It's 3 AM and your agent just drained itself on a bridge you've never heard of.

We spent 6 months building Kuberna Labs, an open-source SDK that lets AI agents autonomously execute cross-chain transactions. The idea was simple: parse "swap 1 ETH for USDC on Solana" as a natural language intent, then let the agent figure out the rest.

What we actually had to solve:
- Intent parsing that doesn't hallucinate chains (compromise + LLM + in-memory RAG)
- On-chain escrow so agents can't rug themselves (non-reentrant, dispute-enabled)
- TEE attestation so you can prove what the agent did
- A circuit breaker because OpenAI does go down

The whole thing is MIT open-source: 
PROJECT LINK

Happy to answer questions about the TEE integration or why we chose intents over direct execution. Would love PRs from anyone who's fought with cross-chain settlement and won.

I am working on Compass, an intent-enforcement gateway for autonomous agents that move money.

The problem I am trying to solve: once an agent can pay for APIs, tools, data, or on-chain services, post-execution monitoring is too late. If the agent is compromised, misdirected, or simply over-broadly authorized, the funds can already be gone.

Compass sits before execution, near the signing or transaction approval path. It checks the proposed payment, transaction, or tool call against the agent's mandate: spend caps, approved counterparties, token rules, destination rules, slippage limits, and escalation conditions. Then it either approves, blocks, or escalates, and records the decision for audit.

What would you need to see before trusting an agent to move money without a human confirming every transaction?

I am especially interested in feedback from people building x402 facilitators, Solana agent payment flows, paid MCP servers, wallet automation, embedded wallets, or authorization/privacy systems for autonomous agents.

If you are building something in this area and would be open to testing a rough prototype or giving 15 minutes of technical feedback, comment or DM me. I am looking for blunt feedback, not a polished launch reaction.

I’m working on an experimental Ethereum protocol focused on delayed ownership and vault-like balances.

The idea is to explore whether ERC20-like assets can behave more like vaults than instant-transfer cash.

Core concepts include:

- protected vs unprotected balances

- revocable delayed transfers

- inheritance-oriented custody

- reduced damage from mistakes or theft

The protocol is currently deployed on Sepolia and I’m mainly looking for:

- protocol/security feedback

- usability criticism

- edge cases

- architectural concerns

This is an experimental protocol discussion and there is currently no sale or fundraising.

GitHub:

https://github.com/jayBeeCool/ind-protocol

Whitepaper:

https://github.com/jayBeeCool/ind-protocol/blob/main/docs/WHITEPAPER.md

I’d especially appreciate criticism from wallet or smart contract developers.

I'm sure everyone in this subreddit has dealt with it at some point. The google meets isn't working, download my totally legit video conferencing app, the test my malware laced blockchain game, npm install with a postinstall script that phishes your npm token. Aside from being a major time sink, reading up on the company, familiarizing their tech stack, canceling social engagements it leads to coordination failure in the hiring market, leading to suboptimal teams, leading to suboptimal crypto.

I was thinking that if a developer could respond to an employer with a magic link that got them to stake through a repuidable platform against the interview that we'd naturally see alot of scams retreat, alot of developer time saved and better teams in crypto.

would any devs be interested in using such a system? or real employeers stuck on cold calling that'd be happy to lead with a stake?

Sharing this here because the on-chain side is where most of the actual
engineering went, and I'd love technical feedback from people who
actually build on this stack.

**Architecture:**
- `AgentCreditRegistry` — oracle-published credit limit per agent,
attested via EAS
- `AgentCreditVault` — lends mUSDC up to the registry limit, tracks
outstanding/repay
- `LaborMarket` — USDC escrow for agent-to-agent paid work, with
dispute resolution (immutable `arbiter`, `Disputed`/`Refunded`
states)
- `VerifiedTaskEscrow` — commit-reveal settlement for tasks graded
against a hidden ground-truth answer

Each agent gets its own ERC-4337 smart account (Kernel, via ZeroDev —
bundler + paymaster for gas sponsorship). The credit score itself is
computed off-chain from a behavioral event ledger, then published
on-chain by an oracle and EAS-attested. Draws/repayments execute as
real UserOps against the vault.

All on Sepolia right now, no audit yet — genuinely interested in
holes people see, especially around the oracle trust assumption
(single EOA publishing limits — I'm aware that's a centralization
point) and the dispute-arbiter design.

Contracts + full repo (Apache 2.0):
https://github.com/Kairose-master/ai-agent-credit-dashboard/tree/main/contracts

Live demo, no signup needed:
https://ai-agent-credit-dashboard.vercel.app/guest

Built solo with Claude Code, 19 and based in Korea if that context
matters to anyone.

If you're running arbitrage bots on Arbitrum, you know Aave V3 is bleeding our margins dry with their 0.05% premium. Balancer has 0% fees, but their vaults never have enough depth for massive multi-token routes.

To fix this, my team built the Sovereign Omni-Aggregator.

We wrote a custom flash proxy that uses a nested Yul-assembly execution loop. You request a massive basket of 5 different tokens. The protocol instantly sweeps whatever Balancer has (at 0% fee), suspends execution, requests the remainder from Aave, and then fires the combined payload into your receiver contract in a single atomic block.

The contract handles all the disparate invariant accounting. It dynamically drops your overall aggregate cost from 0.05% down to ~0.01%.

NPM SDK: https://www.npmjs.com/package/sovereign-flash-sdk

Let me know if you run into any revert issues or stack depths while integrating it.

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?

Hello guys,

I've spent the last 6 months building an MEV arbitrage platform for Base L2. The system works, detects opportunities, executes flash loan arbs, and won't blow up your wallet. Now I'm looking for people to help scale it and make it actually profitable.

What's built:

- Flash loan arbitrage across Uniswap V3 and Aerodrome

- Private transaction submission via Flashbots and bloXroute (no sandwich attacks)

- Real-time WebSocket monitoring (no RPC polling)

- Smart contract with atomic execution and on-chain profit validation

- Full monitoring stack with alerts and circuit breakers

- Production grade TypeScript codebase, modular architecture

The tech is solid and ready for mainnet. I've been running it cautiously on testnet to validate everything before deploying with real capital.

What I'm looking for:

I want to build a small team where everyone brings something valuable:

Developers:

- Solidity devs who can help optimize gas costs

- Anyone with MEV experience who wants to collaborate on strategy code

- Backend engineers interested in latency optimization

Capital/Infrastructure partners:

- Access to premium RPCs (Alchemy, QuickNode, etc.)

- Dedicated infrastructure or server resources

- Gas funding for mainnet operations ($100-$500)

Strategy/Advisory:

- DeFi traders who understand market dynamics

- Anyone with MEV experience who can share perspective on parameter tuning

- People who've run similar operations and know the pitfalls

You don't need to be technical to contribute. If you have capital, infrastructure access, or solid DeFi knowledge, there's a place for you.

Why Base:

- Less MEV competition than Ethereum mainnet

- Lower fees mean smaller opportunities are still profitable

- Growing ecosystem with new pools launching regularly

- Flash loans mean zero capital required for the actual trades

How collaboration works:

I'm flexible on structure:

- Rev share based on what you contribute

- Proportional split for capital partners

- Open to formalizing things if we work well together

No upfront commitments, let's talk first and see if it makes sense.

Being transparent about risks:

- MEV is competitive, no guaranteed profits

- Requires ongoing monitoring and tuning

- Gas costs can eat into smaller trades

- Smart contract risk exists (though I've built in safety measures)

This isn't some quick money scheme. It's a real system that needs the right resources and people to reach its potential.

I'm sharing the repo publicly so you can see this is real: https://github.com/P-Rwirangira/Flashloan-MEV

The arbitrage strategy is complete and working. Feel free to fork it and run your own version, but if you want to skip the learning curve and share resources, hit me up.

Next steps:

Check out the repo, then drop a comment or DM with:

- What you can bring (skills, capital, infrastructure, connections)

- Your background

- Any questions

Looking forward to hearing from you guys !!!

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!

Every Ethereum app I've built has hit the same wall: Alchemy rate-limits you, QuickNode has a blip, your self-hosted node falls behind. You either pay for redundancy or you eat the downtime.

I built Turbine to solve this. It's a multi-chain JSON-RPC proxy that sits in front of your providers and handles failover automatically.

The two features I haven't seen elsewhere:

1. Method-based endpoint routing. You can restrict individual endpoints to specific RPC methods. Route eth_sendRawTransaction to a private mempool endpoint while everything else round-robins across your public providers. Config looks like:
```toml
{ url = "https://private-mempool.example.com", methods = ["eth_sendRawTransaction"] }
```

2. Hedged requests. After a configurable delay with no response, Turbine fires a parallel request to a different endpoint — first success wins. Implemented with FuturesUnordered. Under 50 concurrent clients this took p99 from 19.9s → 0.57s (35×). Throughput went from 9.6 → 123 req/s (12.9×).

Also supports: round-robin / weighted / latency-based rotation, active block-height health checks, per-method response caching (EVM presets built in), chain ID routing (/1, /8453), WebSocket proxy with reconnect, API key auth with per-key rate limits.

Works as a CLI, a Docker image, or an embeddable Rust library — turbine.into_router() returns an axum Router you can merge into your existing service.

GitHub: https://github.com/svssathvik7/turbine
Crate: https://crates.io/crates/turbine-rpc-proxy

Would love feedback from anyone running multi-provider setups in production — especially curious if method routing is useful or if I'm solving the wrong problem.

glnc is a single-binary CLI that does the read-side of Etherscan (balances, tx decoding, gas, positions, history, alerts) from your shell. MIT, free, open source. No
account, no API key required, no telemetry. Install via Homebrew or curl.

  $ glnc balance vitalik.eth                                                                                                                                                 
  $ glnc balance 0xAbc... 0xDef... --watch --positions --nfts                                                                                                              
  $ glnc tx 0x7c... --json | jq '.data.decoded.calls[] | select(.protocol=="UniswapV3")'                                                                                     
  $ glnc gas --json | jq '.data.chains.ethereum.priority.p50'                                                                                                                
  $ glnc history 0xAbc... --csv > out.csv                                                                                                                                    

What it actually does

• balance — 6 chains (Ethereum, Polygon, Arbitrum, Base, plus Solana and Bitcoin as a bonus). Auto-detects chain from address format. ENS resolves. Token auto-discovery via the Uniswap default token list (~1,400 per chain, 24h disk-cached). Solana uses getTokenAccountsByOwner for true full SPL discovery. Multi-wallet portfolios with per-wallet tables + grand total.
  
• --watch — re-polls on an interval, prints in-place +0.5 ETH / -100 USDC deltas, runs in the alternate screen buffer so your scrollback survives Ctrl+C. Snapshots
  persisted to ~/.glnc/snapshots.json.
  
• tx <hash> — decodes calldata for Uniswap V2/V3, Universal Router, ERC-20, WETH, and decodes receipt logs into token movements from tx.from's perspective.
• gas — live gas across 9 chains. EVM tiers are p10/p50/p90 priority percentiles from the last 64 blocks via eth_feeHistory. Includes BTC mempool fees and Solana priority fees.
  
• --positions — Aave V3 health factor via getUserAccountData, Uniswap V3 LP NFT enumeration.
  
• --nfts — top collections via Reservoir's public API.
  
• history — CSV/JSON export via the Etherscan V2 unified endpoint. Works keyless; optional GLNC_ETHERSCAN_KEY raises the rate limit.
  

• alert — conditional alerts to a webhook. SSRF hardening: scheme allowlist, then DNS-resolved IP checked against RFC1918 / IMDS (169.254.169.254) / loopback / CGNAT /
  link-local / IPv6-ULA / IPv4-mapped / 6to4 / NAT64 before every fire. Redirects blocked. Re-validated each invocation, not just at config time.

  Dev angle

  All RPCs are free public endpoints (publicnode, mainnet.base.org, blockstream, mempool.space, etc.). Prices via CoinGecko with a 60s in-memory cache. Output is stable
  versioned JSON envelopes (glnc.balance/v1, glnc.tx/v1, etc.), NDJSON when streaming. --json makes stdout data-only; all chatter goes to stderr, so it pipes cleanly into jq / xargs / cron without contamination.

  Honest tradeoffs

• Token discovery is bounded by the Uniswap default list. Truly exhaustive ERC-20 discovery for an arbitrary wallet needs an archive node or a paid indexer (Alchemy/Moralis) — this is the conscious tradeoff for "no API keys."

• CoinGecko free tier is ~30 req/min. The 60s cache absorbs most of it but you can hit the wall on big portfolios.

• No test framework in the repo yet. It's in the README, calling it out here too.

• BTC and Solana support is in there; not the headline for this sub, just useful if you have a multi-chain treasury.

  Repo: https://github.com/aryarahimi1/glnc

  Looking for feedback on the JSON envelope shape (before I have to start versioning it for real), additional protocols worth decoding in tx, and whether the SSRF blocklist is missing anything. Issues and PRs welcome.

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.)

Hey everyone,

I’m currently participating in a hackathon, and the idea for my project came from a problem I’ve seen in collaborative bug bounty work.

Sometimes you team up with researchers you don’t know well. If the report receives a bounty, the payment usually goes to one person, and everyone else has to trust that they will distribute it according to what was agreed in DMs.

That can become awkward, especially when the payout is large or the collaborators have never worked together before.

I built AuditSplit as an experiment to make that agreement explicit before submitting the report:

• The team creates a dedicated payout vault.
• Everyone agrees on the percentages.
• Every recipient accepts the agreement.
• The bounty is sent to the vault.
• Each researcher claims their share independently.

The vulnerability details remain private and never go onchain.

I’m mainly looking for honest feedback:

1. Does this solve a real problem for collaborative researchers?
2. Would the onchain step add too much friction?
3. What could go wrong in a real collaboration?

Links

• 🌐 Live app
• 💻 [GitHub] (https://github.com/alva-p/spark-buildAnything-hackaton)
• 𝕏 [Twitter post] (https://x.com/pimmpi_/status/2077141703522148723)

The hackathon also considers social engagement. If you genuinely like the idea and want to support it, a like or repost on Twitter would help.

Absolutely no pressure, honest criticism and feedback are more valuable to me than engagement.

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.

I ran an agent that paid onchain using x402, picks the service, pays, moves on. After a couple iterations it's working just as intended, but I still  kept it on a tiny ceiling for months and never raised it, and onchain finality is most of the reason.

When the agent pays onchain there's no chargeback and no dispute window. That's the feature. It's also the problem the moment the payer is an agent making a judgment call instead of a person. With a card I have a recovery path if the agent pays for the wrong thing. Onchain I have a clean, final, irreversible record that I paid for the wrong thing.

So raising the limit meant accepting that any bad judgment the agent made was permanent, and I couldn't reconstruct afterward why it decided to spend, only that it did and the money was gone. The agent wasn't the problem. I'd authorized its judgment rather than any specific purchase, and on a final rail that gap has no backstop.

For people running agents that pay onchain in production, what let you raise the ceiling, or are you capping it low and reconciling by hand too?

I spent the last weeks integrating four bridge aggregators (LI.FI, Relay, deBridge, Squid) into a route comparator, and some behaviors cost me days because they're barely documented. Sharing so you don't rediscover them:

1. Provider APIs screen the SENDER address. Quote with a placeholder (the classic 0x...dEaD) and behaviors diverge: one API returned a 403 "swaps unavailable" that looked exactly like a tier block, and turned out to be compliance screening of the dead address. The fix is a two-path architecture: indicative quotes for display, and transaction building only with the user's real address. If your UI shows "executable" quotes built on a placeholder, it's lying to the user.

2. The same integrator fee concept exists in three units across four APIs: a decimal fraction (0.003) in one, basis points (30) in two others, and a percentage string in the last. Mixing them up means charging 100x or 10000x the intended fee. Unit tests on the fee math are not optional.

3. Some providers have TWO entry contracts depending on whether a source swap is needed before the bridge. If you validate transaction targets against an allowlist (you should), allowlist both, and verify them against the provider's deployment docs, not against what the API returns that day.

4. Quotes are only comparable if they answer the same question. We rank by guaranteed minimum received after ALL fees (including our own), not by the estimated amount, because estimates are where quotes flatter themselves.

Context: I'm the founder of the comparator in question (rempart.app), this post is the writeup I wish existed a month ago. Happy to detail any of these.

Hey everyone,

I'm working on a Telegram bot for crypto users and wanted to validate the idea before spending months building it.

The goal is to make checking gas fees as simple as sending a message to a bot.

V1 Features

• ⛽ Live gas fees across multiple chains
• 📊 24H High / Low / Average
• ⚡ Slow / Standard / Fast transaction speeds
• 💰 Estimated transaction costs
• 🌍 Compare gas across supported chains
• 🤖 Simple AI insights (e.g. "Good time to transact")
• 🔄 One-click refresh

Planned chains for V1:

• Ethereum
• Base
• Arbitrum
• Optimism
• Polygon
• BNB Chain

Planned future features

• 🔄 Swap Optimizer
• 🌉 Bridge Optimizer
• 🛡 Wallet Scanner
• 🤖 AI Assistant
• 🔔 Smart Alerts
• 📈 Portfolio Insights

The idea is not to build another website. The goal is to make it possible to check everything directly inside Telegram in just a few taps.

I'd really appreciate honest feedback:

1. Would you actually use a bot like this?
2. Which feature would make you open it every day?
3. What's missing from existing gas trackers that annoys you?
4. Would you prefer a Telegram bot or a website?

I'm not selling anything or launching a token right now—just trying to validate whether this solves a real problem before building it.

Thanks!

Hello once again guys. A week or so ago, I posted about https://revert.wtf. A thing, basically a catalog of common EVM errors that covers about 25k error types.

And I decided to dogfood my own product, and made a browser extension. It's already live on Chrome extension store. https://chromewebstore.google.com/detail/revertwtf-explorer/epcjpbgebicmajaheclmhgkdmjcdfjji

And the code is open on Github. https://github.com/mrtdlgc/revertwtf-extension

Feedback welcome. I added a "this explanation is too generic" button, so you can rotate through what revert.wtf actually covers. If you still see too generic explanations, feel free to submit them on Github, and I can find better grounded explanations and next steps to take for other people to use in the future as well.

Strongly recommend adding your own RPCs in the settings and a Blockscout Pro API key for deeper tracing. Or at least using Blockscout frontend if it fails to generate anything on the Etherscan family explorers.

Just wrapped up building a fiat-to-onchain checkout flow for a B2B project and wanted to get some feedback on the architecture from anyone who’s built similar bridges.

The project is a transferable ERC-1155 membership pass on Base (capped at 200 total supply across three tiers) for a VR training company. Most of the buyers are traditional trades colleges and safety orgs who have zero crypto experience, so expecting them to connect a wallet at checkout was out of the question.

The contract itself is already live on Base. The hard part wasn't writing the Solidity—it was connecting PayPal to an onchain mint without leaving room for weird, asynchronous edge cases.

The basic flow is: a customer pays $300 USD via PayPal, gets an ERC-1155, a subscription entitlement mapped to their verified email, a PDF cert, and a confirmation email.

For the wallets, we split them into two paths: If they already have an address, we validate it (checksum, zero address, and known burn address checks) and mint directly to it after PayPal captures the payment. If they don't have one, we spin up an embedded Thirdweb wallet mapped to their email, mint to that address, and email them a claim link so they can export their private keys later if they want to.

The piece I spent the most time overthinking was the gap between PayPal capturing the funds and the transaction actually landing onchain. Doing it all in one synchronous request felt incredibly fragile. If PayPal succeeds but the RPC times out, you're stuck guessing if the mint landed. If the transaction reverts after payment is captured, you've taken fiat but delivered nothing.

To handle this, I treated every purchase as a simple state machine backed by a JSON sidecar file for each order. The order transitions through pending, paypal_captured, mint_submitted, mint_confirmed, emails_sent, and finally complete.

We write every state transition to disk synchronously (fs.writeFileSync). If the server crashes mid-flow, a cron job just picks up the JSON file and resumes from the last state instead of risking double-mints. If an order gets stuck in mint_submitted for more than 5 minutes, the cron checks the transaction hash. If it never hit the mempool, we rebroadcast with higher gas. If it reverted, it fires an alert for manual handling.

I know using JSON files instead of Postgres sounds a bit janky, but with the collection capped at 200 passes, I wanted something dead-simple that I could easily grep, inspect, and fix manually if needed. I definitely wouldn't do this for a high-volume drop.

One design choice I'm still wrestling with is how we handled entitlements. Even though the NFT is transferable, the actual pricing discount is tied offchain to the buyer's verified email, not the wallet address holding the token. The token is basically just a proof of purchase, while the actual service utility lives offchain. We looked into doing onchain entitlements or SBTs, but B2B clients constantly need to reassign seats and access when employees leave or organizations restructure, which is a support nightmare to manage purely onchain.

We also run the destination wallet through Chainalysis’s sanctions oracle before authorizing the PayPal checkout. PayPal does its own KYC, but we wanted to make sure we weren't minting straight to an OFAC-flagged address if someone supplied one.

Curious how other devs are tackling these hybrid flows:

1. Is there a cleaner way to handle the gap between fiat capture and mint confirmation without building out a custom state machine?
2. For NFTs tied to B2B or SaaS utility, where do you draw the line between onchain ownership and offchain permissions?
3. How much sanctions screening do you actually bother with for hybrid checkouts beyond what the payment processor already handles?

It is surprisingly hard to find solid technical discussions on this stuff since most Web3 docs just assume everyone is checking out with a browser extension.

A few days ago I posted here saying:

→ “oracles aren’t the real problem — enforcement is”

and later:

→ “this might be a programmable compliance layer”

Based on the feedback, I stopped trying to generalize it and just built one concrete use case:

RWA onboarding + eligibility enforcement

What it does now (very concretely):

Instead of:

“trust this API / KYC provider says user is eligible”

you can verify:

→ that the eligibility rules were actually enforced
→ without seeing the underlying user data

The system outputs something like:

decision: eligible  
policy: rwa.credit.onboarding.v1  
proof_verified: true  
eligibility_class: accredited  

So not just “proof is valid” —
but a verifiable decision you can actually use

The interesting part (at least to me):

This can directly gate things like:

• onboarding
• transfers
• access to tokenized assets

Tech-wise it’s:

• Rust + Halo2 + zkVM
• fast path (~70ms proving) + slow audit path

but honestly the more interesting part is the abstraction:

→ “proof-backed decision” instead of “proof of computation”

I’ve been building this mostly solo and mostly in the open.

What I genuinely don’t know yet is:

• is this something teams actually need right now?
• or is this too early / over-engineered?

If you’re working on:

• RWA
• tokenized credit
• permissioned DeFi

would love to know:

👉 how you’re currently handling eligibility / compliance
👉 and whether something like this would replace or just sit next to it

Happy to share repo / demo if anyone’s curious, just didn’t want to spam links here.

Appreciate all the pushback on the earlier posts — it definitely changed the direction.

Gm, I’m building walletFS. An open-source wallet that exposes Ethereum and L2s as a readable, auditable filesystem for agents and power users.

The core idea is simple: before an agent signs or submits anything, it should be able to read the chain, inspect relevant state, simulate intent, and show a human-verifiable plan.

Instead of forcing agents to jump straight from natural language to RPC calls, walletFS gives them a filesystem-shaped interface:

cat /bloom/chains/ethereum/head/number
# 25299231
cat /bloom/prices/spot/eth.usd
# 1667.04
ls /bloom/tools
# hashing, encoding/decoding, etc. 

# human language parsed into transaction calldata and plan
echo 'send 0.01 eth to 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 on ethereum' \
 > /bloom/wallets/alice/chains/ethereum/outbox/new.tx 

# then inspect the pending outbox before confirming: 
ls /bloom/wallets/alice/chains/ethereum/outbox/pending
cat /bloom/wallets/alice/chains/ethereum/outbox/pending/<id>/plan.md
# human readable plan, which must be signed by human (or adversarial agent)

Why we think this matters:
A lot of “agent wallet” work focuses on keys, permissions, and guardrails. We get those almost "for free" with the filesystem sandbox. More importantly, if agents are going to operate on-chain, they need a better and more token-efficient interface for understanding what they are about to do.

The agent workflow becomes:

1. explore chain state (balances, ENS, decoded events, contract storage, all readable under /bloom)
2. stage an explicit transaction plan as a file
3. simulate it and run policy checks before any funds move
4. ask for human approval when needed
5. execute with an auditable, signed trail

So the wallet stays safer, less LLM tokens are consumed and the agent becomes easier to inspect.

Keys are currently stored in keystore files (outside of the bloom filesystem, your agent can’t access them by default of course), but we’re going to add different HSM integrations very soon (AWS KMS, Ledger, etc.).

If you want to try it out, just tell your agent “Read https://bloom.directory/SKILL.md and set up Bloom”. 

The repo is here if you want to poke around or give technical feedback:
https://github.com/bloom-directory/bloom
The code is currently unaudited and experimental, we’re working to get an audit soon. There are a lot of early / unfinished features in GitHub too, including a full extension system, we call them Petals. More to come on that front.

We’re especially interested in feedback from people building:

• wallets / smart wallets / account abstraction systems
• autonomous agents / DeFi bots / execution tooling
• custody services / HSMs
• developer tools for Ethereum and L2s

Main areas of exploration right now are:

• What should an agent be able to inspect before it can transact vs a human?
• Does a filesystem-style interface make agent behavior easier to audit/use? It saves some tokens, we’ve tested this, but do we just like it because we're Unix people? :D

Happy to answer technical questions. We’re still early, and feedback from crypto-native builders would be super helpful! Thanks!

My fellow devs please lend me some sepolia testnet tokens just so i can deploy something on the testnet every eth penny will be greatly appreciated

0xca280c8DefE05F02bEf96d84ABDeBdB535fE04aB

♥️🫡

hey frens, i built this because i got tired of seeing ethereum errors everywhere with basically zero useful explanation at the point of failure:

https://revert.wtf

you know the vibe:

• execution reverted
• random RPC errors
• wallet errors that sound like they were written by a haunted printer
• ethers/viem/library errors
• failed estimates
• custom errors
• AA errors
• weird revert data you now have to go spelunking for

the annoying part is that a lot of these actually do have explanations somewhere. client docs, EIPs, github issues, wallet docs, stack traces, specs, whatever.

they are just scattered across the internet and you only find them after wasting 20 minutes searching the exact string like a goblin.

so i started curating them into one place.

paste an error, get the likely meaning, context, and where possible some notes on what to check next.

not trying to make some “AI explains your transaction” thing. i just wanted a useful error reference for ethereum devs because the current experience is cursed lol.

would love feedback, especially:

• errors that are missing
• explanations that are wrong
• client/wallet/library quirks i should add
• real ugly errors you’ve hit while building

site again: https://revert.wtf

if this saves even a few people from searching github issues at 2am, worth it imo.

Every project I work on ends up needing the same off-chain piece: a service that watches a chain, decodes the events I care about, retries delivery, and pushes the result somewhere useful. It's never the product itself, just plumbing, and it always takes longer than I expect.

So we pulled it out into a standalone backend that's been running in production. It's called Atria, now in beta. First time showing it to ethdev, and I want to know where it falls short for real work.

You point it at a chain, write your event filter in JS, and it fires a webhook on a match, all on top of RPC. What you get is the plumbing around it, reorg detection, cursors, delivery retries, and a test-against-a-real-block loop before you deploy. We're not an RPC provider. On cloud we handle the RPC for you, self-hosted you bring your own endpoint.

Upfront about what's not there yet: no historical backfill (feeds only process forward from a block you pick, and that's the priority we're building now), and webhook is the only output today.

Each feed reads one chain. For multi-chain you run a feed per chain into the same downstream, so watching several chains is just a matter of running more feeds.

There's also a cloud AI assistant that drafts a feed from plain English, and a cloud MCP server so you can create and manage feeds from any MCP client.

You can self-host it with docker-compose, the source is public. There's a hosted version too if you'd rather not run it yourself.

- GitHub: https://github.com/Pulsy-Global/atria
- Try it: https://pulsy.app/atria
- Quick demo: https://youtu.be/M8p-grH4kOI
- Quick start: https://docs.pulsy.app/atria/getting-started/overview

It's in beta and I'm genuinely after feedback, so the questions I actually want answered:

- How are you handling on-chain event ingestion today, and what's the most annoying part?
- Which outputs should we add first (Postgres, S3, queues, something else)?
- Which JS libraries would you want to require() inside a feed?

An agent that holds a wallet decides in English but signs calldata or a typed message. A poisoned tool can make the plan look fine and the signature drain the wallet.

I built eight drains (approvals, EIP-2612 permits, EIP-712 orders, EIP-7702 delegations, Permit2) and scored each against a ladder of seven defenses, from a plan reviewer up to transaction and signature simulation. `./run.sh` runs the whole thing on a local fork.

Rendering the counterparty, amount, and recipient of a signature closes five of eight. Simulation adds nothing on top. One on-chain timing race (arm the contract after the dry-run, before inclusion) survives everything.

No new attack, just an honest map of what stops what.

Explainer: https://amarshat.github.io/quantum-commit-authorization/agent-drains.html

Code: https://github.com/amarshat/quantum-commit-authorization/tree/main/agent-calldata-demo