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.
Would love a website and idea review, be honest
Solo founder. I built a web app that locks your crypto until a date you pick (up to 10 years), no early withdrawal. Once it's locked, it's locked — the point is to kill panic-selling.
Came from my own problem: couldn't stop trading at the worst times, so I made it impossible.
Link:TimeLock
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
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.
| Component | Tech / Standard | Function | Benefit |
|---|---|---|---|
| License Token | ERC-721 | One NFT = ownership of one game copy | True transferable ownership |
| Temporary Lending | ERC-4907 | Separates "owner" from temporary "user" with an expiry timestamp | Lend games without losing the NFT |
| Resale Royalties | EIP-2981 + contract rules | Automatic % royalty paid to publisher on every secondary sale | New ongoing revenue for publishers |
| Game Files | Encrypted + Arweave | Permanent off-chain storage (one-time payment) | ~200 years of guaranteed storage |
| Access Control | Threshold crypto (e.g. Lit Protocol) + SIWE | Key is split across nodes; unlocks only when wallet proves NFT ownership | No single company controls access |
| Dead Man's Switch | On-chain oracle + threshold release | If servers are down for a long time or bankruptcy is detected → key is released publicly | Game is automatically preserved |
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.
Hello,
I'm currently working on an EVM event listener for a crypto payment gateway, and I'm facing a dilemma regarding the best way to handle chain reorganizations. Specifically, I'm trying to figure out the right approach for dealing with the risk that a reorg could remove transactions from a reorganized block, including legitimate payments.
What are the current best practices for handling this in production systems?
I'd also like to share my current thinking and hear whether I'm on the right track or missing something.
My idea is to make the number of required confirmations depend on the payment amount. For example:
I'm expressing these thresholds in minutes only for simplicity. In practice, the implementation would use block confirmations, since every blockchain has different block times.
With this approach, I assume I would need multiple webhook states, something like:
That way, merchants can distinguish between a payment that has been detected on-chain and one that has reached the required confirmation threshold.
To be honest, I couldn't come up with a more balanced approach than this. I'd really appreciate any advice, suggestions, or insight from developers who have already dealt with this problem.
Thank you!
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 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 automatically generates a Dune dashboard.
how it works:
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
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.)
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:
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.
CREATE2 factory across all participating EVM chains, giving developers deterministic addresses without chain-specific deployment scripts.For people watching this space, real time cross border payments are no longer the demo, they're production for billions in B2B and remittance volume. The stack that made it work is more boring than ethereum twitter expects.
A regulated infrastructure layer handles licensing, custody, and the on/off ramps. USDC sits in the middle as the settlement leg. Partner banks and mobile money networks handle local payout. The platform on top owns the user experience.
For north america origination the layer most platforms run on is cybrid, because US and Canada money transmitter coverage plus ACH Pull is hard to replicate. Bvnk does the equivalent for EU. Conduit for LATAM, zero hash for embedded crypto angles. The composition depends on corridor strategy more than tech preferences at this point.
Whats genuinely new in 2026, the regulated infra layer is mature enough that platforms can launch on stablecoin rails without owning custody, licensing, or banking relationships. That was not true in 2022, the providers existed but the maturity didn't match the use case yet.
Settlement is timestamped on chain, reconciliation runs through normal accounting tooling. Speed is 10 to 30 minutes end to end for major corridors. This is the boring infrastructure version of "crypto for payments" that actually shipped.
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
Built a prototype for cryptographically securing customs document clearance.
The core idea: make document manipulation mathematically impossible after ministry approval, without exposing document contents or holder identity.
How the ZK layer works:
The ZK proof is generated inside SP1 zkVM — a RISC-V zkVM that compiles Rust circuits to Groth16/PLONK proofs. The circuit takes the ministry's ECDSA signature and the document hash as inputs, and mathematically proves three things simultaneously:
All of this is proven without revealing the document contents, the holder's identity, or the ministry's raw signature to any external party. The committee that attests to the proof never sees the underlying data — only the mathematical statement "this is valid."
Domain separation is applied to the document hash: `SHA256("ublp-doc-v1:" + canonicalJson(document))` — preventing cross-protocol hash collisions.
Architecture:
- Ministry signs document (EC P-256 ECDSA) → issues Verifiable Credential
- Agent generates ZK proof via SP1 zkVM (Groth16/PLONK)
- `document_hash` and ministry sig as public inputs
- holder identity as private input → only `holderPubKeyHash` exits the circuit
- Independent committee verifies ZK proof, then BLS12-381 threshold signs (2/3)
- L2 smart contract verifies both ZK proof + BLS signature → immutable settlement
ZK Circuit inputs:
Private (never leaves the circuit):
- ministry_pub_key_raw — uncompressed SEC1, 65 byte
- document_hash — SHA256("ublp-doc-v1:" + canonicalJson), 32 byte
- holder_signature — P-256 ECDSA, 64 byte
- holder_pub_key_raw — uncompressed SEC1, 65 byte
- holder_did — UTF-8 bytesPrivate (never leaves the circuit):
- ministry_signature — P-256 ECDSA, 64 byte
Public outputs (verified by L2):
- document_hash — document fingerprint
- ministry_pub_key_hash — SHA256(ministry raw key)
- document_id_hash — replay protection
- holder_pub_key_hash — holder identity proof; hash only, not raw key
Key design decisions I'd love feedback on:
This is a prototype — mock ZK in dev mode, real SP1 in prod mode.
GitHub: github.com/ekacin/UBLP
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.
Note that this is a pre-release so don't use it for deploying anything to production. Feedback welcome.
I want to fully reindex the Ethereum chain; however, archive nodes are very slow and costly. What are the alternatives?
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:
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:
What I’m trying to understand is the practical missing layer between “profitable in solver” and “actually included by a builder.”
Questions:
coinbaseDiff / gasUsed the main thing to benchmark?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.
Early this year, I set out to solve a deceptively simple problem: **how does an AI agent settle a financial transaction on-chain?**
Not "call an API." Not "reply to a prompt." Actually move value, ETH, USDC, whatever, from point A to point B, with cryptographic proof of what happened, and a dispute mechanism in case something goes wrong.
Six months, 18 Solidity contracts, and one embarrassing `Math.sin()` price oracle later, here's what I actually needed.
**The architecture that survived**
Three contracts matter. The rest were noise.
**Escrow.sol**: Holds funds until an intent is fulfilled. The key insight: the agent never holds a private key. It posts an intent. Executors compete to fulfill it. The escrow settles only when conditions are met. `nonReentrant` on `assignExecutor()` and `raiseDispute()` caught a reentrancy vector I'd missed in the first draft.
**Intent Parser**: The agent says "swap 1 ETH for USDC on Solana." The parser needs to output structured JSON without hallucinating. I started with GPT-4. It confused "Arbitrum" with the "ARB" token, a $10,000 hallucination waiting to happen. Now I use a 4-layer fallback: compromise.js → 12 regex patterns → GPT-4 (only when confidence < 0.6) → RAG memory. The LLM is a safety net, not the primary parser.
**Circuit Breaker**: My agent called a dead OpenAI endpoint 47 times before I noticed. Each call cost money. Each returned nothing. The agent didn't know it was failing, it just thought the world was returning empty responses. I built a sliding-window state machine: 3 failures in 5 minutes → OPEN → 30s probe → HALF_OPEN → reset or lock. When the circuit is open, the agent falls back to a local parser. No API call needed. Graceful degradation > perfect uptime.
**What broke that I didn't expect**
- `Math.sin()` as a price oracle. It was a placeholder that somehow made it to staging. Don't laugh, you've done something equivalent.
- Direct wallet integration. First design gave agents a key. Reversed it after a close call in testing. Intent-based execution is harder to build but fundamentally safer.
- The 4-layer parse chain was born from a GPT-4 hallucination that would have cost real money.
**What surprised me**
Cross-chain settlement is not primarily a smart contract problem. It's an **orchestration** problem. The contracts are the easiest part. Making the agent decide correctly, attest to its decision, and fall back gracefully when things fail, that's where the real engineering lives.
**The honest limitation**
All 18 contracts compile and 175 tests pass. What doesn't exist yet: zkTLS integration, Solana support, and a production-grade adapter for existing agent frameworks. I know roughly how to build each. If you've solved any of these, I'd genuinely love to hear how.
What safety patterns do you use when your agent touches real money? I'm especially interested in hearing from anyone who's run agent-incentive experiments on testnets.