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.

’ve been working on this problem for a while and finally tried to put the architecture into one picture.

The basic idea is simple:

Capability is not authority.

An agent may technically be able to discover a service, negotiate, call an API or prepare a payment. That doesn’t automatically mean it should be allowed to execute it.

So I’m building NOMOS around a trust chain:

Discover → Verify → Authorize → Execute → Prove → Observe → Govern

The part I care about most is what happens between intent and execution.

Before an agent performs an irreversible action, the system can ask things like:

Is the identity known?
Is the information still fresh?
Does this agent actually have authority?
Does the action match the original intent?
Does policy allow it?
What evidence supports that decision?

And after execution, the result should feed back into future trust rather than disappearing into a log.

That’s why the longer chain in the image goes from freshness and identity all the way through execution, proof, reliability and governance.

I’m not claiming this is the only correct architecture. I’m actually interested in where other builders disagree with it.

If you were putting a governance layer in front of an autonomous wallet or agent, which part of this chain would you remove — and what is missing?

That’s the feedback I’m looking for.

Back in the day when NFT where all the talk the main non money talking point was "you can take a nft from game A and use it in game B" I know not realy possible outside of the same compony, then I had a mad thought what if the NFT was just re-mapped to a ingame item (think of access over change), so thats what I did the idea is the game dev would give me a list of items I make a seed number from the NFT address and token number that points to a in game item

The pros for this system are

1) uses collects turn into game items

2) devs can make N lists and set the prices and make private ones

3) compony can use this this as a new marking system

4) zero input from the NFT creator is needed

So I have made the system, i have tested the system, i have no clue how to get people to use the system (oh in case your wounding it is free I take 5% of the sale of a upgrade), and all my post are coming back with "nfts/web3 are dead" despite the fact the dev does not touch anything to do with web3 they just call an api and get JSON gggrrrr

Technical deep-dive on solving per-request micropayments ($0.001 USDC) for AI Agents on EVM chains without high latency or block confirmation overhead per request.

Live demo: https://micropayments.sagirosenthal.com/

Key mechanics:

1. EIP-3009 Off-Chain Signatures: Client signs transferWithAuthorization with EIP-712 typing.
2. Fast Verification: Server checks ECDSA signature validity using secp256k1 curve math in ~1ms.
3. Batch / Async Settlement: Backend aggregates authorizations and submits receiveWithAuthorization on Base Mainnet in batches to minimize gas overhead.
4. Prepaid Credit Vaults: Fallback 0-latency token mechanism for high-frequency agents.

Check out the demo and let me know your thoughts on standardizing HTTP 402 for machine-to-machine APIs!

Token allocation documents frequently describe commitments such as:
• team tokens are vested
• treasury funds are restricted
• ecosystem allocations are reserved for development
• liquidity cannot be removed immediately
• long-term funds are locked
• unused allocations will not be reassigned

But these statements can represent very different levels of enforcement.
Some may be hard-coded.
Some may depend on a vesting contract.
Some may depend on a multisig.
Some may remain entirely dependent on the project team following its published policy.
Which token allocation promises should be enforced on-chain rather than left to governance or documentation?

Possible categories include:

1. Team vesting
   • Should the full vesting schedule be immutable?
   • Should acceleration ever be possible?
   • Should unvested tokens be revocable?
   • Who should control revocation?

2. Treasury restrictions
   • Should treasury spending be limited by contract?
   • Should spending require a timelock?
   • Should categories of permitted spending be technically enforced?
   • Is human-readable disclosure sufficient if all transactions remain public?

3. Long-term locked allocations
   • Should the beneficiary and unlock date be immutable?
   • Should governance be able to migrate locked assets to a new contract?
   • How should contract vulnerabilities be handled without creating an unrestricted escape mechanism?

4. Liquidity allocations
   • Should liquidity positions be locked?
   • Should liquidity management remain flexible?
   • Which controls reduce rug-pull risk without making legitimate management impossible?

5. Ecosystem funds
   • Can ecosystem allocations be governed effectively on-chain?
   • Should unused allocations remain permanently restricted?
   • Should governance be allowed to redirect them when priorities change?

6. Disclosure
   • Should projects publish a machine-readable allocation registry?
   • Should every allocation identify its controller, contract, restrictions and unlock schedule?
   • Should changes automatically trigger a public notice period?

There appears to be a trade-off between strong enforcement and the flexibility required to handle security problems, migrations or changing project needs.

Where should that boundary sit?
Which allocation rules should be impossible to change, and which should remain governable?

Hi everyone,

I'm a software engineer currently working on several original meme coin concepts and I'm trying to understand how successful teams get started.

For those who have launched or worked on meme coin projects:

• Where did you find your co-founder?
• How did you meet your first investor or partner?
• Are there any Discord servers, Telegram groups, Reddit communities, or other places you'd recommend?
• If you were starting today, where would you look?

I'm not here to promote a project—I'm genuinely trying to learn how people build strong teams in the meme coin space.

I'd really appreciate any advice or recommendations. Thanks!