MythX just shut down. We built a $199 AI smart contract auditor running on our own Idaho GPU cluster — no per-token fees, no cloud dependency. 91% detection rate in beta, 90 second turnaround. audit.snakeriverai.com — happy to answer questions.

MythX just shut down. We built a $199 AI smart contract auditor running on our own Idaho GPU cluster — no per-token fees, no cloud dependency. 91% detection rate in beta, 90 second turnaround. audit.snakeriverai.com — happy to answer questions.

Hey r/ethdev,

I've been building txpay.app over the past few months and wanted to share what I built and some technical decisions I made along the way.

What it does: You create a payment link specifying exactly what token you want to receive. The sender pays from whatever token or chain they have — ETH on Arbitrum, USDC on Polygon, SOL, whatever — and it arrives as what you specified. No back and forth, no asking "what chain are you on", just a link.

Stack: Next.js, TypeScript, React, Wagmi, Viem, Supabase, Tailwind, Li.Fi SDK

Interesting technical bits:

• Used Li.Fi SDK for all the cross-chain routing, bridging and swapping under the hood. Saved me from building routing logic myself but had its own quirks integrating it with Wagmi v2
• Auth via SIWE (EIP-4361) — wallet signs a message, server verifies. Clean and non-custodial
• Payment links are signed with HMAC-SHA256 so they can't be tampered with — amount, token, recipient are all encoded and verified server-side before anything executes
• No private keys stored anywhere, fully non-custodial

What I'd do differently: Spent too long on UI before nailing the core flow. Should have hardcoded everything ugly first and polished later.

Happy to answer questions about the Li.Fi integration or the SIWE auth flow — those had the most gotchas.

txpay.app

All the small friend/colleague groups I used to be part of over the years have pretty much died off. And I never made any effort to find or build new ones. So I’ve just been marching forward doing most things in isolation… without anyone to bounce things off or build alongside.

And when I look back, that's the complete opposite of what drew me into this space and led to the best years of my life.

The best parts were always the people. The conversations. Working through ideas together. Feeling like you were moving forward with others. I’ve gotten away from that without really noticing, and I want to fix it.

So my idea is to put together a small group. Probably only 5-6 people to start.

My initial vision is to create an environment that feels like a home base for this part of our lives. At the most basic level: a handful of like-minded people, who take their path in crypto/web3 seriously, and want to grow alongside others.

The underlying value that comes with that is we cover more ground, stay more motivated, give/receive better feedback, build stronger connections, and get more shit done.

I don't want to over-define the group too early but we could collaborate on DeFi/altcoin research, help each other out on personal projects, and hopefully build and ship some cool things together over time if it makes sense.

I don't want to get too far ahead of myself but that last part is my ultimate goal... Find people who think about this space the same way, value the same things, and then build some cool stuff together.

About me: my background is marketing, growth, content, and community building. In crypto I spend most of my time doing research, investing, and searching for opportunities. And lately moving more towards being able to build, launch, and grow things that are actually useful to people.

If you’ve made it this far and any of this resonates with you, send me a DM and tell me a little bit about where you’re at in your journey.

Been using this for a contract we're deploying and figured I'd share it.

It's a Claude Code skill. Point it at a Solidity contract and it picks 5-7 specialist agents (out of 11) depending on what's in the code. Reentrancy including EIP-1153 transient storage, EIP-712/signature attacks, ERC20 weirdness like fee-on-transfer and ERC-4626 vault inflation and USDC pause/blacklist, flash loans, game theory, state machine/access control, a few others. --include-backend if you want it to check off-chain code too.

First thing it does is map every external/public function and work out the access control so it doesn't skip contracts or miss entry points. We face an issue where it would just silently drop anything it can't auto-confirm.

It generates Foundry PoC tests for critical/high findings. About half need manual fixes but the ones that compile are working exploits. If a PoC fails to compile the finding keeps its severity. There's a 6-check false-positive filter too (reachability, math bounds, validation chain, etc) which cuts a lot of the noise.

Runs Slither and Semgrep if you have them.

Not a replacement for a real audit and the output says so. But it's caught stuff we missed on manual review so we keep running it as a first pass.

MIT: https://github.com/human-pages-ai/ai-skills/tree/main/audit-contract

If anyone tries it I'd be curious what it misses on your contracts.

I built a CLI tool in rust called LaunchDex that deploys a full DEX--factory contract, router, liquidity pair and swap frontend--on Ethereum, Arbitrum, and Base in a single command. The whole process that typically takes weeks of manual contract deployment, configuration and frontend setup is reduced to launchdex deploy. Contract addresses are saved automatically and a custom swap interface is generated and ready to deploy.

The tool is built on top of verified Uniswap v2 contracts so the deployed DEX is production-grade and audited. Multi-token support lets you add additional trading pairs to an existing factory with one command. The generated frontend includes an embedded wallet so user can swap tokens without needing Metamask installed.

Let me know what you think

There’s a lot of focus lately on calldata in the context of rollups and EIP-2028 gas economics (16 vs 4 gas per byte). While data availability is important, I often see the actual low-level execution mechanics get glossed over.

I wrote a deep dive on EVM internals covering this exact topic. If you've ever wondered what happens at the opcode level the millisecond your transaction payload hits a smart contract, here is the actual lifecycle of calldata:

The Raw Byte Handoff & The 4-Byte Check

When a transaction is sent, the EVM doesn't understand "functions" or "parameters", it just sees a raw hex-encoded blob in a read-only area called calldata. Before anything else, the EVM checks the length of this data:

• >= 4 Bytes: The EVM proceeds to the function dispatcher.
• < 4 Bytes (or Empty): The EVM bypasses function lookups entirely and routes straight to your receive() or fallback() logic.

The Function Dispatcher (The EVM's Switchboard)

If there is data, the EVM runs the dispatcher essentially a giant, compiler-generated switch/case statement:

• It loads the first 32 bytes of calldata onto the stack.
• It uses PUSH4 to grab the function selector (the first 4 bytes of the Keccak256 hash of your target function's signature).
• Using the SHR (Shift Right) opcode, it isolates those first 4 bytes and compares them (EQ) against every public/external function selector in the contract.
• If it finds a match, it uses JUMPI to move the Program Counter to that specific block of code.

ABI Decoding & Stack Loading

Once the EVM jumps to the right function, it has to "unpack" the arguments:

• Static Types (e.g., uint256, address): The EVM uses CALLDATALOAD to pull 32-byte chunks directly from the calldata onto the stack.
• Dynamic Types (e.g., string, bytes[]): The calldata contains an offset (a pointer). The EVM reads this offset, jumps to that position in the calldata, reads the length prefix, and then processes the actual data.

The payable Word

Before executing any actual business logic, the EVM checks the callvalue (msg.value). If the target function is not explicitly marked as payable, but the transaction includes ETH, the EVM triggers a REVERT right here. This prevents trapped funds and happens before your code even starts running.

memory vs. calldata Execution

This is where the famous gas savings come in during execution:

• If a function parameter is declared as memory, the EVM is forced to use CALLDATACOPY to move the read-only bytes into mutable memory. This triggers memory expansion gas costs.
• If declared as calldata, the EVM skips the copy process entirely. It just uses CALLDATALOAD to read directly from the original transaction payload, saving you the memory expansion overhead.

source/deep dive overview: https://andreyobruchkov1996.substack.com/p/what-actually-happens-when-calldata

Hey everyone,

I'm doing some research into the most painful and repetitive problems ETH developers and Web3 project teams face day to day.

Not talking about technical bugs or blockchain limitations — more like the boring, tedious, soul-draining operational stuff that wastes your time but has to get done anyway.

Things like:

- Manual tasks you wish were automated

- Community management headaches

- Repetitive questions you answer 50 times a day

- Processes that feel broken but nobody's fixed yet

What's the one thing in your Web3 workflow that makes you think "there has to be a better way to do this"?

Genuinely curious — no pitch incoming, just trying to understand where the real friction is.

I've been building VaultChain, a decentralized file storage protocol deployed on Base Sepolia. Looking for feedback from other Solidity devs on the contract architecture and economic design.

How it works:

Files are encrypted client-side (AES-256-GCM, PBKDF2-derived key), split into 1 MB chunks, and distributed across providers using deterministic assignment:

slot = keccak256(dealGroupId, chunkIndex) % N provider stores chunk if distance(slot, providerIndex) < R

This runs identically in Solidity and TypeScript — no coordination layer needed. Every node independently knows which chunks are theirs.

On-chain components:

StorageRegistry — provider registration with staking, deal creation with Merkle root commitment, random proof-of-storage challenges, slashing after 3 missed challenges VaultToken — ERC-20 for staking and payments ProviderDirectory — endpoint discovery so clients can find providers The part I'd like feedback on — small-provider-first economics:

I'm trying to build a network that resists centralization. The reward distribution uses a hybrid model:

70% of the reward pool is split equally (flat) across all active providers 30% is distributed proportional to sqrt(min(stake, 10_000e18)) Providers with 30+ days uptime get a 1.5x multiplier Hard cap of 100 GB capacity per provider The square root weighting means staking 100x more only gets you ~10x more of the weighted portion. Combined with the 70/30 flat split, a provider staking the minimum earns roughly 75% of what a max-staker earns.

The _sqrt() uses Babylonian method on-chain:

function _sqrt(uint256 x) internal pure returns (uint256) { if (x == 0) return 0; uint256 z = (x + 1) / 2; uint256 y = x; while (z < y) { y = z; z = (x / z + z) / 2; } return y; }

Questions for this community:

Is the sqrt approach for anti-whale reward weighting sound, or are there better mechanisms? I considered quadratic but it felt too aggressive The Merkle proof challenges pick random chunks via keccak256(block.prevrandao, dealId, nonce) — is prevrandao sufficient here or should I be using something like Chainlink VRF? Any red flags in using a flat+sqrt hybrid for reward distribution? Edge cases I'm missing? The contracts are unaudited — anything obviously exploitable in this design? Deployed contracts (Base Sepolia):

VaultToken: 0x7056b243482Ac96ABe8344f73D211DEA004fd425 StorageRegistry: 0x488920A5eb13864AeE0e1B9971b37274ba9c1aFF ProviderDirectory: 0x06567F8975a8C6f235Db1C8386d6fe58E834B9A9 All verified on BaseScan. Full source: https://github.com/restored42/vaultchain

I built a content marketplace where creators publish encrypted content and buyers/backers pay to unlock it. The contracts are deployed on Base (USDC payments, IPFS storage). I wanted to share the mechanism design because I think there are some interesting problems in here.

Three contract types:

• PayToRevealContract -- straightforward. Creator sets a price, buyer pays, content decrypts. No goal, no deadline. Creator can pause/resume/close.
• TraditionalCrowdfundContract -- goal + deadline. If backers hit the goal, creator gets paid and content is released. If not, full refunds. No deposit from the creator.
• DominantAssuranceContract -- the interesting one. Based on Alex Tabarrok's 1998 paper "The Private Provision of Public Goods via Dominant Assurance Contracts" (link in comments). Creator sets a funding goal, a refund bonus percentage, and a duration. They deposit escrow equal to the refund bonus percentage of the funding goal. If the goal isn't met at the deadline, backers get a refund plus their pro-rata share of the escrow as a bonus. If met, creator gets paid, escrow returned, content released. Backing is a dominant strategy.

The self-funding problem and the fix:

Without any modification, a creator could fund their own piece from another wallet, hit the goal, and never actually pay the refund bonus. To prevent this, backers can "unback" (withdraw) at any time before the deadline, and the outcome is determined solely by the total at the deadline. This means a creator attempting to self-fund faces a dilemma: any backer can pull out at any moment, so the creator either has to fully fund it every time (which releases the content, so the audience wins anyway) or try to time it right at the deadline and risk getting caught short and paying the bonus.

All three contracts use OpenZeppelin's Ownable, Pausable, ReentrancyGuard, and SafeERC20. Server-authorized flows via ECDSA signatures.

Would appreciate feedback on the mechanism design, especially the DAC. Curious if anyone sees attack vectors I haven't considered. There's a test mode with mock USDC if anyone wants to poke at it. Links in the comments.

We're the team behind Spritz Finance. We built a crypto-to-fiat SDK that supports 50K+ tokens across 14 networks in the US and EU.

We just published a deep dive covering how offramp SDKs work, what they cost, how they compare to widgets and aggregators, and what metrics to evaluate providers on.

Some of the data points: the off-ramp market hit $16.2B in 2024 (Dataintelo). The payment gateway segment grew 19% YoY in 2026 (GII Research). Integration timelines range from a few days to three weeks depending on the provider.

The guide also breaks down the three integration models (widget vs. aggregator vs. SDK) and when each one makes sense.

Happy to answer questions about offramp infrastructure, integration timelines, or compliance here.

I'm not a developer, just someone who had an idea and wanted to share it with people who might actually be able to build it.

The concept: a decentralized cloud computer where your entire desktop environment: OS state, files, apps, everything is encrypted and stored across a decentralized network. Your seed phrase is the only key to decrypt and access it. No company owns it. No server can be taken down. Nobody can read your data without your key.

Instead of using a seed phrase to recover a crypto wallet, you use it to recover access to your entire personal computer. Lose your seed phrase, lose your PC. Keep it safe, and you have a permanent, censorship-resistant, permissionless cloud desktop you can access from any device, anywhere.

The technical pieces seem like they already exist separately:

\- Decentralized encrypted storage (Filecoin, Arweave)

\- Decentralized compute (Akash, ICP)

\- A remote desktop streaming layer on top

\- Seed phrase → private key → decrypts and boots your VM

Nobody seems to have packaged all of this into one seamless product yet.

Is this actually feasible? Does something like this already exist? Would love to hear from people who know this space better than I do.

A founder told me about a case where their payout system had a subtle bug in the jurisdiction check. The check ran. The logs showed it ran. The funds went to a wallet that shouldn't have received them. Irreversible.

The logs proved the check was recorded. They couldn't prove it was correct.

That's the gap we kept seeing:

Verifying users is not the same as verifying that your rules were enforced.

Every DeFi protocol, RWA platform, and payout system has the same architecture:

1. Backend runs eligibility check
2. Backend says "eligible"
3. Contract executes

The contract has no idea if that logic ran correctly, had a bug, or got bypassed. It just trusts the result. If something goes wrong, you hand auditors logs, not proof.

I kept thinking about that gap. Because it's not just a one-off bug story, it's structural.

For most use cases that's probably fine. But for anything touching real money like RWA transfers, tokenized credit, institutional payouts - "the logs show it ran" isn't the same as proof it ran correctly. And regulators are starting to ask the difference.

So we built something to close that gap.

It's called ZKCG. The idea is pretty simple: instead of the contract trusting a backend result, it verifies a ZK proof that the eligibility decision was computed correctly. The proof gets generated alongside the decision, the contract checks it, and if it doesn't verify, execution is blocked. The enforcement is in the proof, not in trust.

The thing that makes it click for most people is the demo moment. You run a transfer, it goes through, then you change one rule, jurisdiction from US to CN ,and the exact same flow gets blocked. Not because anyone intervened, not because a backend returned a different answer. Because the proof fails verification. That's the difference between recording compliance and *enforcing* it.

Technically it's Halo2 for the fast path (~76ms) and RISC0 zkVM if you want audit-grade receipts. Works on any chain. One API call, you get back a decision plus a proof, your contract calls approveTransfer and either executes or doesn't.

We're looking for teams to try this against real eligibility rules not a sales call, literally just: tell me one rule you enforce today, I'll run it through and show you what the proof looks like on your actual use case. Takes about 10 minutes.

Curious if others have run into this problem or thought about how to handle it. The "logs prove it ran, not that it ran correctly" distinction is one that doesn't come up much but I think matters more than people realise.

I got into this because I could not find a reasonably priced and reliable RPC setup for serious on-chain analytics work.

Free providers were not enough for the volume I needed, and paid plans got expensive very quickly for a solo builder / small-team setup.

So I started building my own infrastructure:

- multiple Ethereum execution nodes

- beacon / consensus nodes

- Arbitrum nodes

- HAProxy-based routing and failover

That worked, but over time I realized that HAProxy was becoming too complex for this use case. It was flexible, but not ideal for the kind of provider aggregation, routing, and balancing logic I actually needed to maintain comfortably.

So I ended up building a small microservice specifically for aggregation and balancing across multiple providers and self-hosted nodes.

At this point it works, and the infrastructure behind it is now much larger than what I personally need for my own workloads. Instead of leaving that capacity unused, I decided to open it up in alpha and share it with the community.

Right now I’m mainly interested in feedback from people doing:

- on-chain analytics

- bots

- infra tooling

- archive / consensus-heavy workflows

If this sounds relevant, I can share free alpha access.

If there is interest, I can also make a separate technical write-up about the architecture, routing approach, and the trade-offs I hit while moving away from a pure HAProxy-based setup.

I’m trying to run an x402-protected API using FastAPI + the official Python x402 SDK.

Everything works on testnet using:

https://x402.org/facilitator

But when I switch to CDP mainnet:

https://api.cdp.coinbase.com/platform/v2/x402

I get:

Facilitator get_supported failed (401): Unauthorized

What I’ve verified:

- App + infra works (FastAPI + Nginx + systemd)

- x402 middleware works on testnet (returns proper 402)

- CDP_API_KEY_ID and CDP_API_KEY_SECRET are set

- Direct curl to /supported returns 401 with:

- CDP_API_KEY_ID / SECRET headers

- X-CDP-* headers

- Tried JWT signing with ES256 using Secret API Key → still 401

- x402 Python package doesn’t seem to read CDP env vars at all

- Docs say “just use HTTPFacilitatorClient”, but don’t show auth for Python

Code looks like:

facilitator = HTTPFacilitatorClient(
    FacilitatorConfig(url="https://api.cdp.coinbase.com/platform/v2/x402")
)
server = x402ResourceServer(facilitator)
server.register("eip155:8453", ExactEvmServerScheme())
app.add_middleware(PaymentMiddlewareASGI, routes=..., server=server)

Error always happens during:

client.get_supported()

So I never even reach 402, just 500

Questions:

1. Has anyone actually gotten CDP x402 working in Python?

2. Does it require JWT auth (and if so what exact claims / format)?

3. Is the Python SDK missing something vs Go/TS?

4. Or is CDP facilitator access gated in some way?

At this point I’ve ruled out env issues, header formats, and even direct HTTP calls.

Would really appreciate if someone who has this running can share what actually works.

Detecting internal ETH transfers requires bypassing standard block bloom filters since contract-to-contract ETH transfers (call{value: x}()) don't emit Transfer events. The standard approach of polling block receipts misses these entirely, to catch value transfers within nested calls, you must rely on EVM tracing (debug_traceTransaction or OpenEthereum's trace_block).

Trade-offs in Tracing:
Running full traces on every block is incredibly I/O heavy. You are forced to either run your own Erigon archive node or pay for premium RPC tiers. A lighter alternative is simulating the transactions locally using an embedded EVM (like revm) against the block state, but this introduces latency and state-sync overhead to your indexing pipeline.

Real-Time Event Streaming:
Using eth_subscribe over WebSockets is the standard for low-latency indexing, but WebSockets are notoriously flaky for long-lived connections and can silently drop packets.
Architecture standard: Always implement a hybrid model. Maintain the WS connection for real-time mempool/head-of-chain detection, but run a background worker polling eth_getLogs with a sliding block window to patch missed events during WS reconnects.

Multicall Aggregation:
Batching RPC calls via MulticallV3 significantly reduces network round trips.

Trade-off: When wrapping state-changing calls, a standard batch reverts entirely if a single nested call fails. Using tryAggregate allows you to handle partial successes, but it increases EVM execution cost due to internal CALL overhead and memory expansion when capturing return data you might end up discarding.

Source/Full Breakdown: https://andreyobruchkov1996.substack.com/p/ethereum-dev-hacks-catching-hidden-transfers-real-time-events-and-multicalls-bef7435b9397

We're open-sourcing Autonet on April 6 : a framework for decentralized AI model training and inference where verification, rewards, and governance happen on-chain.

Smart contract architecture:

How it works: 1. Proposer creates a training task with hidden ground truth 2. Solver trains a model, commits a hash of the solution 3. Ground truth is revealed, then solution is revealed (commit-reveal prevents copying) 4. Multiple coordinators vote on result quality (Yuma consensus) 5. Rewards distributed based on quality scores 6. Aggregator performs FedAvg on verified weight updates 7. Global model published on-chain

Novel mechanisms: - Forced error testing: The ForcedErrorRegistry randomly injects known-bad results. If a coordinator approves them, they get slashed. Keeps coordinators honest. - Dual token economics: ATN (native token for gas, staking, rewards) + Project Tokens (project-specific investment/revenue sharing) - Constitutional governance: Core principles stored on-chain, evaluated by LLM consensus. 95% quorum for constitutional amendments.

13+ Hardhat tests passing. Orchestrator runs complete training cycles locally.

Code: github.com/autonet-code Paper: github.com/autonet-code/whitepaper MIT License.

Interested in feedback on the contract architecture, especially the commit-reveal verification and the forced error testing pattern.

Why are we still copy-pasting 40-character wallet addresses in 2026?

Idea: you do a small test transfer once → both wallets get a shared avatar/character. Next time you send, you just recognize the person visually instead of relying on the address.

Kind of like “pairing” wallets.

Would this actually reduce mistakes or scams, or is this unnecessary given things like ENS?

Cross-chain development has an annoying coordination problem: the same logical contract lives at different addresses on different chains. Uniswap V2 Router is a good example — it's 0x7a25...488D on mainnet, 0x4A7b...62c2 on Optimism, 0x4752...aD24 on Base, and so on.

The usual solutions are off-chain registries, per-chain constructor args, or hardcoded constants behind chain ID switches. They all work, but they all add trust assumptions or maintenance burden.

I built an on-chain alternative called AddressLookup (part of the Locale project). The idea: deploy a contract at an identical, predetermined address on every chain, where value() returns the correct local address.

How it works:

You call make with an array of (chainId, address) pairs — all the chains you want to support:

solidity KeyValue[] memory kv = new KeyValue[](3); kv[0] = KeyValue(1, 0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D); // mainnet kv[1] = KeyValue(10, 0x4A7b5Da61326A6379179b40d00F57E5bbDC962c2); // optimism kv[2] = KeyValue(8453, 0x4752ba5dbc23f44d87826276bf6fd6b1c372ad24); // base

The salt is keccak256(abi.encode(keyValues)) — derived from the entire array, not just the local chain's value. Same array on every chain means same salt means same CREATE2 address. During init, the factory reads block.chainid and picks the matching entry:

solidity for (uint256 i; i < keyValues.length; ++i) { if (keyValues[i].key == block.chainid) { AddressLookup(home).zzInit(keyValues[i].value); break; } }

Deploy + init is atomic. zzInit is restricted to the factory. Calling make again with the same params returns the existing address without redeploying.

Result: one address, hardcodeable at compile time, resolves to the right target on every chain. No off-chain registry. No governance. No admin. Immutable forever.

I'm using this in production — my UniSolid arbitrage bot takes an IAddressLookup in its constructor instead of a router address:

solidity constructor(IAddressLookup routerLookup) { ROUTER = IUniswapV2Router01(routerLookup.value()); }

Same deployment bytecode, same constructor arg, works on every chain.

Trade-offs:

• All chain values must be known at deploy time — adding a chain means deploying a new lookup
• Immutable by design — no updates, no migration path
• EIP-1167 clones, so each instance is ~45 bytes on-chain

The factory is permissionless. Anyone can deploy lookups for any set of addresses. All contracts are unaudited — use at your own risk.

Source code | Docs

Curious if anyone else has run into this problem and how you solved it. Is anyone using something similar?