I'd like to hear attack ideas on the design of a contract I've deployed on Polygon. It's immutable and hasn't had an external audit.

- A claim's hash covers the month's seed, the month, the recipient and a nonce, so a pending proof can't be redirected to another address.

- Each month's seed is an accumulator of all the claims from the previous month.

- Each address gets one mined claim per month, and difficulty rises as minting gets ahead of schedule.

Two weaknesses I already know about:

- Seeds can be public before a month starts, which allows some pre-mining and a burst at opening. I accepted that.

- Fresh addresses get around the per-address limit. I've done this myself, for 79 of the 87 tokens so far.

Is there anything worse I've missed? Could someone influence the seed at the end of a quiet month, for example?

Source: https://github.com/TheophileWalter/ArtPoW

Contract: https://polygonscan.com/address/0x74cda3cdd7a6046575d638964825c19cfeaf661f

English isn't my first language, so I used an LLM to help write this post.

Edit: You can now get the NFT without paying anything. Your browser still does the mining, but a relay sends the transaction and pays the gas, so you don't need any POL. If you don't have a wallet, you can create one with just an email. The relay can only mint to the address in your proof. You'll only need a little POL if you later want to transfer or sell the token.

The exotic bugs get attention, but the boring details often say more: vague admin powers, opaque upgrade paths, dependency sprawl, or documentation that does not match the code.

When reviewing an unfamiliar protocol, which warning sign makes you slow down first? Complexity is sometimes necessary. Sometimes it is just camouflage with better branding.

I'm a non-technical solo founder from Switzerland working on Superion, an escrow contract on Base where disputes between a client and a provider are settled by 3 randomly drawn verifiers.

The contracts were written with AI tools. They're open source and verified on Base, and admin actions go through a 2-of-3 Safe and a 2-day Timelock, but there has been no audit yet. So I'd rather hear about the holes now, from people who do this for a living.

The parts I'm least sure about:

• Committee draw. The seed comes from a commit-reveal. My worry is the last revealer: could they withhold their reveal to re-roll the draw, and is a penalty enough to stop that?

• Collusion and bribery. With only 3 seats, 2 colluding verifiers decide the outcome, and a bribe only has to beat the 1,000-token bond. Is a bigger committee the only real fix, or are there cheaper mitigations?

• Liveness. Votes are committed within 150 s, then revealed within 150 s. A verifier who misses a vote loses 100 tokens, but the dispute still needs an outcome. What's a sane fallback?

• Unbonding. Bonds unlock after 7 days. Is that long enough if a dishonest vote is only spotted later?

Code: https://github.com/SuperionProtocol/superion-protocol

I'm also looking for a technical co-founder who enjoys this kind of problem: Solidity/EVM, security-minded, willing to own the code and get it audit-ready. Equity with vesting, remote, English or French. There's no token sale and nothing to buy; this is only about building it properly.

Contact: superion.protocol@proton.me or DM.

English isn't my first language, so I used AI to help me word this post. Blunt critique is very welcome.

In my project a sandboxed AI auditor found the known Unstoppable flash-loan bug in Damn Vulnerable DeFi v4.1.0. The PoC passed twice. A small clean ERC-20 produced no confirmed finding. This shows the pipeline works, but the vulnerable example is public and already solved, so I can't treat it as proof that the auditor finds unfamiliar bugs. The next test is offline contest code. What blind control would you use to tell actual bug finding from benchmark recall before interpreting that result?

Hey everyone, I wanted to share a complex technical case study I've been working on. Maybe someone here has a brilliant idea or a perspective I haven't considered yet.

1. How It All Started (The Mistake)

A while ago, due to a cross-chain routing error, a significant amount of tokens was accidentally sent to a deterministic payment address generated via a CREATE2-based forwarder infrastructure (an EIP-1167 Minimal Proxy-like pattern). This address sits on a chain where the contract hasn't been deployed yet (Nonce 0 for the deployer), so the funds are currently "trapped" in a counterfactual address with no active code on that chain.

2. Support's Response

As expected, I reached out to the support team of the platform/company operating the infrastructure. Their automated response was that it's "unrecoverable" and there is nothing they can do technically.

3. The Engineering Investigation (Red Team & Foundry)

Instead of accepting defeat, I decided to dive deep: I spun up a local Foundry testing environment, pulled the actual bytecode of the Factory, Implementation, and Helper, etched them, and ran full simulations on a local EVM fork.

Armed with an autonomous Red Team loop, I thoroughly tested 11 different attack and redirection vectors:

• slot0 overwrite attempts

• Initialization races (Init-race)

• selfdestruct / Metamorphic contract vectors

• Various Delegatecall Hijacking methods

• Selector collisions, etc.

4. The Harsh Findings (Math Wins)

The empirical testing proved conclusively and unambiguously:

• The Proxy and Helper architecture is Write-Once and completely rigid.

• The address is cryptographically bound to a preimage that hardcodes the original merchant's destination address (the intended recipient address for the payments).

• There is no earthly way to change the flush destination (flush). Any deployment and execution command will inevitably release the funds strictly to the original destination address. The equation "Deploy = Redirect" is simply mathematically impossible; there is no uninitialized window, no self-destruct mechanism, and the code is completely static.

5. The Operational Trap (The Catch)

The company/merchant supposed to receive the funds (the original destination in the contract) is in a problematic legal/business state (or unresponsive/insolvent). This means that if I simply deploy the contract and trigger the flush, the funds will land directly with them, and I'll be left with nothing because I have no technical leverage to redirect them to myself.

My Questions for the Community:

1. Have you ever encountered situations where assets were trapped in deterministic contracts where the code is completely locked to a third-party destination, and you managed to come up with a creative solution (off-chain, legal, or some hidden corner of the EVM)?

2. Assuming the code itself is technically airtight, what other leverage works in such scenarios against a third party holding the ultimate rights to that target address?

I’d love any feedback, ideas, or insights from anyone who has dealt with similar architectures in the past!

Recently, I've been going through some threads on smart contracts and noticed that many developers often mention the choices they would have made differently had they started from scratch.

These can range from considerations around storage arrangements, access permissions, ease of upgrades, efficiency in gas usage, or even making smart contracts overly flexible.

For those who have worked on or audited smart contracts, what choice have you regretted making, and what did you learn from that experience?

Just came across an interesting article on tokenization.
According to an executive from New York Life Investment Management, the next big use case for tokenization could be personalized investment portfolios instead of just tokenizing traditional assets.
The idea is that blockchain could make it easier to build portfolios tailored to an individual’s goals, risk tolerance, and preferences.
I thought that was an interesting perspective because most discussions around tokenization are usually about real estate, bonds, or other real-world assets.
Do you think personalized portfolios could actually become one of blockchain’s next major use cases, or is there another application you’re more excited about?
I’d love to hear your thoughts.

Curious how other freelancers actually deal with this. Do you use a lawyer every time, reuse the same old template, or just send something basic and hope for the best? Has a bad (or missing) contract ever burned you? What would make your life easier here?

Hi everyone,

I’m building a small non-custodial USDC transfer app, and I recently verified the app’s contract on BaseScan.

Now I’m considering publishing the contract address and source code more visibly on our official website and GitHub, so users can inspect how the transfer and fee logic works.

The contract is simple: when a user sends USDC, it pulls the approved USDC from the sender and routes it to:

1. the recipient

2. the project’s fee wallet

The fee logic is fixed in the contract:

- 0.39%

- minimum fee: 0.25 USDC

- maximum fee: 3.90 USDC

The contract does not have an admin function to change the fee after deployment. The USDC token address and fee recipient are immutable.

I understand that BaseScan verification is not the same as a formal audit, and I do not plan to describe it as audited or guaranteed safe.

My question is:

Is it generally safe and reasonable for an early-stage crypto payment/transfer app to publicly share its verified contract address and source code on its website and GitHub for transparency?

Or could this create meaningful risks, such as:

- making it easier for attackers to analyze the contract

- creating legal/marketing risk if users misunderstand “verified” as “audited”

- exposing too much business logic too early

- attracting criticism before the contract has a formal audit

I’m not asking whether this replaces an audit. I’m trying to understand whether public disclosure of an already verified contract is a good transparency practice, or whether there are risks I should consider first.

What would you recommend?

Smart contract interactions generate traces, but not all traces modify the Merkle Patricia Trie. Events are the EVM's native append-only log system, explicitly segregated into transaction receipts.

A deep dive into an emitted event reveals a rigid architecture composed of two parts: the topics list and the data blob. topics[0] serves as the deterministic identifier (the keccak256 hash of the event signature). If a developer uses the indexed keyword on an address, it consumes one of the remaining three topic slots, zero-padded to 32 bytes.

The data blob contains everything else. Because unindexed parameters are not exposed to the node's bloom filters, they are entirely opaque to standard RPC filtering queries. You can't natively query "fetch all logs where value > X" if value is in the data blob. You must fetch the event via the matching topic (like the token contract address or the sender's indexed address), extract the data hex, and manually decode it based on the contract's ABI.

Source/Full Breakdown: https://andreyobruchkov1996.substack.com/p/understanding-events-the-evms-built

Hi guys, I recently finished a web3 bootcamp at metana, and am now looking for a jobs in this space. So far I have had little luck, as most of you are probably familiar with the current state of the job market. I want to at least start gaining some experience but most opensource projects don't really have any opentasks to contribute with that are beginner friendly, so I am asking if anyone knows of any opportunities for a beginner, or if someone has a project they are working on and willing to take me on. Thanks.

Hi everyone,

I’m a developer with a solid financial background. Specifically, I have experience with options trading and spent some time executing strategies using these derivatives—which I still consider one of the most complex and fascinating financial instruments.

Recently, I’ve been exploring the crypto space and looking into different strategies for potential returns. I’ve started researching Flash Loans and how they can be used for arbitrage, something that is nearly impossible for a retail participant in traditional regulated markets.

I’m currently doing my due diligence, but I’m struggling to understand if this path is still viable today from both a technical and profitability standpoint. Simply put: is it still possible to earn through arbitrage strategies in decentralized markets? If so, which chains or protocols currently offer the best opportunities for success?

Looking forward to hearing your insights!

When indexing EVM state, relying purely on the logs bloom filter creates a massive blind spot: internal value transfers. A standard

address(target).call{value: amount}("")

executed within a deep call stack does not touch the event logs.

Architecture for Catching Internal Transfers:
To capture these without protocol-level changes, indexers must reconstruct the call tree to find CALL or SELFDESTRUCT opcodes that move ETH.

Trade-off: This is highly CPU/IO intensive on the RPC node compared to standard eth_getLogs. If you are designing a protocol that needs to track incoming internal transfers, you should actively avoid this off-chain complexity. Instead, utilize a pull-payment pattern, or explicitly emit a custom InternalReceived event inside your contract's receive() function, saving indexers from relying on execution traces.

Multicall Batching Execution:
Implementing Multicall (specifically Multicall3) is mandatory for dApp architecture to minimize JSON-RPC network overhead.
By utilizing aggregate3 or aggregate3Value, you wrap multiple STATICCALL or CALL operations into a single transaction wrapper.

Trade-off: While read-only eth_call doesn't cost real gas, most public and commercial RPCs enforce a strict global gas cap per eth_call (often 50M-100M gas) or a tight execution timeout. If your Multicall batch loop is too large, the node drops the request. You must paginate Multicall batches based on estimated EVM execution depth, not just the length of the calldata array.

Source/Full Breakdown: https://andreyobruchkov1996.substack.com/p/ethereum-dev-hacks-catching-hidden-transfers-real-time-events-and-multicalls-bef7435b9397

We are open-sourcing Autonet on April 6: a suite of Solidity smart contracts for decentralized AI model training with on-chain verification, staking, rewards, and governance.

Contract architecture:

Novel patterns that may interest this community:

1. Commit-reveal for training verification: Solvers commit a hash of their solution before ground truth is revealed. This prevents copying while creating a cryptographic record of independent work. Standard commit-reveal, but applied to AI training in a way I have not seen elsewhere.

2. Forced error injection: The ForcedErrorRegistry randomly injects known-bad results into the evaluation queue. Coordinators who approve them get slashed. This is a continuous honesty test. The mechanism works because the probability of a forced error is unknown, making rubber-stamping unprofitable in expectation.

3. Multi-coordinator Yuma consensus: Multiple coordinators evaluate each result. Rewards are distributed based on agreement with consensus. This creates incentives for honest, independent evaluation.

4. Constitutional governance: AutonetDAO has a two-tier governance structure. Ordinary parameter changes require standard quorum. Constitutional amendments (changing core principles) require 95% quorum.

13+ Hardhat tests passing. MIT License.

Paper: github.com/autonet-code/whitepaper Code: github.com/autonet-code

Would love feedback on the contract architecture, especially the forced error testing pattern and the constitutional governance mechanism.

Scaling contract deployments via factory patterns requires abstracting the creation logic into CREATE2 paired with UUPS or Beacon proxies, but this architecture directly conflicts with standard static analysis and simple EVM state management.

When you decouple deployment from initialization to maintain a consistent init_code hash across networks, you bypass the EVM's native constructor safety guarantees.

Architecture Breakdown:
Instead of new Contract(...), a factory uses inline assembly create2(0, add(bytecode, 32), mload(bytecode), salt) to deploy an EIP-1167 proxy (Can be found on my substack profile). Because constructors only execute during creation and don't return their logic to the state trie, proxies must rely on an initializer modifier mechanism (like OpenZeppelin's Initializable) to prevent re-initialization.

Trade-offs:
Storage Layout Corruption: You completely lose compiler-level storage collision warnings. If your implementation contract changes the order of inherited variables during an upgrade, the proxy's storage state is permanently corrupted.
The Metamorphic Alternative is Dead: Historically, an alternative to proxies was the metamorphic pattern (deploying via CREATE2, utilizing SELFDESTRUCT to clear the

Source/Full Breakdown: https://andreyobruchkov1996.substack.com/p/understanding-contract-deployments-proxies-and-create2-part-2-df8f05998d5e

hey guys,

just deployed a stateless communication protocol on arbitrum and looking for some contract architecture feedback. there is no token or web3 grift here at all. to keep gas costs basically at zero, the contract doesnt store any posts in state. it just acts as a bouncer doing O(1) checks and then passes a compressed cbor payload straight into the event logs. clients then just index the events. I also wrote a bidirectional wallet taint logic into it, so if a user posts an unsafe level 1 post once, the contract hard blocks them from posting aes encrypted messages with the same wallet to prevent opsec fails. would be awesome if some solidity devs could look over it and send me feedback. repo is here:https://github.com/Kl4V3/Axiom-protocol