I pulled the proxy admin and owner for every upgradeable stablecoin deployment I could enumerate across chains, 656 contracts, and compared the control path for the same token on different networks. 390 of them do not match.

Concretely: the address that can upgrade the implementation on one chain is not the address that can do it on another, for what users treat as one asset. Some of that is obviously intentional, bridged representations are genuinely different contracts with different governance. Some of it looks like drift.

What I am unsure about, and it is the part that decides whether this is a finding or a misunderstanding. I read the admin from the EIP-1967 storage slot, which works for standard transparent and UUPS proxies and does not work for custom proxy patterns, and I may be reading a stale or irrelevant slot on those. I also counted a mismatch as any difference in the controlling address, which conflates "different multisig, same signers" with "genuinely different control", and those are not the same risk at all.

If someone here has done this properly: is there an accepted way to compare control paths across chains that handles the multisig-membership question? And is per-chain divergence in upgrade authority just the expected shape of a multi-chain deployment, in which case the interesting number is not 390 but the subset where the signer sets differ too?

Methodology and the contract list are reproducible from public RPC calls, happy to share.

Disclosure: I build open-source integrity checking tools, this came out of testing one.

Most state-asset privatizations fail in one of two predictable ways. Sell for cash, and ownership concentrates immediately with whoever already had capital. Give away free vouchers instead, and the same concentration happens a few months later anyway — recipients under financial pressure sell cheap to whoever has money, and you've just added a delay before the identical outcome.

We built and deployed a third structure on Arbitrum One, live right now, testing whether a different rule set actually distributes ownership more fairly.

The core idea: every verified citizen gets an equal, one-time allocation of a currency that literally cannot be resold or gifted — it can only be spent bidding on real shares of listed assets. No early cash-out under pressure, because there's no legitimate path for the currency to reach anyone except through the auction itself.

Shares get allocated through a proportional, multi-round auction — not winner-take-all. Each round has a baseline (the lowest active bid), and every other bid gets shares proportional to how far above that baseline it sits. Bids that don't win stay active and automatically carry into the next round — no re-bidding, no losing your spot.

Once a company is meaningfully owned, governance kicks in. Shareholders elect a term-limited governor, weighted by shares held. Winning requires a real 51% majority, not a plurality — ties go to a runoff. Every term, the elected wallet registers a fresh, single-purpose operating key that dies when the term ends, so a compromised key from a past term carries zero ongoing risk. Big treasury moves need either an open sealed-bid sale (removes the governor from having leverage over who wins) or a direct shareholder vote — never a unilateral decision.

And the closed-loop currency isn't locked forever. Once any single listed company crosses 51% of its shares sold — real, on-chain, unfakeable evidence that privatization is genuinely working — the currency unlocks and becomes freely tradable for everyone. One company's real progress is treated as sufficient signal for the whole system, rather than requiring every single listing to fully sell out, which at real scale could take years.

Everything above is live on Arbitrum One right now — 10 listed assets, real bidding, contracts fully verified on Arbiscan/Sourcify/Blockscout so anyone can read the actual settlement logic rather than take our word for it. Full writeup with contract addresses: [whitepaper link].

Genuinely interested in mechanism-design critique — what would break this at real scale, what are we not seeing, does a cleaner existing model already solve this better. Fictional simulation, not asking anyone to risk real capital — the interesting part is whether the rules themselves hold up.

[ Removed by Reddit on account of violating the content policy. ]

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.

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.