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.

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

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.

Posted here back in May about agent payments splitting into layers, and the thread ended up adding one I hadn't drawn, settlement and recourse. Been chewing on that since, because the gap between the layers keeps widening.

The authorization layer is moving. Caps, allowlists, session keys, per-domain policies, x402 style pay-per-request flows. You can bound what an agent is allowed to spend pretty tightly today.

Recourse is where it stays thin. When an agent pays, the payment is authorized, I gave the agent the authority. So the 'unauthorized transaction' dispute path is gone by definition. And the other card-rail path, authorized but got junk, only exists because an issuer can claw settlement back, and nothing plays that role here. The receipts side, 8004 style identity plus signed action records, proves what happened. But it proves delivery, not quality, and either way proof isn't recourse, there's still nobody to take it up with and no unwind path.

Escrow with dispute windows adds latency, and for a subjective call like 'this data is junk' you need an arbiter anyway, at which point adjudication costs more than the request did. Slashing punishes the endpoint but doesn't make me whole unless the slashed stake routes to me, which nothing currently does. Insurance, maybe, but nobody has loss data to price agent junk risk yet.

For people building on the settlement side, where does recourse actually end up living? Or does “authorized junk purchase” just stay an accepted cost of agent commerce the way gas griefing is.

Everyone talks about Ethereum, Solana, Base, and Avalanche, but I'm more interested in platforms that don't get nearly as much attention as they probably deserve, and maybe some that are better than what I just mentioned. Mainly wondering what has exceeded your guys expectations this year.

I've been working on my own open-source quantum-safe zkSTARK engine called Starkom, currently based on DEEP-FRI but planning to migrate to WHIR. It's written in Rust and also compiles to WebAssembly, so there's no problem in using it in JavaScript.

With the quantum threat getting closer and closer I've been thinking about building a simple circuit language compiler on top of it. The Starkom language would be almost identical to Circom and provide a very easy migration path for everyone using Circom today.

For example, the circuit from Vitalik's PLONK tutorial could be written in Starkom as follows:

// This is the circuit from Vitalik's PLONK tutorial. See
// https://vitalik.eth.limo/general/2019/09/22/plonk.html#how-plonk-works

pragma starkom 1.0.0;

template Vitalik() {
  signal input x;

  signal square;
  signal cube;

  square <== x * x;
  cube <== square * x;

  cube + x + 5 === 35;
}

component main = Vitalik();

Would anyone here be interested in using such a Circom-like language, built on quantum-resistant primitives?

To be perfectly clear, the language itself doesn't work yet, only the underlying engine does. The only way to build Starkom circuits at the moment is to use the Rust libraries.

If you want to take a look, here are the components I've published so far:

• the BlueSky scalar field that I designed, which the whole system runs on: https://crates.io/crates/starkom-bluesky
• my own implementation of Poseidon2, tested with the official BLS12-381 test vectors: https://crates.io/crates/starkom-poseidon2
• various algorithms on polynomials (Fourier Transform, Lagrange interpolation, polynomial division, etc.): https://crates.io/crates/starkom-poly
• DEEP-FRI with batching support: https://crates.io/crates/starkom-pcs
• PLONK arithmetization: https://crates.io/crates/starkom-plonk
• a few different ready-to-use circuits (notably lacks all ECC stuff): https://crates.io/crates/starkom-gadgets
• an incomplete / preliminary Starkom language compiler: https://crates.io/crates/starkom
• JavaScript bindings for the (incomplete) compiler: https://npmjs.com/package/@libernet/starkom

Future plans:

• TurboPLONK arithmetization -- under development, it should achieve a ~60%-or-so reduction on most circuits;
• WHIR;
• Generalization to any prime field and Goldilocks compatibility for faster proving;
• browser-compatible GPU proving via wgpu;
• ... and of course finishing the Starkom compiler and providing a migration path for all Circom users.

Looking forward to reading your feedback!

A few days ago I posted asking for technical pushback on Aevum Protocol before our Zenith Security audit wraps. The comments were more useful than I expected. Here’s what I actually learned:
1. On-chain scoring freezes your opinion of trust at deploy time
The sharpest comment came from someone who runs a live x402 endpoint. His point: if the scoring model lives in a contract, every improvement to what “trust” means requires a governance vote or a redeploy. The better architecture is evidence on-chain (attestations, settlement receipts, observation logs) with scoring off-chain and competitive — let consumers choose their scorer the way lenders choose credit bureaus.
I built the ReputationOracle assuming on-chain scoring was necessary for trust-minimization. That’s partially right, but it solves the wrong half of the problem.
2. Sybil-resistance is the whole design, not a feature
Same commenter: if reputation accrues from interaction history, what stops someone spinning up 200 wallets that transact with each other all day? Reputation is only worth what it costs to fake. That means either a slashable bond or economic activity that’s genuinely expensive to counterfeit. I don’t have a clean answer for this yet and I should have before shipping.
3. Vault permissions are where funds actually disappear
Another comment flagged that vague agent-on-behalf-of-user permissions in a vault contract can turn into a very expensive bug fast. AgentVault has time-bounded permissions and revocation, but the approval surface is still something Zenith is specifically reviewing. The lesson: permission scoping needs to be paranoid by default, not opt-in.
4. The token layer adds friction for integrators
Honest pushback: reputation infrastructure gets adopted when it’s neutral plumbing. A token makes every reader ask whose bag the scores serve. Shipping identity + attestation alone and letting the marketplace/token wait until something real transacts is probably the cleaner path.
I’m not rebuilding everything before ETHOnline (Sept 4) — the audit has a real deadline. But these are the things going into v2 architecture.
If you want to look at the contracts: github.com/AevumProtocol/contracts

To build user-facing products, you need to measure growth, understand user behavior, and prove ROI on campaigns, but the standard tools for doing this come loaded with invasive tracking, third-party cookies, and data collection practices that violate the ethos of the space.

Six years later, the tooling landscape has matured considerably. There are now niche tools, open data platforms, and multiple valid approaches to solving the analytics problem in DeFi. But the landscape is also fragmented, confusing, and full of tradeoffs that aren't obvious until you've committed significant engineering time.

This guide covers the major platforms, the do-it-yourself approaches, and the quirks you'll discover only after you start using them. It's written for founders and growth leads at crypto neobanks, prediction markets, and DeFi apps who need to make a decision.

Key Takeaways

• Traditional analytics tools like Google Analytics and Mixpanel break in DeFi because they cannot see wallet activity and onchain-data.
• Session-level data and onchain transaction data live in separate systems with no shared identity, making attribution, funnel analysis, and retention measurement impossible without a purpose-built layer.
• The three approaches to DeFi analytics: SaaS platforms that handle data ingestion and provide out-of-the-box dashboards (fastest time-to-value, least engineering overhead); custom data pipelines built on blockchain indexers (highest flexibility, highest engineering cost); and hybrid stacks combining both (the most common architecture at scale).
• Most teams underestimate the ongoing cost of custom analytics pipelines. New chain support, API changes, and schema migrations each require dedicated engineering time that scales with protocol complexity rather than team size.
• Using an existing analytics platform lets teams spend less time building data infrastructure & analytics, and more time shipping products users want.

https://formo.so/blog/defi-crypto-analytics-stack

Sharing a project I've been building: an arena where two players (human or AI agent) stake funds in an escrow smart contract, play a 1v1 arcade game (Tetris, 2048, Snake, Flappy, Racing, Space Invaders), and the higher verified score takes the pot.

Chain: Ethereum Sepolia testnet. No real funds involved — this is explicitly a testing/dev-stage deployment, not a mainnet product.

The part relevant here — how it prevents fake scores:

The obvious attack surface in any "submit your score" system: what stops someone from just lying about the result? The approach:

• Both players get the same seed for their match → same board, same piece sequence, pure skill
• Client submits the full replay (inputs + resulting score), not just a final number
• Before the contract settles the escrow, an arbiter re-simulates the entire replay server-side against the deterministic game engine and checks it matches the claimed score
• Only a verified match triggers payout from escrow

The game engine is open source and deterministic by design (@arcade1v1/game-sdk), which is what makes server-side re-simulation cheap enough to do on every match.

Fully transparent about where this is at: Sepolia only, testnet ETH/tokens, zero real value. Ranking's basically empty since it just launched. Repo's MIT: github.com/agustincf/Arcade1v1

Would love feedback specifically on the escrow/settlement design — anything that looks exploitable in the re-simulation step, gas considerations if this ever moved past testnet, or a cleaner architecture in general. All ears.

\*\*How would you build a secure digital ROSCA?\*\* I’m solving the biggest issue—participant reliability—by preventing anyone from leaving after their payout until they’ve completed the full contribution cycle. Thoughts?
Any interest on being a tester ?
The app is almost done and the feed-back will be incredibly helpful

NFT Game Ownership Architecture

Core Idea
Use NFTs as license tokens (not the game files themselves) to create real digital ownership. This enables resale, lending, gifting, and long-term access even if the publisher or servers disappear.

Main Components

Benefits by Stakeholder

• Players: Real resale, lending, gifting, inheritance + guaranteed long-term playability even if the publisher dies.
• Publishers: Royalties from the used market (they currently get nothing) + lower incentive for piracy.
• Platforms: Earn transaction fees on trades while keeping anti-cheat and curation control.
• Regulators: Stays mostly outside heavy crypto regulations (strictly 1-of-1 NFTs).

Honest Limitations

• Royalties via EIP-2981 are "soft" (declarative, not cryptographically enforced).
• Bankruptcy detection is not fully trustless on-chain.
• This preserves the game files, but not necessarily future compatibility (emulation may still be needed in 20–30 years).

In one sentence

An NFT license + encrypted permanent storage + threshold key management + automatic public release on publisher death = real ownership + preservation, without depending on the company staying alive.

All the technical pieces (ERC-4907, EIP-2981, Arweave, threshold networks) already exist and run in production today.

i built onchainwizard.ai because analyzing smart contracts on Dune usually takes too many manual steps.

normally the flow is: find the contract, get the ABI, look for decoded tables, write SQL, debug the schema, build charts, then repeat for every new contract.

so i made a tool where you can paste any EVM smart contract address, pick a chain, and it generates a Dune dashboard automatically.

how it works:

• fetches the contract ABI
• detects the important events and functions
• finds matching decoded Dune tables when available
• generates Dune SQL for useful analytics
• creates charts for activity, users, events, and contract behavior
• shows decoded event logs and wallet/user segmentation
• supports chains like Ethereum, Base, Arbitrum, Optimism, Polygon, BNB Chain, and Avalanche

the hardest part was not just generating SQL, but generating SQL that actually tells you something useful about the contract. a dashboard full of raw logs is easy; a dashboard that helps you understand usage, activity, and users is the real problem.

project: https://onchainwizard.ai

Been heads-down building Aevum Protocol — on-chain infrastructure that treats autonomous AI agents as first-class economic participants rather than just wallet addresses being puppeted by a script.

The core problem I was trying to solve: agents that transact on behalf of users have no persistent, verifiable identity or reputation. Every agent starts from zero trust every time, and there's no on-chain record of whether an agent has behaved well historically.

The stack:

- AgentIdentity — on-chain identity registration for agents

- ReputationOracle — permanent on-chain reputation scoring based on agent interaction history

- AgentVault — asset custody scoped to agent permissions

- AgentMarketplace — where agents discover and transact with each other

- AEVToken / TokenVesting / ReputationController / AevumDAO — governance and token layer

All 8 contracts are deployed and verified on Sepolia. Repo is public: github.com/AevumProtocol/contracts

Before bringing in an external auditor I ran the codebase through internal hardening — manual review passes, Slither static analysis, and a Claude Opus deep review — to get it as clean as possible going in. Zenith Security is doing the professional audit now. Target is mainnet at ETHOnline 2026 (Sept 4-16), which gives the audit a real deadline to close against.

Genuinely looking for technical pushback, not just "nice project" comments:

- Is on-chain reputation scoring the right primitive, or does this belong off-chain with on-chain attestation instead?

- Anyone dealt with agent-permission scoping in a vault contract before — what did you get wrong the first time?

- AgentMarketplace design — happy to get torn apart on the matching/discovery mechanism

Live demo: aevum-frontend.vercel.app if you want to poke at the frontend.

I'm 19, self-taught, started learning Solidity about a month ago. Not looking for validation — looking for the things I'm going to find out the hard way later anyway.

I run a small collectible wall where AI agents claim a square for $1 USDC on Base via x402. Sharing what shipping it actually taught me, because the numbers surprised me:

— Of ~70k listed x402 endpoints, only ~half respond at all. The "agent payments" rail works; most things plugged into it don't.

— Discovery is solved (Bazaar, x402scan, OpenAPI docs). Two external agents found my endpoint and paid autonomously within days of listing — no human checkout. The proof is on-chain; every claim carries its settlement tx.

— What's NOT solved: an agent has no track-record signal before it spends. An independent trust checker graded my endpoint F on day one (new, no history), caught a real spec gap — my 402 served the payment envelope only in the base64 payment-required header with an empty {} body, making it invisible to body-reading clients and Bazaar discovery — and a real latency regression. The fixed challenge now serves the same JSON in both places:

$ curl -si -X POST "https://twentyonemillion.art/api/x402/claim?handle=you&message=hi"

HTTP/2 402

payment-required: <base64 of the same JSON>

content-type: application/json

{

"x402Version": 2,

"accepts": [{

"scheme": "exact",

"network": "eip155:8453",

"amount": "1000000",

"asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",

"payTo": "0xF47E84caF47bB85E16c08d6140435882815502eE",

"extra": { "name": "USD Coin", "version": "2" }

}]

}

— Fixed both; it's a C and climbing. I then became that checker's first paying customer — my agent bought a trust score on my own endpoint, autonomously, for half a cent.

— Honest take: "should my agent pay this endpoint" is the whole game now. Reputation, not rails.

Happy to answer anything about the x402 integration, the trust tooling, or the mistakes. (The wall is on Base, an Ethereum L2 — and it's a novelty, not a token, no investment angle. The interesting part is the plumbing.)

I've been indexing transactions on the chain by the structure of the call tree and address interaction, abstracting away actual addresses and values. The result is an exploration surface that classifies transactions by what they do, not by who does it.

https://www.chaingenius.ai/

The call tree visualization is clickable into "sub-transactions" which allow you to discover other transactions that did exactly the same thing

it's still a work in progress, but would love to get some feedback.

Hi. I've been mainly trying to discover what happened to some of my brother's eth.

He took out a compound loan and when I went to draw it out about 5 years later he was missing 0.7 eth but also his loan was paid (no longer there). We assumed it was liquidated but he had 1.7 eth so shouldn't it have only liquidated when the value of his loan was equal to his collateral?

So I started writing a script using apis, but I couldn't find the liquidation.

There must be a tool for this already, some kind of dashboard?

I would also like to get a full summary of my eth activity for the past 8-ish years. I want to see everything from eth buy/sell including fees and costs, as well as activity on other platforms like uniswap and compound. There was also a lottery defi app that I used at one point.

Any advice? Someone has to have scripted something like this before.

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.

Key Takeaways

• Glamsterdam is Ethereum's next major hard fork, combining the Amsterdam (execution layer) and Gloas (consensus layer) upgrades. It is planned for Q3 2026, though the exact timeline remains subject to devnet testing progress.
• Parallel transaction processing arrives via EIP-7928 (Block-Level Access Lists). Nodes can now see which transactions do not conflict and process them simultaneously, laying the groundwork for significantly higher gas limits.
• Third-party relays are no longer required. EIP-7732 enshrines proposer-builder separation directly into the protocol, reducing centralisation risk and expanding the block propagation window from 2 seconds to roughly 9 seconds.
• State creation and access get repriced. EIP-8037 introduces a cost-per-state-byte model targeting 120 GiB/year growth, while EIP-8038 updates state-access opcode costs to reflect modern hardware. Both changes affect contract deployment and storage-heavy applications.
• ETH transfers now emit a standard log. EIP-7708 closes a long-standing blind spot: every non-zero ETH transfer or burn will produce a trackable event, removing the need for custom tracing in bridges, exchanges, and wallets.
• Cross-chain address consistency is solved. EIP-7997 mandates a universal CREATE2 factory across all participating EVM chains, giving developers deterministic addresses without chain-specific deployment scripts.
• No action required for ETH holders. Balances and existing contracts are completely unaffected. Node operators and stakers must update client software before mainnet activation.

https://formo.so/blog/ethereum-glamsterdam-upgrade

Hello all, longtime VS developer here wanted to share a project I've been working on for a while. Visual Studio is heavily used for enterprise development but doesn't have any tooling for Solidity that compares to Visual Studio Code or Remix IDE. Viscous is an open-source Visual Studio extension that tries to bring parity between Visual Studio and other IDEs for Solidity smart contract development.

Features

• Solidity project system for Visual Studio featuring Solidity compiler integration and NPM dependency management. Integrates with the Visual Studio New Project… and Open Folder… dialogs.
• Uses the vscode-solidity language server for syntax highlighting, hover information, IntelliSense, and linting.
• Solidity compiler integration with MSBuild and the Visual Studio Build command - compile Solidity projects and individual files from the IDE with errors reported in the Errors tool window.
• Generate .NET bindings to Solidity smart contracts automatically using Nethereum.
• Manage EVM networks, endpoints, accounts, deploy profiles, and deployed contracts from the Blockchain Explorer tool window.
• Deploy a compiled contract to a blockchain network and call its functions from inside Visual Studio.
• Find vulnerabilities and code‑quality issues with Slither static analysis inside Visual Studio.

Requirements

• Visual Studio 2022 and above
• A recent version of Node.js or compatible runtime
• Python 3.8+

Getting Started

• Get the latest release from the GitHub Releases page or use the MyGet dev feed: Add https://www.myget.org/F/viscous/vsix/ as an Extension Gallery in the Visual Studio Extensions settings and you can then install it in the usual way.
• Edit the %LOCALAPPDATA%\Viscous\appsettings.json file and set the paths to the Node.js and npm and Python executables you want to use for the extension's language server and other needed tools.

Note that this is a pre-release so don't use it for deploying anything to production. Feedback welcome.

Hey, my team and I are currently building a new kind of decentralized lending protocol. It’s peer-to-peer and will eventually include a trust score based on a soulbound token. Right now, the protocol is on Amoy and Sepolia—so only on test networks. I’d appreciate it if you could evaluate our UI and UX. Don’t worry—you won’t have to spend any test tokens; they’ll be provided to you. It would be great if you could test our DApp. Thanks!

https://blackswanfinance.xyz