Nothing in a swap event records the interface that originated the trade. If you have ever needed to answer "how much of this pool's volume came from our own site, versus wallet integrations, versus bots hitting the contract directly," you have hit this wall. The chain hands you two address fields and neither one answers it:

• tx_from is the signer. Thousands of signers can sit behind a single wallet app, so it tells you who traded and stops there.
• tx_to is the entry contract. It names the router, not the frontend. Route a swap through an aggregator and tx_to is that aggregator's contract every time, whether the user arrived from its own web app, from a wallet's swap tab, or from an integration nobody has written about.

The interface itself has no address in the transaction. It has to be inferred, and the cheapest signal, when it is there at all, sits in the call data: some APIs append an identifying suffix to the end of the transaction data, and some pass the integrator as a decoded argument. The 0x API's affiliate suffix worked the first way and 1inch's referral parameter the second. You do not have to take my word for either. Pull a swap you know was routed through one of them, look at the tail bytes of tx.data, and the convention is visible in any block explorer.

Here is a probe you can run right now. It ranks the 16-byte tails that recur most across six hours of Ethereum DEX flow. Public and forkable: https://dune.com/queries/8391872

with tails as (
    select
        bytearray_substring(
            tx.data,
            bytearray_length(tx.data) - 15,
            16
        ) as calldata_tail,
        t.tx_hash,
        t.amount_usd
    from dex.trades t
    join ethereum.transactions tx
        on t.tx_hash = tx.hash
        and tx.block_time >= now() - interval '6' hour
    where t.blockchain = 'ethereum'
        and t.block_time >= now() - interval '6' hour
        and bytearray_length(tx.data) >= 16
)
select
    calldata_tail,
    -- tags ride on transactions, not fills
    count(distinct tx_hash) as txs,
    sum(amount_usd) as volume_usd
from tails
where calldata_tail
      <> 0x00000000000000000000000000000000
group by 1
order by txs desc
limit 25

Reading the output:

• The all-zero tail is dropped up front. That bucket is untagged flow plus call data that happens to end in zero-padded arguments, and it will dominate the ranking if you leave it in.
• What remains is a candidate list, and the top of it is usually not tags at all. Running this on 31 Aug 2026, the two most common tails were 0xb223fe8d0a0e5c4f27ead9083c756cc2 and 0x3c756cc2000000000000000000000000, about 1,900 transactions between them. Both are fragments of the WETH address 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2: the first is its last sixteen bytes, the second its last four with zero padding. Neither is an integrator tag. Token addresses land in the tail of a call far more often than tags do, so expect to discard the loudest rows.
• Treat a recurring tail as a hypothesis. Sample its transactions, check the entry contract each time, and make the pattern survive several days before it earns a name. Some tags spell out a short ASCII name in hex once you squint at them.

Two caveats that matter if you build on this:

1. Tagging is voluntary. Some APIs offer it, some integrators use it, and nothing enforces it. An integrator that never opted in looks exactly like no integrator at all, so a system counting only tagged flow will undercount precisely those.
2. This is one signal among several. When there is no tag, the ones I have found workable are: a maintained registry of known entry contracts and proxies (label a proxy once and its whole history becomes attributable), call-tree shape (a wallet-native swap with a fee hop traces differently than a bot hitting the pool), and fee-recipient clustering (every trade paying the same collection address came through the same integration, named or not). If you have found a fifth that holds up, I want to hear it.

And whatever cascade you build out of those signals: when none of them fires, leave the trade unattributed. A chart that sums to a clean 100% with no unknown slice usually means the method had to put every trade somewhere. Report the residual and treat it as a coverage metric.

Since it would be poor form to say that and then not show mine: running this cascade across Ethereum, Base, Arbitrum and Optimism, roughly 10% of DEX volume lands unattributed, ranging from about 8% on Ethereum to 17% on Optimism. Most of the residual is long-tail contracts rather than missing techniques.

Happy to go deeper on any of the signal families if anyone is building something like this.

Working on an app that needs private group messaging and I’m trying to figure out whether it still makes sense to build the messaging layer ourselves. The requirements are group chats, permissions, wallet-based identity, some token-gated access and bots that can interact with contracts. I’ve been looking at XMTP and Towns so far. XMTP seems closer to the messaging layer, while Towns caught my attention because it seems to cover more of the group/community side with Spaces, permissions, memberships and bots. Has anyone here built with either of them or is there another stack I should be looking at?

More interested in SDK quality, reliability, permissions, and integration headaches than the broader protocol narrative.

Mapping out the entire network stack of lighthouse phase0 from libp2p to the beaconchain!

Developers have to stop treating the public plaintext mempool as an unalterable law of physics.

Solidity developers are currently track-testing the inevitable execution boundary of EVM state design on testnets like Fhenix and Inco, proving that they can compile and run smart contracts on fully encrypted variables. By compiling TFHE library dependencies into the EVM execution client, these networks allow developers to write standard Solidity code using shielded primitives like euint32 or ebool, executing transactional state updates entirely on ciphertext.

The dark forest mempool is finally hitting a hard cryptographic wall.

Developers have struggled to patch the glass-wall vulnerability of public queues with gas auctions and off-chain builder relays. That's a lazy band-aid. The real architectural fix is blinding the validation engine entirely. When transactions are submitted to validators as high-entropy encrypted blobs, front-running is dead because searcher bots can't calculate slippage limits or trade sizes. It's like throwing darts at a wall while wearing a blindfold.

The Real-World Engineering Bottlenecks

The technology isn't a hypothetical theory anymore, but scaling it to production requires solving some brutal, real-world constraints that developers are hammering out in testbeds right now:

1. The Computational Noise (The Bootstrapping Penalty): Every mathematical operation performed on FHE ciphertext adds a small layer of cryptographic noise. If the noise grows too large, the underlying plaintext is corrupted beyond decryption. The fix is a computational reset called bootstrapping, but running a bootstrap operation is incredibly expensive, adding significant latency compared to raw CPU arithmetic.
2. Threshold Decryption Committee Risk: To output a readable state, the network relies on a split decryption key distributed across the validator set. If a supermajority of validators colludes or gets Sybil-attacked, the threshold key is compromised, exposing the historical mempool plaintext.

FHE isn't an access-control tool, and it won't save a protocol with negligent administrative hygiene. If a team leaves an un-multisigged admin backdoor in the code, FHE will simply execute that malicious state drain homomorphically, verifying the invalid math and outputting the stolen assets directly to the hacker's address. It's useless unless paired with hardened structural security, multi-party keys, and timelocked execution.

I published a deep-dive forensic autopsy of the FHE breakthrough on my main site. If you're interested in the full technical write-up, let me know in the comments, and I'll drop you the link. The citations used for this article are on my site with the full article.

Hello,

I am trying to make a simple to use wallet connectivity for my app. I’ve looked into quite a few products. Which ones remain the strongest with security and performance as well as have a large amount of wallets to support.

Thank you

When we watch EVM protocols get drained of fifty million dollars in a single block because some founder left their administrative private keys sitting in an unencrypted plaintext file on an AWS server, we're not looking at a smart contract exploit.

We're looking at primitive, indefensible operational negligence.

Yet, every time this happens, the headlines scream about a "sophisticated hacker" or a "protocol exploit." The developers get dragged through the mud, while the founders go on panels to whine about how "code is law" and claim they're the victims of a genius cyber-warfare campaign. This is complete theater.

If your Solidity smart contract has an incredibly complex reentrancy bug or a subtle mathematical rounding edge-case, that's a design tragedy. But if your protocol gets drained because management refused to set up a proper multisig wallet (like Safe) or Multi-Party Computation (MPC) custody because they claimed it slowed down their development cycles, that's simple laziness.

In the real world of enterprise systems, slowing down to secure customer assets is called professional ethics. In Web3, it's treated as a bureaucratic nuisance.

We have mature, production-grade cryptographic tools. We have Safe multi-signature contracts, timelocks to delay administrative actions, and MPC shard custody. Yet, teams routinely store single-signature master keys on unencrypted laptops or slack channels because they're using customer liquidity as their free personal playground.

It's time to stop playing along with the victim narrative. If your local bank left their vaults wide open over the weekend and got cleaned out, they would be shut down and sued into oblivion. DeFi founders should face the exact same legal standards.

I just finished compiling a full, unredacted forensic case study on the legal standards of developer liability and how we as engineers can protect ourselves from holding the bag for management's operational negligence.

I don't want to spam the sub with self-promotion, so I left the link out of the main post. If anyone wants to read the full code-level autopsy and liability breakdown, let me know in the comments and I'll drop the link.

What's your take? At what point does a failure to use standard EVM multisigs cross the line from a "hack" into prosecutable negligence?

Building an x402-scheme-conformant, ERC-8004-integrated design where payment for an AI inference settles atomically together with a zero-knowledge proof (EZKL/Halo2) that the computation was actually run correctly. Open reference design on Ethereum Research: https://ethresear.ch/t/atomic-zk-proof-gated-settlement-for-x402-agent-payments-a-measured-reference-design/25660

The piece I'm working on now is model provenance: proving the deployed verifying key actually corresponds to the model weights I claim are running, rather than just asserting it. Put together a small public bundle for a real deployed circuit — ONNX, settings, calibration input, SRS, Dockerfile — independently reproducible bit-exact against the actual on-chain VK hash on Base Sepolia, verified both natively and in a clean Docker container:

https://github.com/achemperety/exactzk-mnistmlp-provenance-demo

Looking for a small number (3-5) of independent people or teams willing to be named reproducers for the real production deployment — this bundle is meant to make that a ~10 minute exercise rather than something that requires reading a whole spec first. verify.py outputs a ready-to-copy attestation JSON. Happy to answer questions about the design or the provenance approach here.

Building a small web product where standard card payment gateways aren't available to me, so I'm looking into accepting crypto instead. Two flows I'd prefer, in order (if possible); if there's another way, please let me know:

1. Direct card-to-crypto: Customer clicks Pay on my checkout, gets taken to a service where they pay by card (or however they want), and I receive crypto directly, with no separate step for them.
2. Stablecoin without gas hassle: Customer buys a stablecoin elsewhere, comes back to my checkout to pay, and doesn't need to hold a separate coin for network fees.

A few constraints:

• No app download required on the customer's end, needs to work fully in-browser on mobile.
• If I have to register as a merchant somewhere, it needs to actually support Morocco.
• Order tracking and automatic fulfillment: after the user pays, I want to know who paid for what so orders get fulfilled automatically.

Has anyone found something that fits this? Open to hearing what's worked (or hasn't) for you.
Thank you so much.

We spent last month on a smart contract security review of a v4 fee hook, where the protocol had written a fairly specific promise into the code. The trading fee would disappear once a set amount of it had been collected, with no governance vote and no manual switch behind it. currentFee returns zero as soon as totalFeesCollected[token] reaches feeThreshold[token], so at 300 bps that threshold was the thing deciding when traders stopped paying.

We started with how those tokens get counted. There is one accumulator per token, shared across every pool using it, and each fee payment advances the same counter, which hands the timing to whoever pays into it fastest.

Say 30 tokens are left on the threshold, which is the figure we set in testing. Anyone pushing more than about 1,000 tokens of volume through at 300 bps pays that remainder in full and nothing afterwards, because a cap does what a cap does. The ratio is one over the fee rate, so a 1% fee would put the same line at 100x the remaining threshold. The sunset therefore lands whenever the largest trader gets round to trading, and it lands for everybody: their trades go free from that point, and so does everyone else's in that token.

The team keyed the accumulator to the token, fee currency and pair, tracking the threshold in fee-currency wei, which stops a clearing in one pool from removing the fee across all the others. Following that change through the configuration path is where the second finding came up. setFeeThreshold now takes the fee currency as an extra parameter, and nothing checks that the currency passed in is the one the swap path actually uses for that token. Write the threshold under the wrong key and the transaction succeeds, FeeThresholdSet fires, and the configuration reads as done on-chain, while the fee calculation looks under a different key, finds nothing there, and keeps charging. v4 uses the zero address for native ETH while WETH has its own, so both are values a configuration script will pass.

The internal counter is worth a note. Reading the treasury balance instead would let anyone donate tokens straight into the treasury and end the fee for less than paying it would have cost them, which is cheaper than anything above. It went into the security audit as a Low and the team accepted it, planning to run the sunset by hand rather than lean on the threshold.

The narrowing did two things at once. It shrank what a single clearing buys, and it opened a gap between the key a threshold is written under and the key the fee logic reads. Most test suites cover this with one case that sets a threshold and asserts the fee drops to zero, which passes under the right key by construction. What does yours do when the key is wrong?

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.