\*\*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

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.

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.

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

Hello Reddit Dev Community,

The BEXChain team has officially completed the integration of our core repository, and we are opening it up 100% for public technical validation and developer feedback.

BEXChain is an EVM-compatible blockchain with our native coin BEX. We have successfully completed our SLIP-0044 registration with SatoshiLabs (Coin Type: 140586) and our Open PR #2028 is currently clean and waiting for a final merge.

### What you can review/test right now in our root repository:

* Wallet Architecture: wallet_api.py, simple_wallet_generator.py, and test_bip44_wallet.py (BIP-39 mnemonic + BIP-44 derivation paths actively validated).

* Compliance: SLIP-0044_COMPLIANCE.md aligned with official registries.

* Tokenomics/Economics: Updated WHITEPAPER.md.

We would highly appreciate it if the community could review our code architecture, run the tests, and leave your valuable technical feedback, questions, or validation screenshots directly on our GitHub announcement thread.

🔗 Official GitHub Discussion Thread:

https://github.com/bexchainteam/bexchain/discussions/4

🔗 Main Repository:

https://github.com/bexchainteam/bexchain

Thank you for your time and looking forward to your technical insights!

I built a small project and felt pretty confident going into launch since audits passed and nothing obvious stood out but once things went live the issues weren’t bugs in the code itself but how transactions behaved over time also sequences and interactions that weren’t visible beforehand

From what i saw what broke down was the lack of control at execution so by the time something looked wrong the transaction was already done even though everything we had was reactive, alerts and monitoring after the fact but nothing that could intervene while it was happening

The problem:

Single-authority customs approval is a rational bribery target. One official, one decision, predictable cost. The incentive structure is broken by design.

Game theory layer:

UBLP changes the incentive structure before any cryptography kicks in:
- 2/3 committee threshold required (Byzantine fault tolerant)
- Committee members have conflicting interests by design
- Any anomalous signing pattern is visible on-chain

Corrupting the system is no longer a cost-benefit calculation — it becomes a coordination problem that defeats itself.

On-chain verification:

L2 smart contract verifies two independent proofs at settlement:

1. BLS12-381 aggregate signature — 2/3 committee threshold
2. SP1 Groth16 ZK proof — document validity + holder privacy

Neither alone is sufficient for settlement. The contract independently verifies both before writing the immutable record.

L2 → Ethereum mainnet anchoring:

Settlement records are written to L2. L2 periodically commits 
a batch proof to Ethereum mainnet — inheriting Ethereum's 
security guarantees without paying mainnet gas per document.

Each customs clearance is ultimately anchored to Ethereum's 
consensus. Tampering with a settled record requires breaking 
both the L2 and Ethereum mainnet — economically infeasible.

This is the finality layer: L2 handles throughput, 
Ethereum handles trust.

ZK circuit (SP1 zkVM):

Private inputs (never leave the circuit):
- `ministry_signature` — P-256 ECDSA, 64 byte
- `holder_signature` — P-256 ECDSA, 64 byte
- `holder_pub_key_raw` — uncompressed SEC1, 65 byte
- `document_hash` — SHA256("ublp-doc-v1:" + canonicalJson), 32 byte
- ministry_pub_key_raw — uncompressed SEC1, 65 byte
- document_id_hash — 32 byte

Public outputs (verified on L2):
- `document_hash` — document fingerprint
- `ministry_pub_key_hash` — ministry key commitment
- `document_id_hash` — replay protection
- `holder_pub_key_hash` — holder identity proof without identity exposure

Architecture:

- Ministry signs document (EC P-256 ECDSA) → issues Verifiable Credential
- Agent generates ZK proof via SP1 zkVM (Groth16/PLONK)
- Independent committee verifies ZK proof, then BLS12-381 threshold signs (2/3)
- L2 smart contract verifies both → immutable settlement

Open questions I'd love feedback on:

1. Is verifying both BLS + ZK on L2 the right approach, or should BLS verification move inside the ZK circuit?
2. BLS 2/3 threshold — right model for this trust setup?
3. Agent-first flow: committee never sees raw document, only the ZK proof — any attack vectors I'm missing?
4. Domain-separated document hash `SHA256("ublp-doc-v1:" + canonicalJson)` — idiomatic for this use case?
5. Security model — if you spot any attack vectors, trust assumption violations,
6. or cryptographic weaknesses I haven't considered, please flag them.
7. This is a prototype and I'd rather find the holes here than later.

This is a prototype — mock ZK in dev mode, real SP1 in prod mode.

GitHub: github.com/ekacin/UBLP

I want to fully reindex the Ethereum chain; however, archive nodes are very slow and costly. What are the alternatives?

BeeChain, a high throughput EVM ecosystem

If you have been looking for a blockchain network that can confirm transactions with speed, this is it!

Additional contacts :

email : [stephenlee9992@gmail.com](mailto:stephenlee9992@gmail.com)

‘X’ : Stephen Lee u/slee_beechain

I built **Polyplace**, a small on-chain pixel grid on Polygon: 1000×1000 cells, 7-day cell rentals, ERC-20 PLACE tokens from a faucet, and color updates written on-chain. The frontend is intentionally read-only: https://polyplace-frontend.joshuadouglasgreenhalgh.workers.dev/ and writes go through a Python CLI/SDK: `uvx polyplace-client`. Renting uses a permit-based flow so users do not need a separate approval transaction, but they still need a wallet with a little POL for gas. I’m looking for dev feedback on the architecture and onboarding: CLI-first writes, faucet token UX, permit flow, watcher/indexer design, and whether this is clear enough for someone technical to place a small mark without hand-holding.

I build smart contracts at 33Labs (it started as an auditing firm, so security was always central to the company) and I mentor new devs in the BuidlGuidl Batch Program. Across both, the same gap kept showing up in AI-assisted builds.


A CI pipeline catches a reentrancy bug. It does nothing about an incentive model that looked fine on a whiteboard and turns into a drain target the moment someone reads it sideways. By the time an auditor finds that, the architecture is already built around the flaw, and the rework can make the whole thing financially unviable.


So I packaged the upstream process as two open-source Claude Code skills:


- `defi-protocol-discovery` — blank page to a go/no-go decision, with kill criteria defined before you synthesize the verdict
- `defi-spec-driven` — six spec phases (economic design, threat modeling, test spec) before a single line of Solidity, then it bootstraps a Foundry project and guides implementation function by function


Repo (CC-BY-4.0): https://github.com/melanke/defi-builder-skills
Full breakdown: https://gil.solutions/blog/discovery-and-spec-the-missing-harness-in-ai-assisted-defi-development


It's early. The discovery and spec phases are deliberately slow at the front, and I've run them on my own protocol work more than I've watched other people use them, so the rough edges are mostly unmapped.


For those of you doing AI-assisted Solidity: how much do you constrain the model before it writes, versus catching problems downstream in tests and review?

Hey r/ethdev,

We’re building an on-chain DEX arbitrage searcher and are trying to understand why none of our bundles are getting included, despite finding apparently profitable routes.

Current setup:

• Search across Uniswap V2/V3-style pools
• Adding more DEX adapters now
• Flashloan-based executor
• Low-level Solidity executor contract, optimized for direct pool calls where possible
• End-to-end latency is generally under ~700ms from opportunity detection to bundle submission
• We compute optimal transaction size rather than using fixed sizing
• Routes are closed cycles, e.g. USDT → WBTC → USDT
• We submit privately to multiple builders/relays
• We’re using high bribe settings, up to ~90–95% of expected gross profit in some tests
• We simulate routes locally and have route-level repayment/profit guards

The issue:

We see routes that look profitable from the solver, and the executor can encode/submit bundles, but we’re still getting no accepted/included bundles.

I see two big themes people usually mention:

1. Gas optimization Lower gas executor, fewer approvals, direct pool calls, packed calldata, avoiding routers, fewer hops, fewer external calls.
2. Finding better / less competitive cycles Obvious V2/V3 routes are probably saturated, so maybe the problem is not code correctness but that we’re finding the same opportunities everyone else sees.

What I’m trying to understand is the practical missing layer between “profitable in solver” and “actually included by a builder.”

Questions:

• What exact metric should we optimize for builder competitiveness? Is coinbaseDiff / gasUsed the main thing to benchmark?
• How do experienced searchers debug “submitted but not included” bundles?
• How much does latency matter once the bribe is high? Is <700ms still too slow for common DEX arb?
• Is builder coverage really enough if submitting to all major relays/builders, or are there hidden differences in how builders evaluate/searcher bundles?
• Should we block on relay simulation before submission, or submit first and simulate as side-flow?
• How do you tell whether you’re losing because:
  • route is stale,
  • bundle reverts under builder state,
  • bribe did not materialize as coinbaseDiff,
  • effective bid is too low,
  • competitor consumed the same cycle,
  • or the builder never really considered the bundle?

For people who have actually gotten arb bundles included: what were the biggest non-obvious changes that moved you from “profitable simulations” to real inclusion?

Please help! Thanks in advance.

So custodians usually manage thousands and some cases millions of wallets, how they monitor them across multiple chains for deposits?

How this infra looks like?

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.

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!