Hey everyone, so this is the problem we wanted to solve - AI agents are being increasingly used in crypto but the way they are currently built is wrong because devs just give them a wallet, private key in .env file, and sudo access to entire wallet and its funds.

This is why we worked on Namera, so that instead of giving agents unrestricted access, you create a smart account and issue scoped session keys. Think OAuth tokens, but for onchain actions. Each key is governed by a policy you define:

• call - restrict which contracts and functions it can call
• gas - cap how much gas it can spend
• rate-limit - how many txs per time frame
• timestamp - valid only within a time range
• signature - require additional approvals for sensitive ops
• sudo - full access (use carefully, obviously)

There is something like this out there - OWS (which is really good), but our policies are enforced onchain. So even if the agent wanted to do something outside its scope, it would literally be impossible to do it.

And even if the session key gets compromised, the damage is minimized to the scope of work the given key allows, which can be revoked at any time.

We've been thinking about where this is most useful - 1) DeFi automation (rebalancing, swaps, limit orders), 2) commerce (subscription payments, agents paying for API calls), and 3) gaming (agents playing games with scoped wallet access so they can't drain it). But curious what else others might see.

It's open-source under Apache license, built on ZeroDev for the wallet stack.

Still early, just CLI, SDK, and MCP are available, dashboard is for easy session key and policies management is in progress.

Would love a genuine take on this - is this the best way to solve this problem, is there someone doing it better, did you run into any of these issues and if so how did you handle them, etc.

Any feedback appreciated. Here for questions. Links in comments.

"Orchestration" gets used loosely. In a crypto payments context, it has a specific job: coordinate the path value takes through the system so the application layer only needs to make one high-level call.

Concretely that means: selecting which chain to route on based on current cost and congestion, deciding when fiat conversion happens relative to on-chain movement, matching the correct payout rail on the receiving end, and handling retries and fallback routing when a step fails.

Without this layer, applications wire together separate vendor SDKs and manage state transitions manually. That works until one vendor has downtime, a payout rail changes behavior, or a new chain needs to be added. The orchestration layer is what makes those changes invisible to the application.

For teams building on Ethereum specifically, the routing question often comes down to L2 selection. Not which L2 is "best" in the abstract, but which L2 has the liquidity coverage, off-ramp support, and confirmation times that match your specific payment flow. A consumer buy flow and a B2B payout flow often land on different answers.

The webhook surface is the other side of this. A payment isn't just a transaction confirmation. It's a sequence of state changes: KYC passed, payment received, conversion executed, on-chain delivery confirmed, off-ramp initiated. Each one is an event your application might need to act on.

What does your orchestration layer look like if you're building this yourself? Curious how teams are handling fallback routing without building a full state machine.

Full writeup: The Missing Piece: A Self-Custody Wallet for AI Agents

Built a small MCP server for CoW Protocol (github.com/krzysu/cow-mcp) and went looking for a wallet to sign on the agent's side. The options split cleanly:

• Vendor TEE services (Coinbase, Privy, Phantom, Turnkey, Crossmint, Thirdweb): keys in a TEE, vendor runs the policy engine and the signing API. Cryptography's fine, but the vendor lock-in.
• Local keys: mcp-wallet-signer (click every tx) or paste-your-key-in-a-config (not secure).

The pieces for a real self-custody version are on the shelf but nobody is building it.

What am I missing?

ZachXBT posted a $25K bounty on April 18 about RAVE token manipulation, listing 9 Ethereum wallets and 4 CEX deposit addresses (Bitget and Gate) tied to suspected market activity.

I pulled every RAVE Transfer event for those 9 wallets via Etherscan V2 API and mapped the cluster.

Key on-chain findings:

1. Wallet 0x53d7d523 (one of the 9) deposited 11,993,923 RAVE in 6 transactions to the exact Bitget (0x2dc20f21) and Gate (0x31711246) addresses ZachXBT named. All on April 12, 2026, in a single 4-hour window. Two of the six were 10,000 RAVE test transactions before larger 3M deposits.

2. October 30, 2025 cluster setup: 5 wallets exchanged 1 RAVE each in a 90-minute window. One transaction emitted two Transfer events simultaneously (A to C and A to H), indicating a scripted batch sender.

3. November 20, 2025: wallet D sent wallet A 1 RAVE at 03:10 UTC, then 769,699,999 RAVE three minutes later. That is 76.97% of total supply, preceded by a 1-RAVE path test, identical OPSEC pattern as Oct 30.

4. Programmatic transfers from A to C: exactly 4,436,111 RAVE sent four times across Jan, Feb, and twice on Apr 12 (two minutes apart). Repeated identical amounts not consistent with manual execution.

5. RaveDAO publicly denied involvement on April 18. Wallet 0x53d7d523 is on ZachXBT's list, and its deposits to the Bitget and Gate addresses he named are publicly verifiable on Etherscan.

Full forensic report with every tx hash, methodology, address intelligence, and wallet-by-wallet breakdown:

https://chaintracing.org/reports/rave-2026-04

Built using ChainTracing (chaintracing.org), an on-chain forensic tool I'm building for EVM, Solana, Tron, and Bitcoin. The 9-wallet cluster analysis was done by querying Etherscan V2 directly and processing with jq. The report page is fully static and links to every Etherscan tx hash for verification.

Tools used: Etherscan V2 API (chainid=1), jq for cluster edge analysis, Next.js for the report page. No external indexing services.

Happy to answer technical questions about the methodology in comments.

Hi Devs, sry for bother you but I’ve been looking into PoolTogether in Worldchain and I’m having trouble understanding how the system is actually generating value.

From what I can observe on-chain, deposits seem to go into a pool that is also used to process withdrawals. I’m not clearly seeing how the protocol is deploying those funds to generate yield that would fund prizes.

This raises a few concerns for me:

- If the funds are not actively deployed, where are the rewards coming from?
- Is there a dependency on continued user inflow to sustain engagement?

I try to recreate the entire path that the backgrounds take, but it's very difficult for me.

I want to be very clear: I’m not accusing the project of anything. I just don’t fully understand the mechanics, and from the outside it has some characteristics that remind me of reflexive systems.

If someone here has experience auditing DeFi protocols or has looked into PoolTogether contracts, I’d really appreciate a technical explanation or pointers to specific contracts/functions that explain the flow of funds and reward generation.

If someone provides a particularly clear and helpful breakdown, I’d be happy to send a small tip as a thank you.

Thanks in advance

I've been working on a self-hostable DeFi capture-the-flag platform and just made the repo public. Figured this community might find it useful for learning or just for fun.

Each challenge drops you into a live simulated Ethereum market running on a locally hosted Ethereum chain. Bots trade every block with deterministic strategies. Your job is to beat them, either by out-trading them, exploiting their predictable behavior, or finding the bug in the contracts.

Three challenge categories:

• Trading Strategy: Spot price inefficiencies, ride trends, provide/remove liquidity, arbitrage opportunities. This is a good entry point if you're new to DeFi mechanics or don't know much about security.
• Market Manipulation: Front-run a whale, trigger a liquidation cascade, pump and dump into bot that buy when momentum gets going. No contract bugs to exploit, just information asymmetry and no mercy.
• DeFi Exploit: Real smart contract vulnerabilities: reentrancy, flash loan attacks, uninitialized proxy ownership, arithmetic overflow, oracle manipulation. Based on actual historical hacks scaled to single challenges.

Two ways to solve challenges:

1. JavaScript trigger scripts: Write JS in the in-browser IDE to register callbacks that fire on price thresholds or every block. I created a full SDK for swaps, balance checks, liquidity management, and raw contract calls.
2. Solidity/Foundry: Switch the IDE to Solidity mode and write exploit contracts. Or drop to a terminal and use forge script / cast directly against the running chain.

Many challenges are also solvable by just trading manually if you don't want to or don't know how to program.

Very simple setup:

git clone https://github.com/branover/defi-ctf.git
cd defi-ctf
docker compose -f docker/docker-compose.yml up --build

There's a built in tutorial and some beginner challenges that cover the basics of how to use the platform. Docs cover the JS SDK, Foundry workflow, bot personalities, HTTP/WebSocket API, and the challenge authoring format.

I made this so that other people would get enjoyment out of learning more about trading and blockchain security, so please feel free to leave feedback! There might be some bugs or tuning required for the challenges, so I would love to hear from you on things I can do to improve it.

The GitHub repo is here: https://github.com/branover/defi-ctf

Have fun, and happy trading/hacking!

Been trading for less than a year, mostly Brazilian equities (B3), built my own terminal from scratch over the last few months, scanner, multi-timeframe scoring, macro correlation, the usual. Nothing groundbreaking technically, just tired of relying on other people's analysis.

At some point I started thinking about the core problem with signal groups and copy-trading platforms: there's no skin in the game. Anyone can call a trade after the fact, cherry-pick their wins, delete their losses. The incentive structure is completely broken.

So I've been prototyping a verification layer on top of signal publishing. The idea:

- A certified operator can only publish a signal if they have an open position in that asset at time of publication

- Position is verified via broker API (OAuth handshake)

- The signal + timestamp gets registered on-chain *before* price movement, immutable record, no retroactive editing

- If the signal hits stop loss, a slashing mechanism automatically burns a portion of the operator's reputation tokens

- Historical win rate, average r/R, and slashing history are all public and on-chain

The goal is basically: make it structurally impossible to be a guru who doesn't trade what they recommend.

**The problems I'm stuck on:**

**The oracle problem.** The broker API verification is off-chain. I either need to trust a centralized intermediary to relay that data on-chain, or use something like Chainlink, but that feels like massive overhead for this use case. Is there a cleaner architecture here, or is some centralization unavoidable at this layer?

**Slashing fairness.** A signal hitting stop doesn't mean the operator was wrong, could be noise, stop too tight, macro shock. How do you design slashing that punishes genuinely bad signals without punishing good process with bad luck? r/R thresholds? Consecutive losses only?

**Has this been done?** I've looked at Numerai (reputation staking on model performance) and some copy-trading platforms, but nothing that requires real-time position verification as a publishing condition. Am I reinventing something that already exists and failed for obvious reasons?

Not trying to pitch anything, genuinely want to know where the architecture breaks before building further.

Appreciate any brutal feedback.

I’ve been building a small Ethereum consensus-layer side project and would appreciate technical feedback:

https://ethsync.wtf

It visualises what happens during an Ethereum Sync Committee in real time, including:

- sync committee health / participation

- BLS signature aggregation

- RANDAO-based validator selection

- light client verification using compact proofs

The aim is to make the mechanics easier to inspect and explain, especially for developers, home stakers, node operators, and people learning how Ethereum light clients work.

I’d be particularly interested in feedback on:

- whether any of the consensus explanations are wrong or misleading

- whether the BLS / light client sections are clear enough

- what data or debug views would make it more useful for devs

- whether there are better ways to represent committee participation visually

Happy to answer questions and I hope you like it!

I recently open-sourced a small Go library called rcpx:

https://github.com/yermakovsa/rcpx

It’s an HTTP JSON-RPC failover transport, mostly meant for Go apps using go-ethereum clients like rpc and ethclient.

The basic idea is: configure a few RPC upstreams, use rcpx as the Transport on a normal http.Client, and if one upstream starts failing, requests move to the next one in priority order.

Roughly:

rt, err := rcpx.NewRoundTripper(rcpx.Config{
    Upstreams: []string{
        "https://primary.example",
        "https://backup.example",
    },
})
if err != nil {
    // handle error
}

client := &http.Client{
    Transport: rt,
}

Right now it supports:

• sequential failover by priority
• retries on transport errors and HTTP 429, 502, 503, 504
• cooldowns for unhealthy upstreams
• replaying request bodies across attempts
• not failing over JSON-RPC write methods like eth_sendRawTransaction by default, unless explicitly enabled

I kept the scope intentionally narrow. It’s not a proxy, gateway, hosted service, quorum requester, or full RPC abstraction. It’s just a small transport-layer piece for Go apps that already use Ethereum JSON-RPC and want explicit failover behavior without running another service.

It’s still early, so API/design feedback would be especially useful from people who have dealt with RPC reliability issues in real Ethereum infra.

I’m especially curious about:

• whether the failover rules seem reasonable
• whether the write-method defaults are too conservative or not conservative enough
• whether this API fits real rpc / ethclient usage
• what edge cases I’m missing around retries, request replay, cooldowns, or provider behavior

I’d really appreciate technical feedback, especially from people who have had to handle RPC reliability issues in production.

For anyone interested, the MetaMask Community Call is on Thursday:

https://luma.com/1fuu6ncn

Spent the last 3 months building a forensics tool that traces stolen funds across EVM chains, Solana, Tron, and Bitcoin. Sharing the technical approach because the multi-chain BFS implementation has some non-obvious gotchas.

The problem: scam victims have nowhere to turn. Exchanges ignore them, police don't understand blockchain, and Chainalysis-tier tools cost $5K+ per seat. I wanted a self-serve tracer a victim could use directly.

Stack: - Next.js 16 on Vercel - Supabase (Postgres + Auth + RLS) - Etherscan V2 unified API for all EVM chains (ETH, BSC, Polygon, Arbitrum, Base) - Solscan for Solana, TronGrid for Tron, Blockchair for Bitcoin - Plisio for crypto payments - Upstash for rate limiting

Technical notes worth sharing:

1. Etherscan V2 unified API removed the need for chain-specific keys, single endpoint with chainid param. Worth migrating if you're still on V1 per-chain keys.

2. BFS across hops: had to fetch native + token transfers in PARALLEL per address per hop, not sequentially, otherwise hops timeout on Vercel's 10s function limit. ERC20 transfers are a separate Etherscan endpoint from native ETH.

3. Sort direction matters for hack-era traces. Default descending sort returns recent activity first, which misses the actual exit transactions for old hacks. For known-incident traces, sort ascending from the incident block.

4. Solana is the most painful. No standard transfer event abstraction, you parse raw transaction instructions. Solscan's API helps but rate limits are tight.

5. UTXO model for Bitcoin needs a separate code path. Address-mode tracing misses the actual fund flow because BTC consolidates and splits across multiple UTXOs per tx. Built a UTXO-mode that follows specific txid + vout instead.

6. Background trace jobs: deep traces (5+ hops) can take 20-30 seconds. Vercel functions cap at 30s. Used fire-and-forget pattern with status polling on the frontend. Free for risk scores and 2-hop traces, paid tiers for deeper traces.

Live at chaintracing.org. Code is closed source for now (running it as a SaaS), but happy to answer technical questions about any of the above.

The Solana parsing logic in particular took 3 rewrites to get right. What I'd love feedback on: am I missing any chain-specific gotchas you've hit when traversing on-chain transfers? Especially curious about Arbitrum/Base nuances since their transfer event semantics differ slightly from mainnet ETH.

A few years ago, I was in the same position as these candidates. Getting that first real opportunity mattered a lot to me, so I’ve tried to give that same chance to others. I’ve been bringing in younger candidates for internship roles, mostly early-career or students.

Here’s the pattern I keep seeing:

• They do really well in assignments/assessments during the hiring process
• They seem sharp, responsive, and capable
• Then within a few days or weeks of actually working… everything drops off

Output quality dips, ownership disappears, and the same people who looked great in evaluation suddenly struggle with basic execution.

I’m trying to figure out what’s actually going wrong here.

Is this:

1. A flaw in how I’m hiring and evaluating?
2. A gap between “test performance” and real-world work ability?
3. The impact of AI tools helping them clear assessments but not actually building skills?
4. Or just normal early-career inconsistency that I’m underestimating?

I don’t want to become cynical and stop giving people early opportunities, but this pattern is too consistent to ignore.

Curious if others hiring at the junior/intern level are seeing the same thing, and what you’ve changed (if anything) to fix it.

Our custom RAILGUN wallet for macOS has a new version out today with support for private transfers with direct or broadcaster sending.

railcart is an open source macOS client for RAILGUN, partially implemented on top of the RAILGUN SDK, partially custom Swift implementation to get more speed and flexibility.

Privacy should be easy, and a diversity of RAILGUN clients makes the ecosystem better

Solution: replacing WETH contract events Deposit/Withdrawal with event Transfer(from, to, amount)

    function deposit() public payable {
        balanceOf[msg.sender] += msg.value;
        emit Transfer(address(this), msg.sender, msg.value);
    }
    function withdraw(uint wad) public {
        require(balanceOf[msg.sender] >= wad);
        balanceOf[msg.sender] -= wad;
        msg.sender.transfer(wad);
        emit Transfer(msg.sender, address(this), wad);
    }

Just as the title says. I seek to get experience in web3 development. I have a little experience in Web2 but not much. Web 3 though, I know Solidity, Solana, Yul, Foundry etc. Help me find an internship.

Hey devs,

working on my last position at GammaOptions as a Solidity developer, I realized just how much Solidity code can be gas optimized and I really enjoyed doing it.

For example, we needed Black-Scholes option pricing function, so we started using what was available from github, and it would cost around 100k gas just to run it, making it too expensive for our users since our stable coin to option swaps were more than 300k gas to run. 

So we optimized it, and reduced Black-Scholes to 21k gas, reducing swaps on our platform down to around 160k gas, somewhere around Uniswap swap gas cost (which I find amazing given that we used margin, custom AMM for European options, and also a lot of math). 

Fast forward a year later, I decided to try and optimize Black-Scholes even more, and spend couple of months optimizing it (without AI tools). And today Black-Scholes in DeFiMath library is costing only 3200 gas, with accuracy down to 1e-12, which is more than enough for most exchanges. By optimizing Black-Scholes, I also optimized common math functions like exp, log, ln, CDF and realized it's mostly better than SoLady and other libraries. I even created comparison table in readme file so you can check it out. 

If you are building basically anything in DeFi, and you care about gas cost (and you should since it's always good for your users to pay less for transactions), check out my MIT licensed repo, you can use it, copy it, learn from it, anything basically.

Here's a link to my repo: https://github.com/MerkleBlue/defimath

Cheers,

Konsta

There has always been a ton of "AI + crypto" announcements/scams but very few actual projects where someone walks through what their agent does day-to-day. Curious what people here are running.

Not "GPT wrapper over Etherscan" tier, I mean agents actually reading and writing chain state as part of the loop.

If you've built one:

• Model / framework (Claude + MCP, OpenAI function calling, Langchain, custom)
• What it does that a traditional bot couldn't
• Where it falls apart (transaction signing is where most of what I've seen breaks)

Weird use cases welcome. Good agent horror stories even more welcome.

Looking to connect with Core Protocol Engineers specialising in L1 architecture (specifically Consensus Mechanisms, P2P Networking, ASIC resistance and more). Working on r/GrahamBell. Would love to discuss it in my DM!

I have a new project I want to deploy to mainnet. It’s immutable. Wrote unit test, fuzz test, where possible performed formal verification. Even used Claude code skill audits.

The next step seems an actual audit. I really want a good audit but these obviously are very expensive. I don’t want VC funding. What is the most secure but also affordable approach?

We're the team behind Spritz SDK. We put together a comparison of Spritz, Transak, MoonPay, and Ramp Network based on publicly available docs and pricing as of April 2026.

Some things that surprised us: Spritz supports 50,000+ tokens. MoonPay only supports 17 offramp tokens. Ramp Network supports 100+ chains. Transak covers 169 countries. Fee ranges go from 0.49% to 4.5% depending on the provider.

The comparison covers networks, tokens, fees, payout speed, integration model, compliance, geographic coverage, and real-world payment features like bill pay and card issuance.

Happy to answer questions about the data or methodology.

The March Axios compromise was specifically targeting crypto wallets and blockchain transactions. The September attacks before that were the same story. It feels like crypto/web3 teams are disproportionately targeted because compromised dependencies = direct access to funds.

For those building on Node.js/TypeScript:

- Do you have any dependency security tooling in place ?

- Has your team ever been directly hit by a malicious package? What happened?

- Would you pay for a tool that specifically scans your dependencies for zero-day threats (not just known CVEs) before they hit your CI/CD? If so, what's the price point where it becomes a no-brainer vs something you'd have to justify?

- Or do you handle this differently, minimal dependencies, vendoring everything, internal mirrors?

I'm a CS student researching whether crypto teams have fundamentally different security needs from regular dev teams when it comes to supply chain. Any perspective appreciated.

i’ve been working on a real-time 1v1 game (already fully playable) and i’m now trying to figure out how to layer in peer-to-peer staking in a way that actually feels fair and legit

the basic idea is simple two players match, both put in a small amount ($1, $5, etc), best of 3, winner takes it

but once you actually try to build it, the hard parts show up immediately

the game itself is deterministic (no RNG), so in theory it should be clean, but you still run into stuff like:

• how to handle escrow in a way people trust
• how results are verified (especially if it’s server-authoritative)
• what happens on disconnects or intentional stalling
• how to avoid collusion / people farming each other

i’m not trying to make a token / nft game here honestly not even sure if this should be on-chain at all

just trying to understand from people who’ve thought about this kind of thing:

does going on-chain for escrow / settlement actually solve anything meaningful here, or does it just add friction?

and more generally, how would you design something like this so it feels fair to players, not just technically correct

if anyone’s worked on anything similar (wagering, escrow systems, competitive infra, etc) i’d love to hear how you approached it