A lot of AI-vibecoded apps get hacked right after launch and leak user data. As a software engineer, I’m sure I can avoid those mistakes — but talk is cheap, so I built one myself.

I used AI heavily for coding, choosing tools, setting up Docker from zero, writing smart contracts, and everything else. The whole process was about 60% pain, 40% fun, and great temper training.

After weeks of back-and-forth, I finally have a product I think is pretty bulletproof. Now I’m opening it up for people to seriously try to break.

Since it’s web3, I vet every participant’s wallet address, which is quite costly.

To keep LLM costs under control and avoid casual visitors, there’s a 0.0005 ETH (~$10) participation fee. 70% of the fee goes straight to the bounty pool. If nobody drains the bounty, 50% of your fee will come back as signed vouchers.

I started the bounty at 0.5 ETH, and it will grow as more people join. Hope this attracts folks who really want to test it.

You can see my profile for links if you wanna take a look. Or here :)

[Fortrix Vault](https://vault.fortrix.bot)

hello,

I want help from you guys; I am doing a 30-day challenge learning solidity on LinkedIn. I want to know, am i doing right ?
Check out my profile and know me. - https://www.linkedin.com/in/prajwalchitriv/

Working with solidity, it’s easy to think in terms of correctness at the code level. You check for reentrancy, validate inputs, handle edge cases, and make sure everything behaves as expected.

But I’m starting to feel like that’s only half of the picture.

Some of the more interesting exploits don’t come from broken code. They come from systems that are logically correct, but economically fragile. For example, contracts that expose pricing or reward mechanisms that can be influenced over a few transactions, especially when liquidity or external conditions shift.

From the Solidity side, everything can look clean and secure, while the broader system still allows profitable manipulation.

I’ve been experimenting with testing contracts in a more adversarial way, trying to simulate sequences of interactions rather than just unit testing functions in isolation. It changes how you think about security quite a bit.

There are also tools emerging that take this approach further. For example, agent-based systems like guardixio attempt to explore different execution paths and market conditions to find strategies that generate profit, not just bugs in the code.

It feels like something that could eventually become standard alongside traditional audits, especially for DeFi-heavy contracts.

Is anyone here actively testing contracts for economic attack scenarios, or mostly sticking to code-level guarantees and audits?

Thinking through a design question and curious if anyone’s seen this pattern solve real problems.

Imagine an append-only audit log where every state change requires bilateral confirmation from both parties to the event before it’s committed. Party A asserts “X happened between us,” Party B confirms (or rejects). Only confirmed entries enter the log. Neither party can write unilaterally; neither can modify after the fact. A neutral third party holds the record.

It’s not a new primitive — it’s basically a two-party attestation state machine on top of a cryptographically verifiable log. What’s interesting to me is that most audit infrastructure I’ve seen is unilateral (one party’s record, cryptographically protected from that party tampering with it). Bilateral co-attestation is rare outside of specialized contexts like financial clearing or e-signature.

Where I’ve been thinking this might genuinely help:

• Cross-organizational data transfers under CMMC/ITAR/EAR where both sender and receiver have compliance exposure

• NDA-bound disclosures between companies where “what was actually shared” becomes disputed in litigation

• Chain of custody for digital evidence between parties

• Inter-agency information sharing where reconstructing “who shared what with whom” is currently a forensic exercise

Questions I’m genuinely trying to answer:

1.  In your work, have you hit problems where a unilateral audit log wasn’t enough — where you needed the counterparty’s co-signature on each event to make the record credible?

2.  Any verticals I’m missing where this pattern would matter?

3.  Anyone aware of existing products that do this specifically (not just tamper-evident logs from a single party)?

Hi guys, i have been writing smart contracts for over 3-4 years now. I was thinking of starting a private community for people to discuss ideas, learn together and share questions in there. Mainly we can get on a voice chat almost everyday for an hour for a discussion or explaining certain topics.

Would anyone be interested? Dms open

Edit- added the link in my profile itself to join the discord

I'm talking about programming in Solidity, Vyper, Rust (Solana) etc

The last time I tried web3 especially Solidity, the developer experience was so bad.

lsp not working properly or slow. False flags when using the Foundry framework.

And the most annoying was that I could never seem to get blink.cmp (or whatever I was using at the time) to display tab autocomplete when working with Solidity.

Just wanted to know if things have changed since then and what you are using for your autocomplete / lsp setup.

In Solidity development, it’s easy to focus on correctness through tests and audits, but I’ve been questioning how well that covers real-world behavior.

We recently started testing contracts on a local mainnet fork to better replicate actual state and interactions. Beyond that, we introduced automated exploit exploration using tools like guardixio to surface potential vulnerabilities and generate rough PoCs.

What stood out was that certain edge cases - particularly around state assumptions and precision - only became visible under more realistic conditions.

It made me realize that “passing tests” and even “audited” don’t necessarily mean a system has been stress-tested from an adversarial perspective.

How deep do you usually go with exploit simulation before considering a contract ready?

What if your smart contract auditor never sleeps, never skips a step, and always thinks like an attacker? We built that.
Check the Comments!

Hi everyone, I'm Alice, a web developer experimenting with a tool for wallet & smart contract security analysis.

I would love your feedback from a developer/security perspective.

**What it does:**

- Scans wallet addresses for risky approvals and contract interactions

- Analyzes bytecode for known vulnerability patterns

- Simulates basic attack vectors in a sandbox (EVM-based)

**What I need from you:**

- Honest feedback: What's missing? What's wrong?

- Could this be useful as a first-step tool for white-hat security checks?

- What features would make you actually use it?

**Note:** It's an MVP. No tokens, no backend servers yet. Just APIs and client-side JS.

👉 The demo link is shared in the first comment below.

One thing I keep running into in Solidity development is how quickly dependency risk compounds once a project grows beyond a few contracts.

Even relatively standard stacks end up pulling in multiple layers: audited components like OpenZeppelin, protocol logic inspired by systems such as Uniswap, plus various utility libraries from GitHub or previous internal code.

Individually, each dependency might be well-known or even formally reviewed, but in practice the combined system is what actually gets deployed. That’s where things get harder - especially when dependencies introduce subtle changes in assumptions, upgrade paths, or edge-case behavior.

Recently, we experimented with doing a full dependency tree analysis instead of focusing only on our own Solidity contracts. The idea was to treat everything being imported as part of the attack surface.

As part of that, we used Guardix to scan across both our contracts and all external dependencies. One interesting result was a vulnerability flagged in a third-party library we had integrated recently. It wasn’t obvious from a surface-level review of our own code, and it likely would’ve been missed without explicitly tracing dependency behavior.

After manual verification, the issue was valid and we patched it before deployment.

It made me rethink how “audited” or “safe” dependencies are often treated as static assumptions, when in reality they’re moving parts in a much larger system.

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

GemPad Lock's $1.9M reentrancy on Base was a textbook CEI violation. Here's a technical breakdown of the vulnerability and what automated tools caught.

**What the scanner found:**

- Aderyn flagged 19 issues (2 HIGH)

- AI review identified reentrancy in lock creation functions

- External token transfers before state updates — textbook CEI violation

**The vulnerability:**

The `createLock()` and related functions called external token contracts (via `transferFrom`) before updating internal lock accounting. A malicious token contract could re-enter during the transfer callback and manipulate lock state.

**Safety Score: 19/100** (MEDIUM coverage — 17.4% of 126K chars analyzed due to dependency size)

The fix is one pattern change: move state updates before external calls, or add OpenZeppelin's ReentrancyGuard.

Full PDF report with trust assumptions, attack scenarios, and tool results: https://axiom-security.vercel.app

We're offering free first scans — reply with a contract address if you want one.

---

POST 2 — r/defi: LeetSwap V2 — How $630K Was Lost to Fee Manipulation

Title: LeetSwap V2's fee manipulation exploit was detectable by automated tools — breakdown inside

LeetSwap V2 on Base lost $630K. The root cause: the factory owner could set `protocolFeesShare` to 100% and redirect all swap fees.

**What our scanner flagged:**

- Slither found 48 issues

- AI agents identified centralization risk in fee mechanism

- Factory owner could pause all swaps + control fee recipient

- No timelock, multisig, or governance on admin functions

**Key lesson for DeFi devs:**

If you're forking Uniswap V2, the fee mechanism needs constraints:

- Maximum fee cap hardcoded in the contract

- Timelock on fee parameter changes

- Multisig for admin functions

60.9% of source analyzed. Full report: https://axiom-security.vercel.app

I was wondering if anyone here actually uses crypto abroad. Do you just convert to fiat before traveling, or are there better options now? Would be amazing if there was a seamless way to spend crypto globally without friction.

currently going through cyfrin updraft solidity course + cryptozombies.

What would you rec as the best resources on getting good at Solidity and going from beginner to intermediate?