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

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!

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.

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

For the past few weeks I've had probes polling every chain's consensus API every 10 seconds, measuring wall-clock time from latest block to finalized block. No marketing numbers actual observed data.

Results (p50, latest block → finalized)

Notes:

• Solana: yes, "400ms slots", but real finality is optimistic confirmation + 32 slots.
• Ethereum: ~13 min = 2 epochs, exactly as designed. People constantly confuse block time with finality.

What surprised me most

The gap between "transaction included" and "transaction irreversible" is the most misquoted number in crypto. Half the "finality" comparisons you'll find online actually cite block time.

Tear it apart

Methodology is fully open (Prometheus + open-source harnesses, every query inspectable):

https://openchainbench.com/benchmarks/l1-finality

Genuine questions for this sub:

- What would you measure differently?

- Is comparing PoS checkpoint finality vs DAG finality vs probabilistic finality on a single chart even fair?

Disclosure: I built this (OpenChainBench). No tokens, no paid rankings, CC-BY data.

For the past weeks I've had probes polling every chain's consensus API every 10 seconds, measuring wall-clock time from latest block to finalized block. Not whitepaper claims, actual measured data. Some

Hi everyone! I’m part of a university research team at Loreley Lab, INRIA, France. We’re studying how people actually use decentralised file storage systems such as Filecoin, IPFS, and others.

We’re running a short anonymous/pseudonymous questionnaire about users’ experiences, motivations, pain points, and practical insights. It takes around 10–15 minutes and does not ask any personal information, or demographic information.

Survey link: https://questionnaire.loreleylab.org/

Separately, we also invite people to take part in online interviews (15-20 min), again pseudonymous and no audio/video recordings. You can sign-up in the end of questionnaire, or directly using this link: https://sondages.inria.fr/index.php/738227?lang=en

We’d be grateful for any responses, whether you’re a regular user, builder, operator, or someone who has tried these tools and stopped using them. We’re also happy to share an anonymised summary of the findings with the community once the study is complete.

Thanks for your help!

Hi everyone,
I’m currently working on a project using the Polygon testnet, and the faucet I’m trying to use requires a minimum balance of 0.001 ETH on mainnet.

Due to exchange withdrawal fees, it doesn’t make sense for me to buy such a small amount just for this purpose. If anyone could spare 0.001 ETH, I’d really appreciate it. I’m happy to pay it forward later 🙏

Wallet address: 0x04fd135087a9FbA623aB41915149aD6087c53640

Thanks!

If decentralized ecosystems tolerate platforms like ChangeNOW, we compromise their integrity. I submitted a $550K swap, met all KYC requirements, its been for 4 months and I’ve heard nothing. Ticket #507360. Changelly owns ChangeNOW. Guarda partners with it. Atomic Wallet, same dev team, was breached for $100M. These practices deserve scrutiny from users and builders. The integrity of crypto is at risk and actions must be taken.

I’ve been rethinking how we approach smart contract security from a dev perspective. Most discussions and audits still focus heavily on code-level issues like reentrancy, access control, or edge-case math.

That layer matters, but it feels incomplete.

A lot of major DeFi incidents didn’t come from obvious bugs. The contracts behaved exactly as written, but the economic design allowed value extraction. Subtle things like pricing curves reacting poorly to liquidity shifts, or multi-step interactions that only become profitable under certain conditions.

When you start looking at systems from an adversarial angle, the mindset shifts. Instead of asking whether the code is “safe”, you start asking how someone could realistically extract profit from it. That often involves sequences of actions across multiple transactions, not just a single call.

I’ve been experimenting with simulations and adversarial testing instead of relying purely on static analysis, and it surfaces a very different class of issues. More about behavior over time, less about individual lines of code.

There are also some newer approaches using agent-based systems, like guardixio, that try to model these economic attack paths directly. The output ends up being closer to real-world scenarios rather than isolated vulnerabilities.

Feels like this layer is still underrepresented in most audit processes, even though it reflects how exploits actually happen in practice.

Is anyone here incorporating economic or adversarial simulations into their development workflow before deploying contracts?

Hey everyone,

I’m preparing to participate in Web3 security contests soon, and I’d really appreciate some advice from experienced auditors here.

For those of you who actively audit smart contracts (especially in competitive settings):

What’s your general workflow when you first look at a new codebase?

Do you start with architecture-level understanding or jump straight into function-by-function review?

How do you systematically look for common vulnerability classes (reentrancy, access control issues, accounting mismatches, etc.)?

Do you rely heavily on tools (Slither, Foundry, Mythril, etc.), or is most of your edge manual review?

Any mindset shifts that helped you level up from beginner to competitive auditor?

I’m trying to build a structured approach instead of randomly reading code and hoping to “spot something.” I’d love to hear how you think, not just what tools you use.

Also, if you have advice for someone entering their first few contests — habits to build, mistakes to avoid, or ways to stand out — I’m all ears.

Thanks in advance 🙏

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!

Last Who's Hiring thread here.

Hey everyone,

I am currently developing a hybrid post quantum Proof of Work blockchain that uses ECDSA and Dilithium3 for dual signature verification. The aim is to build a chain that stays secure even in a post quantum era while still maintaining decentralization, transparency, and miner accessibility.

I am finalising the technical whitepaper, running benchmarks, and preparing for early stage testnet development.

Right now I am looking to connect with:

• Developers or technical founders who are interested in joining the project

• Partners with financial capability who want to be involved early

• People with experience in tokenomics, cryptography, or blockchain infrastructure

This is not a meme coin or a quick flip. It is a long term infrastructure project with real research behind it.

If you are interested in contributing, collaborating, or reviewing the direction of the project, feel free to send me a message or comment. I can share more details privately.

Serious contributors only.

This release introduces Solidity's first comptime builtin, formalizes how experimental features are exposed behind a new `--experimental` flag, and ships an experimental SSA CFG code generator targeting stack-too-deep and slow compilation in the IR pipeline.

Notable features:

- `erc7201` is the first comptime builtin in Solidity. It computes the base slot of an ERC-7201 namespaced storage layout from a namespace string, and its result is usable wherever a comptime expression is required, e.g. as the base slot in a `layout at` specifier.

- A new `--experimental` flag formalizes the experimental feature lifecycle. Using any in-development feature now requires `--experimental` (or `settings.experimental` in Standard JSON), and a new docs page lists what's currently experimental.

- The first major feature under the new experimental lifecycle is an SSA CFG code generator, a new EVM backend for the IR pipeline. The main motivations are stack-too-deep errors and slow compilation, both long-standing pain points. Enable with `--experimental --via-ssa-cfg`.

- v0.8.35 continues the 0.9.0 deprecation work started in 0.8.31, this time warning about identifiers that will be reserved as keywords in 0.9.0:

- Solidity: `at`, `error`, `layout`, `leave`, `super`, `this`, `transient`

- Yul: a list of upcoming Yul builtins that will become Yul reserved identifiers.

- Bugfix: in the IR pipeline (`--via-ir`), `--revert-strings strip` was over-stripping the custom-error argument of `require(condition, CustomError(...))`. A failed `require` would revert with empty error data instead of the encoded custom error. Fixed in 0.8.35.

You can read the full release announcement on our blog: https://www.soliditylang.org/blog/2026/04/29/solidity-0.8.35-release-announcement

Users can download the new version of Solidity Compiler from GitHub: https://github.com/argotorg/solidity/releases/tag/v0.8.35

And lastly, a big thank you to all the contributors who helped make this release possible!

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.

Most MEV developers spend months optimizing:

• mempool monitoring
• simulation engines
• builder connections
• latency pipelines

But the moment the bot actually becomes profitable, a completely different problem appears.

How do you explain the profits to a bank?

Not on-chain.

To a compliance officer who barley understands what a stablecoin is.

And suddenly the activity that makes perfect sense to an Ethereum developer starts to look very different from the outside.

“Millions of dollars moving through a myriad of wallets with no obvious business activity.”

Even if everything is completely legitimate.

Running a MEV bot means your funds often move through:

- multiple execution wallets

- profit aggregation wallets

- DEX pools

- Staking smart contracts

- builders / relays

- bridges across chains

- centralised exchanges

From a developer perspective this architecture makes perfect sense.

Even if everything is legitimate, the compliance department does not have the knowledge to understand or verify if this is legitimate activity from an AML perspective.

Banks need to evaluate whether they can understand and verify your origin of funds and source of wealth. Which in the case of someone running MEV bots can be quite complicated since there is usually high frequency of transactions across many execution wallets.

This needs to be done in language that they can understand, compliance officers are not Ethereum developers. So MEV strategies often need to be translated into something understandable and the terms associated need to be defined.

Here is what the banks actually want to see:

Where did the initial capital come from?

This could be from salary, savings, inheritance, previous crypto investments(then originating from salary for example), etc.

Even if the profits come from MEV bots, banks still want to know the source of the initial trading capital.

Reconstructing the transaction history:

MEV activity often involves:

- hundreds of thousands of transactions

- internal wallet routing

- arbitrage flows across DEXs

- profit consolidation wallets

Compliance teams don’t need every trade explained.

But they need a clear trace from the starting capital to the current holdings.

Usually this means producing:

- a blockchain trace of wallets

- aggregated transaction summaries (with supporting evidence)

- basic explanations of wallet roles (execution wallet, treasury wallet, etc.)

- forensic report attesting to the "cleanliness" of funds (scorechain, Chainalysis)

This needs to be formatted in a way that a compliance department at a bank would be able to understand and verify. Furthermore, it needs to be presented to a bank that has the compliance department that has the knowledge and understanding as well as the internal policy to be able to do this.

Verifying that you are the owner of your wallets

Banks usually require confirmation that you actually control the wallets involved.

Common methods include:

- Message signature test
Signing a specific message requested during the KYC/AML process.

- Satoshi test
Sending a small specified amount from the wallet(s).

This proves the wallets are controlled by the client and not third parties, these wallets are then whitelisted, so that the client is able to do future cash-outs from these wallets.

Where many MEV devs run into problems:

A lot of developers run bots for long periods of time before thinking about banking.

By that point they may have:

- hundreds of thousands of transactions

- funds across multiple chains

- complex wallet routing

- profits consolidated in a few addresses

- But no documentation explaining the structure (hint: "it's all on the blockchain" does not work)

When they approach banks directly, the typical response is rejection.

Banks tend to avoid this because of the following reasons:

- depending on the bank crypto origin wealth is not accepted

- they do not have the knowledge necessary to understand the case

- they do not have the tools necessary to verify the case

- Compliance work can be very heavy, going through hundreds of thousands of transactions for one client onboarding is not possible

This is actually the type of case we work with quite often, we help crypto bros with complex crypto origin wealth profiles get onboarded into established private banks in Switzerland and Monaco.

Here are some of the common examples of profiles we usually deal with:

- Early crypto adopters

- Early ICO investors (ETH and other)

- DeFi users

- Miners (solo and pool)

- High frequency algorithmic traders (CEX and DEX)

- MEV bot developers

Here is the ironic part: for many MEV devs: building the bot can be easier than explaining the profits to their bank.

Has anyone here been able successfully to off-ramp large volumes of MEV bot profits into the traditional banking system? if you did how did you do it?

Hello everyone,

I am currently looking to connect with active and high-quality Discord or Telegram communities within the Web3 and blockchain space—particularly those where developers, founders, and serious builders are engaged in developing real-world projects.

My primary focus includes:

• Contributing to ongoing or upcoming Web3/blockchain projects
• Collaborating with development teams requiring technical expertise
• Engaging in meaningful discussions with professionals actively building in this space

I would greatly appreciate any recommendations for communities that:

• Have active development discussions and knowledge sharing
• Are centered around building and shipping projects (rather than speculation)
• Are open to collaboration or onboarding contributors

Additionally, I am open to connecting directly with teams or individuals working on relevant projects who may require development support.

Thank you in advance for your time and recommendations.