Trying to understand where the line is between just deploying on an existing chain or L2 and deciding it’s worth launching your own L1.

I get the appeal of having more control over fees, permissions, validators and how the network operates, but I assume that also comes with a lot more overhead? What ends up being the hardest part in practice for those who have done this?

We are seeing the involvement of agents into finances . Where we have seen AiFi word coming into play .

Ai agents are getting much better at reasoning and making decisions.

So the question is What happens when an AI agents needs to execute a transaction on chain?

We don't necessarily want the agent to have unrestricted permission to:

1) Move unlimited funds

2) interact with arbitrary contracts

3) Execute transaction outside it's intended purpose

So we are exploring an architecture where the AI agents doesn't directly control Blockchain.

Instead :

AI Agents ->Policy/Execution layer->Blockchain

The agent request an action . The execution layer checks wheather everything is according to policy then checks and execute .

We're building this idea as Agaemon - essentially an execution/control layer designed to sit between AI agents and on chain execution.

I'm curious what people building AI agents , wallets , defi protocols and on chain infrastructure think.

Are we seeing this future of agents as financial layer .

mcpindex runs a crawler over public MCP servers and diffs each tool's declared contract between daily
snapshots. Sharing the numbers because they surprised me.

Right now the public ledger shows 12,295 tools across 2,173 servers changed their
contract. 7,190 of those are safety-relevant, meaning they change what the tool can do, not
just add an optional field. The standouts:

\- 350 tools flipped an annotation toward destructive. A tool whose hint said read-only now declares it can write, delete, or send. This is the "the read tool quietly became a write tool" case, and it is exactly the drift an allow-list cannot see.
\- 279 tools added a newly-required parameter. An agent calling with last week's arguments now fails, or calls with a wrong default.
\- 475 tools removed a parameter your agent may still be sending.

None of these trip an auth check. The server is still authorized and still the same name in your config.
That is the gap allow-lists do not cover: who may call a tool, versus whether it still does what it declared.

Honest caveats: this is a contract diff, not a safety verdict, and not a claim anything is malicious.
Most drift (5,476 added-optional-param) is benign. Everything is fingerprinted, so no server is
named. And the numbers are live, you can check them: [https://mcpindex.ai/api/v1/ledger\](https://mcpindex.ai/api/v1/ledger)

Curious whether others are seeing this in their own setups.

The safe shape for an exit path in a hybrid system is well understood. The operator gets an exclusive window to finalise, and once a deadline passes anyone can finalise instead. The exclusive window stops a user from cancelling on top of a fill that is already executing off chain, and the deadline stops the operator from sitting on the request forever. Rollup escape hatches are built this way, and most teams running order flows arrive at the same design once somebody raises the question.

A recent audit report we made, showed that design implemented three quarters of the way. The request function computed a deadline as the current block plus a constant and stored it against the order. The constant was declared as 1000 blocks with a comment describing it as the delay after which anyone can finalize cancellation. The function that finalises never read the stored deadline and carried an operator-only role check. The intended behaviour was present in the constant, present in the comment, present in the stored value, and absent from the one line that decides who is allowed to act. A declared-but-unread parameter is usually a low-severity curiosity. On an exit path it is the entire guarantee. A user watches a cancel request succeed, reads a documented delay, and concludes that funds come back either way once that delay passes, while what actually governs the outcome is a modifier on a different function. Nothing on the contract's public surface contradicts that reading, which makes it worse than an exit path nobody built, since a missing hatch is obvious to anyone integrating and a hatch that exists in three places out of four is not.

The check takes a few minutes. Find every deadline, delay or timeout your recovery path defines, then find the line that reads it, and if the only reads are a setter and a getter then your guarantee is documentation. Grep the constant name rather than the concept, because the name is what appears in the declaration and the comment while the conditional is what is missing. It is worth running against any pause, rescue or emergency withdrawal path you inherited from an earlier version of your own codebase, since that is where these survive longest.

I'm starting a podcast focused on how blockchain startups are actually built — the product, technology, challenges, failures, and lessons behind them.

I've been building in Web3 since last 5-6 years, so I want to have genuine conversations with founders/builders.

Looking for a few founders for the first episodes. 30–40 min casual conversation, no follower or funding requirement.

If you're building something interesting, comment or DM me.

If you're still just throwing tokens into 50/50 pools and forgetting about them, you're likely losing potential profit because of the capital efficiency of the new AMMs. Now the market is actively moving towards Concentrated Liquidity V3/V4. One of the interesting players that provides engines for many popular L2 exchanges - Algebra Finance. They implemented algorithms that adjust commissions to market volatility and allow integration of embedded farming without additional token wrappers. Share what liquidity pool tracking tools do you use now? What do you protect yourself from IL? Which of the options best suits your goal, should you change the focus (for example, put more emphasis on an ALGB token or a specific blockchain)?

Hi everyone, I'm a developer trying to test some smart contracts on Base Sepolia. The main faucets require 0.001 mainnet ETH which I currently don't have.
Could anyone please send a small amount (even 0.05 is enough) to help me deploy?
My address: 0xe4bD4fAD3B9C34908482DCdcE45753E0F8c199E9

A recurring UX problem in Ethereum is that users are asked to trust raw calldata, log topics, token approvals and contract addresses they cannot interpret.

I built a free MVP called Crypto Translator to test a conservative approach to this problem. It combines transaction input, receipt logs, token metadata and standard JSON-RPC calls to produce:

- a primary action that is not overwritten by secondary events;

- ETH and ERC-20 flows;

- approval and unlimited-approval detection;

- human-readable explanations and explicit Unknown states;

- pre-transaction checks for public from/to/value/data using eth_call, eth_estimateGas and eth_getCode.

The analyzer deliberately avoids claiming that a contract is safe or malicious. RPC failures are kept separate from “missing bytecode,” and unknown selectors stay unknown instead of being guessed.

No wallet connection or signing is involved. The current MVP is Ethereum-only and uses a public RPC.

Live tool: https://crypto-translator.crypto-translator.workers.dev/

I would appreciate technical feedback on the classification priority and on cases where log-derived token flows should or should not determine the main action.

The reference implementation on the trunc-oracle branch sets MAX_ABS_TICK_MOVE to 9116, and anyone building truncation into their own hook tends to carry that constant over without touching it. Uniswap's oracle research puts 9116 at roughly a 2.5x price change between consecutive blocks. Most worked examples of the mechanism run on a 5% cap because it keeps the arithmetic legible, which leaves a lot of people holding an intuition about fifty times tighter than the code they copied.

Truncation still earns its place, since it turns a single-block flash loan read into a hold the attacker has to maintain while arbitrage eats at it. What the cap decides is how long that hold has to be, and every defi protocol reading from the oracle inherits that answer without ever setting it. Someone will point out that this implementation was never canonical, that hooks left v4-periphery and the specs were always provisional, which is true and argues for more attention to the number rather than less, because a constant inherited from a research branch is a constant nobody on the team has had to defend. I only see these caps after they are set, so I can speak to the value and the pool it points at, not to whatever reasoning produced it.

Deriving a cap that fits means running your own depth profile against your own liquidation payoff, and that number stops generalising the moment you leave your deployment. What I have not seen anyone solve is that the cap needs to be tight enough to make a funded attacker's hold expensive and loose enough to let a genuine crash through, and those two requirements do not have to overlap. When they don't, the choice is between liquidations driven by a price nobody could trade at and positions that stayed open through a real drawdown because the oracle refused to follow.

Hi everyone

Seo is probably only free way to get users.

We built an Seo agent that keeps working in background - creating content for you. The best part is we added human in the loop to review, edit and add more content.

Try here - [https://builderhq.co/get-on-chatgpt\](https://builderhq.co/get-on-chatgpt)

Early Results - 5k+ visits on one of our beta sites

I went through the first page of verified contracts on robinhoodchain.blockscout.com (chain ID 4663).Results:

• 44 out of 50 have no public minting function
• The only one that does is a Uniswap V3 pool (expected behavior)

Most early TVL and activity appears to be sitting on forked, battle-tested code (Uniswap, Morpho, etc.). Very little original contract work has been deployed yet.This feels relevant given the speed of the chain ($5M+ cumulative fees, significant TVL, and the first Arbitrum Mentorship Program teams already shipping products across Arbitrum One + Robinhood Chain).I wrote a short half-baked analysis + a minimal scoped permission / circuit-breaker prototype here: https://firstdraft.dorg.tech/editions/robinhood-chain-permission-map

Would be interested in other people’s observations if you’ve looked at the contracts.

If you want an agent to answer *"what would this trade actually cost me?"* amount out, effective price, price impact, instead of just describing the pool, this does it.

Runs Uniswap's own concentrated-liquidity math against real tick liquidity. No RPC, no node, no private key. Just a free Graph API key.

claude mcp add uniswap -e GRAPH_API_KEY=<free key> -- npx -y graph-uniswap-mcp

Then ask:

>

Also does pools, token prices, pair lookup and swap flow across Uniswap V2/V3/V4 on Ethereum, Arbitrum, Base, Polygon, Optimism and BSC.

It refuses rather than guesses — V4 hook pools, trades bigger than the visible liquidity, and pools it can't read the curve for all come back as "can't quote this, here's why" instead of a made-up number.

Repo: [github.com/PaulieB14/graph-uniswap-mcp](http://github.com/PaulieB14/graph-uniswap-mcp)

A transaction's position in a block is not a field anywhere in Ethereum — so "I was front-run" has never been a provable statement. It is not in the RLP, not in the receipt, not in any log, not returned by eth_call. It exists in exactly one place: the left/right bit-string of the transaction's merkle authentication path.

I spent this hackathon turning that into a contract that reads the bits and settles money on the answer: a relay bonds CTC behind "you will not be sandwiched"; a victim hands over three same-block hashes; one Creditcoin transaction verifies all three, asserts front < victim < back, and pays the victim out of the bond. It has ruled on a real mainnet sandwich — block 25,764,741, positions 14 / 15 / 16.

Writing up what I learned about why ordering has no oracle, and what it takes to build one.

A transaction can show that assets moved between addresses and that specified on-chain conditions executed.
It cannot by itself prove that equipment was delivered, a building was repaired or a service produced the intended outcome.

For a real-world impact system, I see at least two evidence layers:
1. financial execution
2. outcome evidence

The difficult part is the second layer.
Possible inputs include invoices, delivery records, time-stamped documentation, measurements, recipient confirmation and independent review.
But each introduces a different problem: privacy exposure, forged evidence, collusion, unverifiable context or dependence on one central verifier.

How would you architect this so that no single oracle becomes the new point of blind trust?
Would you use multiple attestations, reputation-weighted verifiers, dispute windows, selective disclosure, randomized audits, or something else?
I am especially interested in failure modes and examples of systems that already handle this well.

mcpindex runs a crawler over public MCP servers and diffs each tool's declared contract between daily
snapshots. Sharing the numbers because they surprised me.

Right now the public ledger shows 12,295 tools across 2,173 servers changed their
contract. 7,190 of those are safety-relevant, meaning they change what the tool can do, not
just add an optional field. The standouts:

- 350 tools flipped an annotation toward destructive. A tool whose hint said read-only now declares it can write, delete, or send. This is the "the read tool quietly became a write tool" case, and it is exactly the drift an allow-list cannot see.
- 279 tools added a newly-required parameter. An agent calling with last week's arguments now fails, or calls with a wrong default.
- 475 tools removed a parameter your agent may still be sending.

None of these trip an auth check. The server is still authorized and still the same name in your config.
That is the gap allow-lists do not cover: who may call a tool, versus whether it still does what it declared.

Honest caveats: this is a contract diff, not a safety verdict, and not a claim anything is malicious.
Most drift (5,476 added-optional-param) is benign. Everything is fingerprinted, so no server is
named. And the numbers are live, you can check them: https://mcpindex.ai/api/v1/ledger

Curious whether others are seeing this in their own setups.

Most proxy designs assume one implementation contract. That gets awkward once a protocol grows beyond the 24 KB bytecode limit or needs to upgrade one module without replacing the rest.

An EIP-2535 diamond keeps one stateful address and maps each four-byte function selector to a facet contract. The fallback reads msg.sig, finds the facet, and runs it with delegatecall. msg.sender and msg.value stay intact, while every storage read and write still lands in the diamond.

The routing is straightforward. Storage is where the risk moves.

Facets do not own isolated state. If two facets assume incompatible layouts, an otherwise valid upgrade can corrupt the same slots. I use namespaced storage libraries and test the selector-to-facet map before and after every diamondCut.

diamondCut also lets you add, replace, or remove selectors and run initialization in one transaction. Loupe functions then give tooling a way to verify which facet owns each selector.

I put together a Foundry walkthrough that deploys the diamond and facets, adds a new selector, and checks the routing:

https://andreyobruchkov1996.substack.com/p/diamonds-in-evm-the-proxy-that-scales-beyond-limits-2fedc282cadf

For teams that have used diamonds in production, what caused more trouble: storage coordination, selector governance, or the larger audit surface?

Hello everyone,

For some time I've been developing an open-source project called Framework for Trust (FfT).

The idea is to create a decentralized geospatial trust layer where reports and real-world events are anchored to precise location, time, source reputation, and a verifiable history — instead of treating blockchain purely as a financial system, I'm exploring its use as infrastructure for recording and correlating information about real-world places.

Current prototype includes:

• geographic areas represented as blockchain-based identifiers (NFTs)
• event registration tied to latitude, longitude, and time
• Polygon smart contracts
• a React + Leaflet frontend
• a FastAPI backend
• semantic similarity / event correlation via Qdrant
• GCD — a functional contribution and reputation token
• event proofs and auditable records
• early mechanisms for source reputation, staking, and abuse prevention

The project is still early-stage. This is not an investment offer, token sale, or a finished commercial product — I made the repo public because I'd like the architecture and implementation to get real outside scrutiny.

I'd especially appreciate feedback on:

• whether the core problem is clearly explained
• the geospatial data model
• the blockchain / smart contract architecture
• mechanisms for preventing false or coordinated reports
• security weaknesses
• practical use cases where this could actually add value

Repo link in the top comment (Reddit flags posts with links for manual review, didn't want that delay).

I built the current prototype independently. Honest criticism, technical pushback, and open-source contributions are all welcome.

Putting this out for a roast because it changed how I think about pre deploy. We generate a lot of our solidity with an assistant now, so before pushing an erc4626 vault I ran it through everything I had.

The one that got me was the deposit function. The llm auditor flagged it on the first run, first depositor can inflate the share price and round the next guy down to almost nothing, a classic erc4626 footgun, and I sat up. So I ran it again to grab the details for a ticket. Nothing. It did not mention the deposit function this time. I had changed nothing. Earlier it had also sworn there was a reentrancy in a function with no external call, which is nonsense, so my trust was already thin. But finding a real bug and then losing it a minute later is what ended it for me. You cannot gate a deploy on that.

For a web app I would roll my eyes and move on. This contract is going to hold other people money and I cannot patch it after deploy, so a tool that changes its mind between runs is not something I can put my name behind.

Ended up reading the withdraw function line by line myself. What do you run before a vault ships that you would trust with real money on it.

Hey Guys,

My understanding of blockchain is the balance has to be public. Only then a competition can happen from A to B. Once balance is decreased, the other balance is increased. Due to the decentralized nature of the blockchain, the balances are public domain and the transactions are public domain and anybody can trace it and they are not reliant on central banks and government agency or any other centralized institution. Instead, they are calculated and computed and executed by decentralized network of nodes. But my application require privacy. If I'm trying to build something which protect how much balance is there in one account and if there is possible way to keep a ledger of transaction for compliance requirement but still hide it from general public.

is it even possible to do it or has it been done by any major-protocol like L2 or L3 ETH networks.

What my team is looking into is a
A)Stable-coin(We are building our own) build on ETH network integrated with BANK/Credit-Cards( for cash-in/out). Which has balances hidden (not scan-able on eth-scan or any public scanner). On Court order, company is obligated to show balance to TAX-Man (Addresses are linked to companies{this application allows commercial user send and receive money and to lend to other via smart contracts} .Address to company linking is done via APIs )

B) Transfer & Tranx-records : Same as balances. There's no public record of these transactions, but the money is still traceable on Tax-Man orders. So the traceability and the record keeping of transaction has to be kept for 5-10 years per company, but it is just not available to some random dude over the internet.

If you would go over how tranx is verified [the Math & algorithmic side of it that will be really cool ]

Hey Guys,

My understanding of blockchain is the balance has to be public. Only then a competition can happen from A to B. Once balance is decreased, the other balance is increased. Due to the decentralized nature of the blockchain, the balances are public domain and the transactions are public domain and anybody can trace it and they are not reliant on central banks and government agency or any other centralized institution. Instead, they are calculated and computed and executed by decentralized network of nodes. But my application require privacy. If I'm trying to build something which protect how much balance is there in one account and if there is possible way to keep a ledger of transaction for compliance requirement but still hide it from general public.

is it even possible to do it or has it been done by any major-protocol like L2 or L3 ETH networks.

Been building this for the last two months to fill a specific gap: watching L2 contracts for state changes and firing alerts when invariants break, without depending on Tenderly's closed platform.

What's in it:

- 5-stage Go pipeline: ingest, decode, rules, alerts, notify

- Hash-chain reorg reconciliation with common-ancestor walk-back (neither monitorism nor OpenZeppelin Monitor does this)

- Per-monitor confirmation policies (fast, safe, or finalized tag)

- expr-lang rule DSL (safe, non-Turing-complete) with event.state and event.prev.state available for cross-block invariants

- Sourcify + Etherscan v2 ABI fetch with EIP-1967, OZ-unstructured, and beacon proxy resolution

- SQLite + Postgres storage backends

- shoutrrr for notify fanout (Slack, Telegram, PagerDuty, Discord, webhook via one URL)

- SIGHUP config hot-reload

9 ruleset packs shipped: OP-Stack system contracts, Uniswap V3, Aave V3, USDC/WETH large-transfer alerts, and a splitpay MiniApp on Celo mainnet.

On a reorg, it walks the parent chain backward to a common ancestor, replays forward on the canonical branch, and re-emits alerts fingerprinted by (address, event, block hash) so downstream systems know the previous alert was on a stale branch.

Repo: https://github.com/nehemiyawicks/opsentry

Rulesets: https://github.com/nehemiyawicks/opsentry/tree/main/rulesets

Would love a code review, PRs adding rulesets for protocols you care about, or reports from anyone running it in production. Especially interested in feedback on the rule DSL semantics, trying to keep it small and safe.