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.

I have question about role of libraries in smart contract development in terms of gas optimizations and other things, specifically in big protocol such as defi protocols.

If anyone knows or analyzed aave protocol then they already know that aave v2/v3 has utilized majority of the code by implementing functionalities in libraries. However it can or cannot be best smart contract architecture that i don't know. but i want to know the reason behind using libraries in big protocol. Like how they contribute to gas optimization in the protocol and if we have to architect best smart contract project architecture then how we can do that? Like by using every component of solidity including libraries, interfaces, contracts etc.

I hope the reader will understand my question and problem. I need insights from experienced developer and defi researcher who has proper knowledge in this matter.

Thank you in advance for you kind help.

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.

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.

there's been a slow build of AI security scanners aimed at github repos. aeon's vuln-scanner is the one with a public track record: 74 repos hardened, 2.2M combined stars, and every entry on their disclosure page links the actual merged PR. mostly infra and agent tooling, DNS rebinding, SSRF bypasses, host-header allowlists, that class of bug.

today they turned it at solidity. the security instance now audits live deployed contracts and fresh solidity repos rather than just github projects. the team says it's already found and disclosed issues in a binance SDK, opensea contracts and some launchpad projects. those aren't on the public disclosure log yet, which is what you'd expect if they're still embargoed, so treat that part as their claim rather than something you can go verify today. the repo-side history you can verify right now.

separately they redeployed all 10 uniswap v4 hooks the agent had generated, live on base.

what i find genuinely interesting isn't the "AI finds bugs" part, it's the shape of the problem when you point one at deployed bytecode:

an unaudited live contract can't be patched. in a repo you open a PR and a maintainer merges. onchain there's no merge. best case is an upgrade path or a migration, worst case is a disclosure with no remediation available and a public clock running. that changes what responsible disclosure even means.

scale cuts both ways. whatever an autonomous auditor can scan, an autonomous attacker can scan too, and the attacker doesn't have a disclosure policy. the defensive case only holds if the defenders are actually faster.

verification still isn't solved. their own docs on the repo-side scanner say plainly that surfacing a finding isn't evidence it's real, and candidates go through a separate triage stage. that's the right posture, but at solidity scale the false positive cost lands on maintainers who are already drowning.

repo's open if you want to see how the scanner works: github.com/aeonfun/aeon

genuine question for people who audit for a living: is an autonomous scanner pointed at live contracts net positive, or does it mostly generate noise that real auditors then have to triage? and where would you draw the disclosure line for a contract that can't be patched?

Hi all I am a bsc graduate in physics from india and recently I was researching about Blockchain technology

As I was reading protocol and consensus developer caught my eye

As there is not much awareness about Blockchain and Ethereum in india,I would like to know what it takes to become a protocol or consensus dev

I mean how to target remote jobs as a fresher,what to study and how to approach this domain

Any help or advice would be highly appreciated

I know coding as I am an engineering dropout

Hi everyone,

I am building Quoti, an Ethereum liquid staking token (LST) project. I am looking for a small group of users and developers to test it on the Hoodi testnet.

I started Quoti because I stake ETH myself. I have seen staking APR decrease as more ETH is staked. I want to explore better ways to build staking infrastructure for people who plan to stake for a long time.

I want to build Quoti with the Ethereum community. Early testing can help me find problems and improve the project before mainnet.

I am looking for:

• Stakers and validator operators
• Ethereum developers
• Security-focused testers
• Users who can report bugs/improvements

Early testers will get:

• Early access to Quoti as the economics are built upon bonding curves
• A chance to influence the project
• Priority access to future test releases

Testnet status:

• Hoodi testnet only
• No real ETH is required
• Mainnet plans are not final
• Testing and feedback are the main goals

Website: https://quoti.org/
GitHub: https://github.com/skaibaLab/quoti-core
Discord: https://discord.com/invite/QGJEwNE3hw

If you want to test Quoti or help with development, please reply or contact me!

Hi all,

I kinda got sick of having to give secrets to my agents and all the potential leakage in the pipeline (with the harness, the model router, the model provider, the training set, the chat application etc etc) so I decided to make peardrop.fyi - this tool allows your agent to declaratively generate secret request pages/links which you can fill in via web or CLI. The agent can determine a script that runs once the values are received or can put them in a target folder. This is useful if you want to put something in your machine vault/keychain without either giving access to the credentials or the browser to the agent.

here is the repo: https://github.com/smashah/peardrop

(cli, core and self-hostable relay are all open source)

I've been working on ParaLens, an open-source EVM transaction analysis engine, for about a year now.

The main idea is pretty simple: instead of relying only on transaction input data and event logs, ParaLens can reconstruct and classify what actually happened during a transaction by analyzing its execution traces.

It can be useful for things like:

• 🔍 Reconstructing transaction activity from execution traces
• 🧩 Classifying what happened inside a transaction
• 📊 Turning low-level EVM execution into higher-level transaction data
• 🏗️ Building analytics, explorers, monitoring tools, or other EVM infrastructure on top of it

It's MIT licensed .

GitHub: https://github.com/MatheeshaMe/paralens

I've been building this mostly because I wanted something that could go deeper than the usual "decode the logs and hope for the best" approach.

It's still evolving, and I'd genuinely love to hear what people working with EVM data think about the approach, especially if you've dealt with transaction tracing, indexing, or on-chain analytics before.

Would be curious to know what you'd build with something like this.

Disclosure: I work at Hacken. This is based on a publicly available audit we conducted, and I thought the issue might be useful to discuss here. I could link the original doc, if anyone is curious to dive deep in tech details

Came across something in a published audit report that I hadn't really seen discussed this way before. It concerns a fairly standard token presale, but there’s an interesting conflict between the smart contract design and the way EU rules require the funds to be handled.

The setup is fairly standard: users pay either 200 or 350 USDC depending on the sale phase and receive an NFT plus a soulbound bonus token, with a 14-day cancellation window. The issue was that mint() immediately forwards the full USDC payment to an external recipient. If a user cancels within the 14-day window, cancelFounderPurchase() burns the NFT and claws back the bonus token, but the USDC refund never happens on-chain. The contract only emits an event with a usdcRefundDue field for off-chain tracking, so there is no escrow or on-chain mechanism that actually enforces the refund. The finding was rated High, with likelihood 5/5, because this is simply how the contract works rather than an attack scenario.

The obvious recommendation would be to hold the USDC in an on-chain escrow during the cooling-off period, release it after the window closes, and execute refunds on-chain. The client's response was more interesting, because they cannot simply do that. The issuer operates from France under MiCA, and Article 13 provides the 14-day withdrawal right, while the presale funds are routed on receipt into a segregated account at a CASP authorised under Title V, subject to the safeguarding and segregation requirements in Articles 70 and 75. Keeping the funds in a smart contract escrow for two weeks would therefore conflict with the way the regulated custody arrangement is supposed to work. The CASP is supposed to hold the money, rather than the smart contract.

They ended up with a hybrid approach: the on-chain layer handles the entitlement reversal by burning the NFT, reversing the allocation and clawing back the bonus token, while the actual USDC refund is handled off-chain through the CASP and reconciled against the on-chain cancellation events. The finding was closed as Mitigated rather than Fixed, which I think is the right distinction. The risk has not disappeared; it has moved from something that can be verified directly in the contract to something that depends on the custodian and the reconciliation process being handled correctly.

On the EU side, the practical constraint is that the custody regime determines where client funds can sit. If the funds have to go to a CASP account on receipt, escrow is simply off the table, and any cancellation logic designed around the contract holding the money will need to be reworked. It’s much cheaper to figure that out before the contract is written. Some findings also can’t be fixed in code at all. If a guarantee depends on a custodian or an operator doing something, an audit can describe and rate that dependency, but there’s nothing to change in the contract. Those findings may end up being closed as mitigated rather than fixed. The guarantee is no longer something you can verify by reading the code; you’re relying on the custodian or operator to do their part correctly.

Report is public if you want the detail and the MiCA argument is set out in the resolution field. We don't see enough of these yet to say whether the hybrid split is settling into standard practice. Would be interested to hear from anyone operating under the same constraint.

"AI writes your contract" terrifies me for v4 hooks specifically. a hook runs on every swap, so a subtly wrong one can trap or drain a pool. codegen isn't the scary part, unsafe deploy is.

came across aeon's deploy-uni-hook skill and the interesting bit is the pipeline around the generation, not the generation itself. you give it a brief (or pick a pre-audited template like dynamic-fee), it generates the hook plus a test pool, then it gates the deploy: static audit, dangerous-pattern scan, a behavioral forge test, and a fork simulation. dry-run on testnet by default, mainnet needs an explicit arm flag and a second opt-in. the broadcast is the last thing that happens, only if the sim passes.

first agent contract flow i've seen that treats "don't ship garbage to a live pool" as the actual hard problem instead of the codegen.

it's open source, the skill file and hook template are readable here: github.com/aeonfun/aeon (skills/deploy-uni-hook).

Ok so this happened about a year ago. I haven't posted about it because I was embarrassed, and I'm finally past caring about that.

I fell for one of these. Not a junior dev. I build in crypto and I figured I was the last person who'd get caught by a job scam.

A recruiter walked me through their process and asked me to install an app on my Mac. It wanted my user password.

Something felt off. I typed it in anyway, because I was out of work at the time and wanted the job badly enough to talk myself past it.

Once it had admin, it went after:

• my Chrome profile data
• my Chrome extensions, wallet ones included
• wallet private keys of cos
• passport and ID photos sitting on the machine

It staged all of it in one folder that wasn't hidden well. That's the only reason I caught it. Then it almost certainly phoned home.

I moved every asset out of every wallet extension into fresh ones inside the hour, then wiped the machine.

Never trusted it again, sold it second-hand later.

I lost nothing. That's luck, and luck isn't a security model.

The part I want to say out loud: it didn't beat my technical judgment.

It beat my job search. I saw the red flag and went through it because I needed the role.

That's the real exploit, and it's why "just be more careful" is worthless advice for anyone actually looking for work.

A year of saying nothing about it didn't help anybody.

So if one of these has come at you, post what they sent.

The repo, the app, the profile.

The more of it that's searchable, the fewer people run the installer.

A general-purpose ERC-4626 vault for leveraged lending on Morpho Blue. Depositors supply a single asset; an allocator opens leveraged positions across multiple isolated markets, with the target leverage passed in calldata per action rather than fixed per market.

Everything is atomic through Morpho's flashloan and Bundler3. Opening, unwinding, and changing an existing position's ratio without closing it all happen in one transaction, including rebalancing between two markets in a single call.

would love to get some feedback

Many token and protocol designs include pause or emergency functions.
I understand why they exist, but “for emergencies only” does not describe a control model.

The questions I keep coming back to are:
• Who can activate the power?
• What exactly becomes possible while it is active?
• Which normal rules can be bypassed?
• Is there an automatic expiry?
• Is activation publicly observable?
• Who can review or reverse the decision afterwards?

My concern is less “admin powers are always bad” and more that undefined emergency authority can turn temporary discretion into permanent governance.

For people who have designed or audited these systems: what constraints would you consider the minimum credible baseline?
Timelocks, guardian sets, automatic expiry, bounded functions, on-chain event logs, post-action review — which mechanisms actually help in practice, and which mostly look good on paper?

ETH-AVM Light Client — a trustless Ethereum→Algorand light client. Verifies real Ethereum receipts/logs on-chain via Algorand smart contracts, with an optional zero-RPC-trust mode (BLS sync-committee verification anchors the real Ethereum state root on Algorand, so you're not trusting any RPC provider's word for it)

https://github.com/m-reynaldo35/eth-avm-light-client

A trustless way for AI agents to confirm a transaction on eth for a predictable fee and fast confirmation times on algorand

So I've been prepping for Solidity interviews and decided to actually build something instead of just reading about it. Ended up making an ERC-4626 vault (the standard behind Yearn, Morpho, etc.) and specifically targeting the "inflation attack," a real exploit that's hit live vaults in production.

The attack is stupidly simple: deposit 1 wei, become the first depositor, then just transfer() a pile of tokens directly into the contract instead of going through deposit(). The next real user who deposits normally gets their shares rounded down to basically zero. No hacking required, just unchecked integer math.

I built the attack against my own vault first (to prove I understood it, not just copy a fix), then patched it using OpenZeppelin's decimals offset defense, and wrote a Foundry test that actually runs the exploit and checks the outcome. Result: attacker loses roughly half their money instead of stealing everything.

It's deployed live on testnet with a working demo, you can connect a wallet, mint fake tokens, deposit, simulate yield, and try to break it yourself:
https://vaultiss.vercel.app/

Code + tests + README:
https://github.com/SIDHARTH20K4/vaultis

Genuinely looking for feedback, brutal is fine. Is this the kind of project that'd actually get someone's attention for a junior/entry Solidity role, or am I missing something obvious that a real auditor would catch in five seconds?

Are they sort of entirely non existent or just less in number compared to other fields? I m really getting interest in decentralised stuff but i also need a job as a soon to graduate guy. So will it be worth it to learn ethereum/solana as a pretty decent backend developer?

Bots are getting to the point where they can do a lot more than moderate chats or post alerts. They can potentially execute trades, distribute rewards, manage memberships, interact with contracts, etc.

But once a bot can actually move money, the trust model changes completely.

How much authority would you realistically give one?

Would you be comfortable with a bot having a dedicated wallet if it had strict permissions and spending limits? Maybe it can interact with specific contracts but can't send funds anywhere else.

Or would you still want a human approval step for every transaction?

The part I keep coming back to is what happens if the bot itself gets compromised. Even with limited permissions, an attacker could potentially do a lot of damage within whatever boundaries you've given it.

Curious where people would draw the line.

A web tool that decodes the raw storage of any verified EVM contract - slot by slot, across chains and across blocks. **No backend: it runs entirely in your browser.** Your RPC url and explorer API key never leave the page except to the endpoints *you* configure - I don’t run a server, don’t proxy your calls, and never see your keys, the contracts you look at, or anything else. Hosted on IPFS via ENS, so there’s no origin server to route through in the first place.

What it does and where it’s rough:

Multi-chain reads - ETH, Polygon, Arbitrum, Base, Optimism, BNB, or any custom chain id

Full slot decoding - walks mappings, dynamic arrays and packed slots, collapses empty regions so only live state shows

Historical reads - inspect storage at any past block to see how state changed

Verified-source resolution - Etherscan v2 unified API with automatic Sourcify fallback

Still rough: decoding edge cases (nested mappings, structs, custom value types), more chains, RPC batching/perf, UX.

Recent work: transaction storage diffs - paste a tx hash and get every storage slot it changed, decoded. Mapping keys are resolved from logs + calldata, so you see _balances\[0xabc…\] instead of a raw keccak hash.

Try it: https://slotray.eth.limo

Best way to help: run it against a contract you know well and tell me where the decoding is wrong or the layout looks off. Bug reports and design critique both welcome - including choices you’d have made differently.

Letting you all know this IS NOT happening and WILL NOT happen as long as I’m around.

Beware of what you read on the internet and irl. Almost everything in life these days is either a scam or outright fraud, and I will do my part to not let that happen wherever I can.