I tested a narrow range for a while, but a big price move pushed me out of it pretty quickly, now i’m trying wider ranges and seeing how they hold up during volatility

User acquisition and compliance checks remain a massive cash burn for early-stage platforms. Every time a dApp onboards a user, the team pays a third-party verifier $2–$5+, stores sensitive PII they don't actually want liability for, and hopes the user generates enough LTV to break even on the check.

The entire flow feels backwards when verifiable credentials and ZK proofs already exist.

Instead of running redundant checks, the identity layer should work more like a shared credit:

1. Platform A pays for the initial verification (KYC, proof of humanity, or accreditation).
2. The user receives a portable, privacy-preserving credential tied to their address/DID.
3. When that user hops over to Platform B, Platform B just queries the credential proof instead of rerunning a full check.
4. Platform A receives a micro-fee for acting as the original verification anchor, turning an onboarding expense into an ongoing yield.

A few teams are starting to package this into single integration layers. Tools like Air3 / AIR Kit are essentially building modular SDKs around this to bundle ZK identity verification with cross-platform loyalty rails.

From an engineering perspective, what’s currently holding this model back from widespread dApp adoption? Is it the lack of standardization across credential schemas, or are platforms just hesitant to rely on third-party trust networks over their own compliance pipelines?

Hey everyone,

With the rapid rise of autonomous AI trading agents (interacting with Uniswap, cross-chain bridges, and lending protocols), there is a critical vulnerability that many agent frameworks ignore: pre-flight oracle and network integrity.

If an agent queries an RPC for an oracle price, and that RPC returns stale data due to network congestion, or if an L2 sequencer just rebooted and transactions are about to get MEV-sandwiched, most agent runtimes blindly execute and lose capital.

We built stale, a lightweight, pure Rust pre-flight security guardrail library:

• GitHub: https://github.com/Ramprasad4121/stale
• Crates.io: https://crates.io/crates/stale

Core Architecture & Invariants

1. Strictly Fail-Closed: Many Web3 libraries fail open (e.g., returning Ok or default values if an RPC returns a 500 error). In stale, any failure mode RPC timeouts, malformed ABI data, non-ASCII hex strings, or underflowing timestamps—strictly returns BLOCK.
2. Zero Runtime Panics: We eliminated all unwrap() and expect() calls across the runtime library. All arithmetic on token reserves and timestamps uses checked math, saturating math, or quotient-remainder decomposition to preserve precision on small amounts.
3. What It Guards:

• Chainlink Data Feeds: Staleness checks against configurable maxAge and multi-feed deviation detection.
• L2 Sequencer Liveness: Direct querying of official Sequencer Uptime feeds (Arbitrum, Optimism, Base, Scroll, Mantle, Metis, zkSync) with automatic enforcement of the 3600-second restart grace period.
• DEX Pool Depth: On-chain liquidity verification for Uniswap V2 and V3 pools before routing a swap.
• EIP-7702 Phishing Guard: Inspects bytecode headers to prevent agents from sending approvals to delegated EOAs masquerading as immutable contracts.
• OFAC Compliance: Direct on-chain verification against the Chainalysis Sanctions Oracle.

1. Model Context Protocol (MCP) & CLI: In addition to the Rust crate (cargo add stale), it includes a native CLI and an MCP server (stale-mcp) so LLM agent frameworks (like Claude Desktop or local agents) can use these checks as native tools.

Would love feedback, edge case suggestions, and contributions.

Building app's on Ethereum JOSN RPC can be tough because RPC providers (Alchemy, Quicknode, etc) all have slightly different apis, usage limitations, and are generally overpriced. Public providers are great but are even more limited, so I built Lasso which aggregates RPC providers into a single endpoint that routes to the best RPC provider for any given request. Its self hostable and quite easy to setup.

Would love some feedback from builders to see if this can help you: You can simply run the docker container and have high-throughput and reliable RPC access via public providers across Ethereum, Base, Robinhood chain, and some other L2s while also being able to add any other EVM chain and access it through a single endpoint.

Follow-up to the sqrt post some of you saw a while back. This time it's the exponential.

exp(int256 x) returns e^x in 18-decimal fixed point at 289 gas, max relative error 2.2e-14 (3.0e-16 absolute when the result is below 1). Reverts above 135e18, returns 0 below about −41.45e18 where the true result is under 1 wei.

It's a two-stage range reduction wrapped around a small rational approximation.

Stage 1 — split x = k·ln(2) + r, so e^x = 2^k · e^r. k is an integer division, and the 2^k comes back as a left shift at the end.

Stage 2 — divide r by 64, which is a right-shift by 6. That leaves an interval of [0, 0.0108].

uint256 k = x_ / LN_2;
x_ -= k * LN_2;
x_ >>= 6;

On that narrow interval a Padé[3/3] approximant does the work with a few multiplications and one division:

e^x ≈ (120 + 60x + 12x² + x³) / (120 - 60x + 12x² - x³)

Recovery is six squarings (2⁶ = 64) plus a shift:

y = y * y;
y = y * y / 1e54;   // ×3
y <<= k;

The part I didn't expect: the approximant is accurate to 1.7e-19 on that interval, and even after recovery amplifies the error 64×, it's still ~2000× inside the published bound. The approximation is nowhere near the limiting factor — fixed-point truncation is, mostly that >>= 6 discarding up to 63 wei of the argument before the approximant ever sees it.

I also spent a while on monotonicity, since exp() sits under option pricing and a primitive that dips could make a premium fall while its input rises. The smooth stretches turn out to be provable — the derivative's numerator is 24(x⁴ − 30x² + 600), which has no real roots — but the 255 points where the range reduction jumps are not, so those got swept exhaustively.

Full write-up with the derivations: https://defimath.com/blog/solidity-exp-a-fixed-point-exponential-in-289-gas/

MIT licensed, part of DeFiMath: https://github.com/MerkleBlue/defimath

Happy to answer questions.

I’m sharing an open-source project I developed after dealing with a real case involving a Ronin Waypoint/keyless wallet compromised through a malicious EIP-7702 delegation.

This is NOT a wallet recovery service. Do not send me your seed phrase, private key, recovery password, OTP, Waypoint token, client shard, or any other secret.

The problem was a recovery deadlock:

The wallet had a malicious EIP-7702 delegation, and any RON sent to the compromised wallet for gas could be swept before the owner had a chance to use it.

Need RON to remove the delegation
        ↓
Send RON to the compromised wallet
        ↓
Sweeper/drainer takes the RON
        ↓
Recovery transaction cannot be executed

So I developed and implemented a different recovery flow.

The compromised account signs an EIP-7702 zero-address deauthorization for:

0x0000000000000000000000000000000000000000

For Ronin Waypoint/keyless wallets, the authorization is signed locally through the Waypoint MPC flow.

The resulting signature is then verified locally to make sure it recovers exactly the affected wallet address.

A second, clean wallet acts as a relayer and pays the RON gas for the EIP-7702 transaction.

This means the compromised wallet does not need to receive any RON.

The flow is basically:

Detect active EIP-7702 delegation
        ↓
Generate zero-address deauthorization
        ↓
Waypoint MPC / keyless signing
        ↓
Verify recovered signer
        ↓
Clean relayer pays gas
        ↓
EIP-7702 delegation removed

I successfully executed the recovery on Ronin Mainnet.

Before:

code = 0xef0100<malicious_delegate>
eip7702 = true

After:

code = 0x
eip7702 = false
currentDelegate = null

The account nonce also advanced after the transaction, and eth_getCode changed from the EIP-7702 delegation indicator to 0x, confirming the deauthorization on-chain.

Recovery transaction:

0xc43b036de851ecdeb70050a0f72d232e1d48153607e4b504f63c04eef16c4223

I published a sanitized open-source implementation here:

https://github.com/YutsuKito/Ronin-7702-Recovery

The project:

• does not collect or transmit the victim’s seed phrase or private key;
• does not send the recovery password to an application backend;
• does not persist the Waypoint token or MPC/client shard;
• verifies that the authorization signature recovers exactly the affected wallet;
• performs fresh nonce and delegation checks before broadcasting;
• uses a separate clean relayer to pay gas;
• requires explicit broadcast confirmation.

I have also submitted the implementation to Ronin / Sky Mavis for technical review.

One important point:

Removing a malicious EIP-7702 delegation does not mean that an already compromised wallet should be considered safe again.

If an attacker still has another valid signing method or compromised credentials, they may potentially regain control.

The purpose of this tool is primarily to create a recovery window so affected users can move their assets to a newly secured wallet.

This is an independent community project and is not affiliated with or officially endorsed by Ronin or Sky Mavis.

Technical feedback, code review, and contributions are welcome.

And again: if anyone contacts you privately claiming they can recover your wallet and asks for your seed phrase, private key, recovery password, OTP, Waypoint token, or MPC shard, treat it as a scam.

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
),
-- one notional per transaction: a routed swap is several dex.trades rows
-- (one per hop/fill) that each carry ~the whole trade size, so summing them
-- overstates by the hop count. MAX() keeps the largest leg as the trade.
per_tx as (
    select
        calldata_tail,
        tx_hash,
        max(amount_usd) as amount_usd
    from tails
    group by 1, 2
)
select
    calldata_tail,
    -- tags ride on transactions, not fills
    count(*) as txs,
    sum(amount_usd) as volume_usd
from per_tx
where calldata_tail
      <> 0x00000000000000000000000000000000
group by 1
order by txs desc
limit 25

Edit, Aug 31: volume_usd now collapses each transaction to one notional (the max leg per tx_hash). The original summed every dex.trades row, which counted multi-hop swaps once per hop. Credit to u/icnews10 in the comments. txs was already per-transaction and does not change.

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.

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?

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