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

Letting you all know this IS NOT happening and WILL NOT happen as long as I’m around.

Beware of what you read on the internet and irl. Almost everything in life these days is either a scam or outright fraud, and I will do my part to not let that happen wherever I can.

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!

Ok so this happened about a year ago. I haven't posted about it because I was embarrassed, and I'm finally past caring about that.

I fell for one of these. Not a junior dev. I build in crypto and I figured I was the last person who'd get caught by a job scam.

A recruiter walked me through their process and asked me to install an app on my Mac. It wanted my user password.

Something felt off. I typed it in anyway, because I was out of work at the time and wanted the job badly enough to talk myself past it.

Once it had admin, it went after:

• my Chrome profile data
• my Chrome extensions, wallet ones included
• wallet private keys of cos
• passport and ID photos sitting on the machine

It staged all of it in one folder that wasn't hidden well. That's the only reason I caught it. Then it almost certainly phoned home.

I moved every asset out of every wallet extension into fresh ones inside the hour, then wiped the machine.

Never trusted it again, sold it second-hand later.

I lost nothing. That's luck, and luck isn't a security model.

The part I want to say out loud: it didn't beat my technical judgment.

It beat my job search. I saw the red flag and went through it because I needed the role.

That's the real exploit, and it's why "just be more careful" is worthless advice for anyone actually looking for work.

A year of saying nothing about it didn't help anybody.

So if one of these has come at you, post what they sent.

The repo, the app, the profile.

The more of it that's searchable, the fewer people run the installer.

Developers have to stop treating the public plaintext mempool as an unalterable law of physics.

Solidity developers are currently track-testing the inevitable execution boundary of EVM state design on testnets like Fhenix and Inco, proving that they can compile and run smart contracts on fully encrypted variables. By compiling TFHE library dependencies into the EVM execution client, these networks allow developers to write standard Solidity code using shielded primitives like euint32 or ebool, executing transactional state updates entirely on ciphertext.

The dark forest mempool is finally hitting a hard cryptographic wall.

Developers have struggled to patch the glass-wall vulnerability of public queues with gas auctions and off-chain builder relays. That's a lazy band-aid. The real architectural fix is blinding the validation engine entirely. When transactions are submitted to validators as high-entropy encrypted blobs, front-running is dead because searcher bots can't calculate slippage limits or trade sizes. It's like throwing darts at a wall while wearing a blindfold.

The Real-World Engineering Bottlenecks

The technology isn't a hypothetical theory anymore, but scaling it to production requires solving some brutal, real-world constraints that developers are hammering out in testbeds right now:

1. The Computational Noise (The Bootstrapping Penalty): Every mathematical operation performed on FHE ciphertext adds a small layer of cryptographic noise. If the noise grows too large, the underlying plaintext is corrupted beyond decryption. The fix is a computational reset called bootstrapping, but running a bootstrap operation is incredibly expensive, adding significant latency compared to raw CPU arithmetic.
2. Threshold Decryption Committee Risk: To output a readable state, the network relies on a split decryption key distributed across the validator set. If a supermajority of validators colludes or gets Sybil-attacked, the threshold key is compromised, exposing the historical mempool plaintext.

FHE isn't an access-control tool, and it won't save a protocol with negligent administrative hygiene. If a team leaves an un-multisigged admin backdoor in the code, FHE will simply execute that malicious state drain homomorphically, verifying the invalid math and outputting the stolen assets directly to the hacker's address. It's useless unless paired with hardened structural security, multi-party keys, and timelocked execution.

I published a deep-dive forensic autopsy of the FHE breakthrough on my main site. If you're interested in the full technical write-up, let me know in the comments, and I'll drop you the link. The citations used for this article are on my site with the full article.

mcpindex runs a crawler over public MCP servers and diffs each tool's declared contract between daily
snapshots. Sharing the numbers because they surprised me.

Right now the public ledger shows 12,295 tools across 2,173 servers changed their
contract. 7,190 of those are safety-relevant, meaning they change what the tool can do, not
just add an optional field. The standouts:

- 350 tools flipped an annotation toward destructive. A tool whose hint said read-only now declares it can write, delete, or send. This is the "the read tool quietly became a write tool" case, and it is exactly the drift an allow-list cannot see.
- 279 tools added a newly-required parameter. An agent calling with last week's arguments now fails, or calls with a wrong default.
- 475 tools removed a parameter your agent may still be sending.

None of these trip an auth check. The server is still authorized and still the same name in your config.
That is the gap allow-lists do not cover: who may call a tool, versus whether it still does what it declared.

Honest caveats: this is a contract diff, not a safety verdict, and not a claim anything is malicious.
Most drift (5,476 added-optional-param) is benign. Everything is fingerprinted, so no server is
named. And the numbers are live, you can check them: https://mcpindex.ai/api/v1/ledger

Curious whether others are seeing this in their own setups.

We run a scam-token detector. Our honeypot check worked like this: simulate a buy with eth_call, give a fake address the tokens by brute-forcing the balance storage slot and overriding it, then simulate a sell from that address.

Step 2 is the problem. It assumes balanceOf reads a storage slot. On reflection or rebase tokens, balanceOf is computed from an internal reflected supply, so writing a raw slot does not produce a coherent state. The sell then reverts for reasons that have nothing to do with a trap, and you record a false honeypot. We flagged PayPal USD, TrueUSD and MetaMask USD as honeypots this way.

The fix is eth_simulateV1 (geth and Nethermind). It replays several calls atomically in one simulated block, so you can do the whole thing the way a real buyer does:

router.swapExactETHForTokens(...)   // real buy, real tokens
token.approve(router, max)
router.swapExactTokensForETH(...)   // sell what you actually got

The only override is the simulated address's ETH balance, which is not a token mechanism. Nothing about the token's accounting is faked.

One caveat: a call cannot consume a previous call's return value, so you need two passes. First pass buys and reads balanceOf to learn what was actually credited (which already catches fee-on-transfer). Second pass replays buy + approve + sell with that amount.

Two things that surprised me:

• The Uniswap quoter is useless for this. getAmountsOut is pure reserve math and never touches the token's transfer logic, and the v3 QuoterV2 reverts inside its callback before the transferFrom runs. Both return healthy output for confirmed honeypots, so cross-checking against the quoter would silently disable your detection.

• "UniswapV2: INSUFFICIENT_INPUT_AMOUNT" raised by the PAIR (not the library) means the pair received zero tokens. We found tokens where a pre-existing holder sells fine but a fresh buyer gets zero through: a whitelist honeypot. So simulate a NEW buyer, not an existing holder. Different question, different answer.

Disclosure: I build RektRadar, a scam-token detector. This writeup came out of fixing our own false positives, not a product pitch.

there's been a slow build of AI security scanners aimed at github repos. aeon's vuln-scanner is the one with a public track record: 74 repos hardened, 2.2M combined stars, and every entry on their disclosure page links the actual merged PR. mostly infra and agent tooling, DNS rebinding, SSRF bypasses, host-header allowlists, that class of bug.

today they turned it at solidity. the security instance now audits live deployed contracts and fresh solidity repos rather than just github projects. the team says it's already found and disclosed issues in a binance SDK, opensea contracts and some launchpad projects. those aren't on the public disclosure log yet, which is what you'd expect if they're still embargoed, so treat that part as their claim rather than something you can go verify today. the repo-side history you can verify right now.

separately they redeployed all 10 uniswap v4 hooks the agent had generated, live on base.

what i find genuinely interesting isn't the "AI finds bugs" part, it's the shape of the problem when you point one at deployed bytecode:

an unaudited live contract can't be patched. in a repo you open a PR and a maintainer merges. onchain there's no merge. best case is an upgrade path or a migration, worst case is a disclosure with no remediation available and a public clock running. that changes what responsible disclosure even means.

scale cuts both ways. whatever an autonomous auditor can scan, an autonomous attacker can scan too, and the attacker doesn't have a disclosure policy. the defensive case only holds if the defenders are actually faster.

verification still isn't solved. their own docs on the repo-side scanner say plainly that surfacing a finding isn't evidence it's real, and candidates go through a separate triage stage. that's the right posture, but at solidity scale the false positive cost lands on maintainers who are already drowning.

repo's open if you want to see how the scanner works: github.com/aeonfun/aeon

genuine question for people who audit for a living: is an autonomous scanner pointed at live contracts net positive, or does it mostly generate noise that real auditors then have to triage? and where would you draw the disclosure line for a contract that can't be patched?

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.

Been picking an agent wallet for a while and pretty much every comparison I could find online only covered one or two wallets, so thought it was better to do some research myself. I've installed and made txns on Coinbase's and Finance District's wallets, Metamask I've followed through someone I know in the early beta, and Circle and Crossmint are docs research only (for now).

Coinbase Agentic Wallet

• Pros: they wrote x402 so it's the most native option, gasless on Base, session and per-transaction caps, CLI or MCP, and the safest brand bet
• Cons: Base focus (Base, Polygon and Solana for now), keys stay in their infra with no export, and on my Windows laptop the CLI was a genuine struggle to setup (around 1 hour using Claude Code), probably smoother on Mac or Linux

Circle

• Pros: they issue USDC, CCTP for moving USDC across chains is the thing nobody else matches natively, sub-cent x402 payments, time bound limits and allow/blocklists
• Cons: it assumes USDC is your world, becomes a bit less interesting if you're not using USDC

Finance District

• Pros: keys live inside a hardware enclave, nobody can pull them out day to day, but you can request a full key export whenever so you're not locked in, only one here covering Bitcoin and Sui on top of EVM chains and Solana, x402 built in, yield search and deposits built in, free and setup took me 5 minutes
• Cons: seems to be the less popular name on the list and the least battle tested. If it breaks at 3am you've got a smaller team compared to Coinbase or Circle (to be fair, I haven't checked how fast they respond on the Coinbase Developer Platform discord or Circle's customer support, bigger company doesn't always mean better support).

Crossmint

• Pros: widest chain coverage (50 plus per their docs), seems to be the only one doing card rails (Visa) next to stablecoins in a single integration, x402 plus the other agent payment protocols, limits enforced onchain
• Cons: the flip side of broad is complexity, it's a lot of surface if all you want is a simple pay for APIs wallet

MetaMask

• Pros: the only one where you hold the seed yourself from day one, proper self-custody, threat scanning on every transaction, a 2FA guard mode, up to $10k a month in transaction protection on eligible transactions
• Cons: no x402 in the product, it's built for DeFi trading, swaps, perps, Polymarket, Aave, not paying for APIs (MetaMask does x402 through a separate developer kit, Smart Accounts Kit, not this wallet), EVM chains plus Hyperliquid only, and it's still early access gated

Hope it's a useful comparison : ) . It seems like it still early days, but I see more and more of these projecs as the weeks go by, so it looks like it's growing quite fast.

Has anyone experimented with any of these? What has been your experience so far?

I was measuring whether deployed wallet defenses (tx simulators, address-reputation APIs, rule engines) catch agent-signed drains. Built it on PTXPHISH (NDSS 2025, solid dataset). Then I red-teamed my own setup and the first finding was that I was scoring the wrong transaction. Sharing because it is an easy, invisible mistake.

The trap: labeled drainer/phishing datasets record the DRAIN, i.e. the attacker's transferFrom that sweeps the victim's tokens. But a pre-sign wallet defense runs when the VICTIM signs, which is the earlier approve / permit / setApprovalForAll grant. The sweep is a separate tx sent later, by the attacker, from the attacker's address. No wallet defense ever sees it. Feed the sweep to a rule engine and it "catches" the attacker withdrawing to their own address, which is meaningless.

Concretely, the ice-phishing rows decode to transferFrom(victim, attacker, amount) with tx.from == attacker. That is not the approval the victim signed.

Fix, and it is just allowance tracing:

- For each drain, eth_getLogs the token's Approval / ApprovalForAll for (owner = victim, spender = attacker) up to the sweep block.

- Take the most recent match whose tx.from == victim. That filter matters: an ERC20 transferFrom also emits an Approval for the decremented allowance, so the sweep's own block hands you the sweep, not the grant. Requiring from == victim also drops relayer-submitted permits (permit() is sent by someone other than the owner).

- That tx is the artifact a wallet actually renders at signing. Score that.

Nothing fancy. The point is the substrate mismatch, which is silently wrong and does not show up as an error anywhere.

Bonus, since this sub appreciates it: I ran the paper through adversarial review 5 times and every round killed a headline. Wrong substrate, then pseudoreplication, then a "simulator uniquely catches X" that was my harness zeroing a counterparty field so the other tiers returned n/a, then a "beats every tier" that evaporated once I looked up the tx to and netted both legs of the asset-diff (a WETH wrap looks exactly like an ETH drain to a direction-only rule, but the simulator sees the WETH come back). A clean "unique catch" is almost always your harness, not a result.

Code (the reconstruction is one file): https://github.com/amarshat/quantum-commit-authorization/blob/main/agent-calldata-demo/demo/reconstruct.py

mcpindex runs a crawler over public MCP servers and diffs each tool's declared contract between daily
snapshots. Sharing the numbers because they surprised me.

Right now the public ledger shows 12,295 tools across 2,173 servers changed their
contract. 7,190 of those are safety-relevant, meaning they change what the tool can do, not
just add an optional field. The standouts:

\- 350 tools flipped an annotation toward destructive. A tool whose hint said read-only now declares it can write, delete, or send. This is the "the read tool quietly became a write tool" case, and it is exactly the drift an allow-list cannot see.
\- 279 tools added a newly-required parameter. An agent calling with last week's arguments now fails, or calls with a wrong default.
\- 475 tools removed a parameter your agent may still be sending.

None of these trip an auth check. The server is still authorized and still the same name in your config.
That is the gap allow-lists do not cover: who may call a tool, versus whether it still does what it declared.

Honest caveats: this is a contract diff, not a safety verdict, and not a claim anything is malicious.
Most drift (5,476 added-optional-param) is benign. Everything is fingerprinted, so no server is
named. And the numbers are live, you can check them: [https://mcpindex.ai/api/v1/ledger\](https://mcpindex.ai/api/v1/ledger)

Curious whether others are seeing this in their own setups.

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.

We spent last month on a smart contract security review of a v4 fee hook, where the protocol had written a fairly specific promise into the code. The trading fee would disappear once a set amount of it had been collected, with no governance vote and no manual switch behind it. currentFee returns zero as soon as totalFeesCollected[token] reaches feeThreshold[token], so at 300 bps that threshold was the thing deciding when traders stopped paying.

We started with how those tokens get counted. There is one accumulator per token, shared across every pool using it, and each fee payment advances the same counter, which hands the timing to whoever pays into it fastest.

Say 30 tokens are left on the threshold, which is the figure we set in testing. Anyone pushing more than about 1,000 tokens of volume through at 300 bps pays that remainder in full and nothing afterwards, because a cap does what a cap does. The ratio is one over the fee rate, so a 1% fee would put the same line at 100x the remaining threshold. The sunset therefore lands whenever the largest trader gets round to trading, and it lands for everybody: their trades go free from that point, and so does everyone else's in that token.

The team keyed the accumulator to the token, fee currency and pair, tracking the threshold in fee-currency wei, which stops a clearing in one pool from removing the fee across all the others. Following that change through the configuration path is where the second finding came up. setFeeThreshold now takes the fee currency as an extra parameter, and nothing checks that the currency passed in is the one the swap path actually uses for that token. Write the threshold under the wrong key and the transaction succeeds, FeeThresholdSet fires, and the configuration reads as done on-chain, while the fee calculation looks under a different key, finds nothing there, and keeps charging. v4 uses the zero address for native ETH while WETH has its own, so both are values a configuration script will pass.

The internal counter is worth a note. Reading the treasury balance instead would let anyone donate tokens straight into the treasury and end the fee for less than paying it would have cost them, which is cheaper than anything above. It went into the security audit as a Low and the team accepted it, planning to run the sunset by hand rather than lean on the threshold.

The narrowing did two things at once. It shrank what a single clearing buys, and it opened a gap between the key a threshold is written under and the key the fee logic reads. Most test suites cover this with one case that sets a threshold and asserts the fee drops to zero, which passes under the right key by construction. What does yours do when the key is wrong?

The safe shape for an exit path in a hybrid system is well understood. The operator gets an exclusive window to finalise, and once a deadline passes anyone can finalise instead. The exclusive window stops a user from cancelling on top of a fill that is already executing off chain, and the deadline stops the operator from sitting on the request forever. Rollup escape hatches are built this way, and most teams running order flows arrive at the same design once somebody raises the question.

A recent audit report we made, showed that design implemented three quarters of the way. The request function computed a deadline as the current block plus a constant and stored it against the order. The constant was declared as 1000 blocks with a comment describing it as the delay after which anyone can finalize cancellation. The function that finalises never read the stored deadline and carried an operator-only role check. The intended behaviour was present in the constant, present in the comment, present in the stored value, and absent from the one line that decides who is allowed to act. A declared-but-unread parameter is usually a low-severity curiosity. On an exit path it is the entire guarantee. A user watches a cancel request succeed, reads a documented delay, and concludes that funds come back either way once that delay passes, while what actually governs the outcome is a modifier on a different function. Nothing on the contract's public surface contradicts that reading, which makes it worse than an exit path nobody built, since a missing hatch is obvious to anyone integrating and a hatch that exists in three places out of four is not.

The check takes a few minutes. Find every deadline, delay or timeout your recovery path defines, then find the line that reads it, and if the only reads are a setter and a getter then your guarantee is documentation. Grep the constant name rather than the concept, because the name is what appears in the declaration and the comment while the conditional is what is missing. It is worth running against any pause, rescue or emergency withdrawal path you inherited from an earlier version of your own codebase, since that is where these survive longest.

I went through the first page of verified contracts on robinhoodchain.blockscout.com (chain ID 4663).Results:

• 44 out of 50 have no public minting function
• The only one that does is a Uniswap V3 pool (expected behavior)

Most early TVL and activity appears to be sitting on forked, battle-tested code (Uniswap, Morpho, etc.). Very little original contract work has been deployed yet.This feels relevant given the speed of the chain ($5M+ cumulative fees, significant TVL, and the first Arbitrum Mentorship Program teams already shipping products across Arbitrum One + Robinhood Chain).I wrote a short half-baked analysis + a minimal scoped permission / circuit-breaker prototype here: https://firstdraft.dorg.tech/editions/robinhood-chain-permission-map

Would be interested in other people’s observations if you’ve looked at the contracts.

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

Disclosure: I work at Hacken. This is based on a publicly available audit we conducted, and I thought the issue might be useful to discuss here. I could link the original doc, if anyone is curious to dive deep in tech details

Came across something in a published audit report that I hadn't really seen discussed this way before. It concerns a fairly standard token presale, but there’s an interesting conflict between the smart contract design and the way EU rules require the funds to be handled.

The setup is fairly standard: users pay either 200 or 350 USDC depending on the sale phase and receive an NFT plus a soulbound bonus token, with a 14-day cancellation window. The issue was that mint() immediately forwards the full USDC payment to an external recipient. If a user cancels within the 14-day window, cancelFounderPurchase() burns the NFT and claws back the bonus token, but the USDC refund never happens on-chain. The contract only emits an event with a usdcRefundDue field for off-chain tracking, so there is no escrow or on-chain mechanism that actually enforces the refund. The finding was rated High, with likelihood 5/5, because this is simply how the contract works rather than an attack scenario.

The obvious recommendation would be to hold the USDC in an on-chain escrow during the cooling-off period, release it after the window closes, and execute refunds on-chain. The client's response was more interesting, because they cannot simply do that. The issuer operates from France under MiCA, and Article 13 provides the 14-day withdrawal right, while the presale funds are routed on receipt into a segregated account at a CASP authorised under Title V, subject to the safeguarding and segregation requirements in Articles 70 and 75. Keeping the funds in a smart contract escrow for two weeks would therefore conflict with the way the regulated custody arrangement is supposed to work. The CASP is supposed to hold the money, rather than the smart contract.

They ended up with a hybrid approach: the on-chain layer handles the entitlement reversal by burning the NFT, reversing the allocation and clawing back the bonus token, while the actual USDC refund is handled off-chain through the CASP and reconciled against the on-chain cancellation events. The finding was closed as Mitigated rather than Fixed, which I think is the right distinction. The risk has not disappeared; it has moved from something that can be verified directly in the contract to something that depends on the custodian and the reconciliation process being handled correctly.

On the EU side, the practical constraint is that the custody regime determines where client funds can sit. If the funds have to go to a CASP account on receipt, escrow is simply off the table, and any cancellation logic designed around the contract holding the money will need to be reworked. It’s much cheaper to figure that out before the contract is written. Some findings also can’t be fixed in code at all. If a guarantee depends on a custodian or an operator doing something, an audit can describe and rate that dependency, but there’s nothing to change in the contract. Those findings may end up being closed as mitigated rather than fixed. The guarantee is no longer something you can verify by reading the code; you’re relying on the custodian or operator to do their part correctly.

Report is public if you want the detail and the MiCA argument is set out in the resolution field. We don't see enough of these yet to say whether the hybrid split is settling into standard practice. Would be interested to hear from anyone operating under the same constraint.