Vibe coding is hyping right now. No doubt LLMs can help programmers with programming, but can they help humanitarians create something that works — and that is also decentralized, immutable, and free of vulnerabilities? I decided to check.

• it is possible to build a simple decentralized app with zero coding skills — it took me 3 days to build my Simple Gambling Machine (it works, it's fully decentralized and immutable, and it's ready to distribute >$500 to gamblers)

• ChatGPT, Gemini, and Cursor/Claude can guide you step by step through the whole process (even if you've never interacted with code before) — from setting up the environment to deploying the website on IPFS

• it really helps if you understand what emergence is, and if you grasp the structure and logic of how different elements come together into a unified whole

• debugging process is painful, and there will likely be some vulnerabilities in your smart contracts — always ask real security auditors to review the code if someone’s money is involved

Starting from basic questions like “Hey GPT, I wanna write and deploy a smart contract — what program do I need to install on my Mac to write code?”, I’m hoping to reach a point where I have a website providing access to my smart contract in a fully decentralized manner. Below you’ll find:

• a story of the whole process

• links to all conversations with various LLMs

• some thoughts on where vibe coding works and where it fails

• some random thoughts about this and that

I do know:

• something about writing contracts (not smart contracts though) since I used to be a lawyer

• something about web3 and smart contracts since I've been a degen since 2020

• something about software development since I'm a business analyst (at least my colleagues say so) in software development company

• a little bit about coding since I made small AI-powered game with friends some time ago (friends did all the coding)

• almost nothing about development environments, programming languages, GitHub repository management, and other important things

Ideally, I’d want to create a loop where I describe functional requirements to an LLM and get back instructions on what to do to implement them — without having to think about code at all.

There are three pillars DeFi (and crypto in general, and TradFi as well) is based on: gaming, greed, and addiction (also known collectively as gambling). Try to decompose almost any DeFi protocol, and you’ll likely find that these three concepts underpin its design. So I was thinking about building something very simple that combines all three.

For example, it could be a simple gambling machine that:

• has some initial ETH balance (say, 0.2 ETH)

• accepts some percentage of current ETH balance (say, 5%) from anyone willing to do it

• automatically transfers its entire ETH balance to the last depositor if no one makes a deposit within a certain period of time (say, 12 hours)

Brief research showed that web3 world has already seen similar projects in the past — FOMO3D and its clones, POwH, King of Ether, and others. Definitely should dive deeper, but will do it a little bit later.

And yes, I want everything to be fully decentralized. Smart contract must be immutable and non-upgradable, but everything else… not sure I fully understand what it means for the backend and frontend to be decentralized (besides the fact that the whole thing should not rely on any centralized intermediaries and must work without any maintenance from my side). By the way, do I need a backend at all?

Intuition tells me that I need a combination of:

• ChatGPT

• Gemini

• DeepSeek

The Lmarena leaderboard resonates with my intuition, so these will be the models I’ll chat with. I’ll share conversations with ChatGPT and Gemini — DeepSeek doesn’t have this feature.

With the help of ChatGPT, Gemini and DeepSeek I understood that I need:

• smart contract (this part is pretty clear)

• frontend (less clear, but understandable)

• backend (likely my contract will act as backend)

The general scheme of how these parts will communicate with each other — who should know what — is more or less clear. The details, however, are quite opaque. There are a lot of things mentioned in ChatGPT's answer, like IPFS, Fleek, Pin CID, ethers.js, web3.js, viem, wagmi, Pinata, Arweave, Hardhat, Foundry, React, Chainlink Keepers, and Truffle. Not sure if I need them… I’ll try to move step-by-step and start with installing Cursor and setting up GitHub.

At this point, it’s important to understand the conceptual design of previous similar projects and their issues. The most notable project is FOMO3D.

In FOMO3D, players bought “keys” to win a prize that would be handed out in 24 hours — as long as nobody else bought a key before the timer ran out. If someone else did, the timer was extended, and the whole process started again with the new buyer in the lead. At its peak, there was $12 million in ETH at stake.

Even though the concept is similar to the game I want to build, the details are quite different:

• there’s a revenue share (revenue from each key purchase is split according to a schedule), which makes FOMO3D a Ponzi-like game

• the winner gets only 48% of the pot (the rest goes to previous key holders, stakers, and the community)

• there’s a pretty complicated price function

• you can find more details here

The end of the game was described as a “block stuffing attack” by Nick Carter. You can find detailed explanation here and in other articles about FOMO3D - one, two, three, four, five, and so on. Other notable projects include Proof of Weak Hands 3D, King of Ether, and numerous FOMO3D clones (most of them were scams). I guess there have been many more attempts to rebuild FOMO3D.

I personally don’t like the Ponzi mechanics embedded in the game — first of all, Ponzi mechanics suck. Also, they add complexity to both the game and the codebase.

I want my game to be very straightforward and simple — no tokens, no revenue share, no other complex things. The last depositor gains (almost) everything. That’s it.

At the same time, some (just a little bit of) complexity is needed. Namely:

• deposit size (the percentage of ETH a player must pay) should not be a fixed number — a tiered approach with a gradual reduction in the required percentage is a much better option

• time period until the game ends should not be fixed as well — it could gradually decline from 24 hours to 1 hour

• game should automatically restart — e.g., 10% of the total pot could be kept for the next game

I asked ChatGPT and Gemini to help me with visualization of possible deposit structure and TVL growth scenarios, and after a number of iterations, I found parameters that look fine to me:

• initial ETH balance: 0.2 ETH (around $500)

• deposit size: 2% of the current ETH balance for the first 50 deposits, 1.5% for the next 75 deposits, 1.2% for the next 100 deposits, 1% for the next 200 deposits, 0.5% for the next 500 deposits, 0.2% for the next 1000 deposits, then 0.05%

• period of time: 24 hours for the first 50 deposits, 16 hours for the next 75 deposits, 12 hours for the next 100 deposits, 6 hours for the next 200 deposits, 3 hours for the next 500 deposits, 2 hours for the next 1000 deposits, then 1 hour

There's an inevitable internal contradiction here — the depositor wants no one to know about the game so they can easily win the pot. But for the game to truly flourish, I need as more gamblers as possible. Ponzi mechanics and referral schemes could help with that... but no — fuck Ponzi and fuck referral schemes.

That said, I will add a small lottery element to incentivize early deposits — say, 10% of the pot will be distributed among 5 random depositors.

Time to do some vibe coding. I will start with the very basics.

I’m writing a smart contract that:

• have some initial ETH balance...

• ... if no one deposits for some period (say, 12 hours)

Also, I need a website so that people can access this contract. Everything (including frontend, backend, etc.) must be decentralized.

Please describe the architecture/design of the project - what will be the major elements, how will they interact with each other, etc.

There’s something you need to know - I’m not a developer. I have Mac, so I can write code, but I don’t know anything about developer environments, standard frameworks and workflows.

Now I want you to provide me with a step-by-step high-level instruction on how to build the project described above. Please start with the basic info on where to start (eg, I heard from my friends that I need Github page and Cursor to build something).

Both ChatGPT and Gemini provided me with detailed and understandable (and in many ways similar) step-by-step guides, so the coding has started!

It was pretty easy. ChatGPT helped me with:

• setting up the environment (installing dependencies, getting started with Cursor, etc.)

• writing and running tests

• deploying the smart contract on the Sepolia testnet

• figuring out how to interact with the smart contract through Etherscan

It wasn’t ideal, though — for some reason, I couldn’t run my tests (Claude in Cursor helped me with that). There were also a few critical vulnerabilities, which my friends helped me detect and fix.

What I used: Cursor for code editing, Solidity for the smart contract, Foundry for building and deploying my dApp, and Alchemy as a node provider.

This was the tough part. Eventually Gemini made everything I needed, but explaining the desired frontend (especially UX/UI part) in words is such a painful experience. It helped with:

• choosing the framework: I chose next.js (Gemini said "if React is the engine, Next.js is like a well-designed car built around that engine" - obviously I chose the car)

• understanding the basics - creating next.js application, running the development server, explaining pretty much everything about core structure, basic layout and pages, components, etc.

• coding everything that need to be coded (from explanation of high-level logic of files and components to down to the lowest level of fixing minor bugs in specific files) and debugging

Currently, Gemini can't understand pictures so I had to explain the design I wanna use on my website. So I drafted it in Miro and asked ChatGPT to describe my future design in words. Flux.1 (accessible through Hyperbolic) helped with the images.

What I used: Cursor for code editing, next.js as a frontend framework.

I wanted my app to be fully decentralized, including hosting. I don't think any single entity would want to take down my site, or that a centralized server I choose would go down due to hardware failure — but why not do everything properly if I can? Both Gemini and ChatGPT said I need a combination of IPFS (as a decentralized storage network) and ENS (for a decentralized domain name) for this purpose. I also found out that I need an IPFS pinning service for everything to work reliably.

Since my website is built on next.js, I started with Vercel, but I couldn't register on their website. While trying to sign up, I was prompted to contact the Vercel team via email and wait up to 48 hours to complete registration. By the way, after 5 days, I still haven’t received a response.

Then I tried Fleek, but for some reason, it didn’t work for me — numerous deployment attempts failed for reasons that neither I nor my LLMs could understand.

Finally, I deployed my website with Pinata. It took some time due to numerous bugs and errors, but eventually Gemini worked everything out without me having to dig into the code.

I have access to about two-thirds of my conversation with Gemini. At some point, I stopped the generation of Gemini's response, and for some reason, Google doesn't allow you to share conversations with skipped responses ("Can’t share chats with skipped responses, try reloading the chat"). There's no way to share it in any other form.

What I used: IPFS as a decentralized storage network, Pinata as a pinning service, and ENS for a decentralized domain name.

Then I spent a few hours fixing a bunch of things:

• refined the deposit structure and pot distribution logic to make deposits more attractive for the first 5–10 depositors

• created a FAQ for my website with ChatGPT

• created a deposit structure table, again with ChatGPT

• also forgot how to interact with GitHub properly and asked Gemini to remind me about best practices (no conversation available, but it was definitely one of the toughest parts)

And then my friends — security auditors — checked the code...

Sure, there were some vulnerabilities.

1. Random numbers

There's no native VRF in Ethereum, so in the current implementation it's possible for the winner to manipulate the claim transaction — and potentially know the "random" 5 winners in advance — by reverting the claim until favorable randoms are selected. Proper randomness requires oracles. Obv I don’t want to pay for oracles, and I’d likely introduce even more vulnerabilities trying to implement them. So this vulnerability is now a feature — kinda extra bounty for smart depositors. You can find its description in FAQ section.

1. Donation address

My initial idea was to send 1% from every deposit to the public EVM donation address of some international organization helping with gambling addiction. But:

• I couldn’t find any such organizations with public EVM addresses

• this logic introduced a vulnerability — anyone could deploy a contract to that EVM address which reverts all incoming deposits. That would make new deposits impossible, meaning the last depositor would win by default.

So I decided to remove this logic.

1. Reentrancy

If the lastDepositor is a contract, it could withhold the 10% reserved for random winners by calling claimTimeout() multiple times during the transfer callback — each time draining 80% of the remaining balance. This was fixed using a reentrancy guard from OpenZeppelin.

1. No Guard Against “Dust” Rounding Errors in deposit()

There was a potential issue where a tiny fraction of wei was “lost” due to a rounding error.

1. Unbounded Growth of depositors[] Leading to Potential Gas/Storage DoS

In a busy game, the length of the depositors array can grow arbitrarily large (thousands or more). Storing — and eventually deleting — such a huge array costs a lot of gas, and on networks with high storage costs, this can become untenable. A circular buffer (fixed-size array) approach was used to fix this.

1. Malicious random winner reverting claim function

A malicious random winner could cause the entire claimTimeout function to revert, preventing the winner and all other random recipients from ever getting paid — effectively freezing the contract's main functionality. This was fixed by explicitly limiting the gas forwarded with the call.

1. Claim with zero depositors

Hypothetically, the pot could hold some ETH while having zero depositors. In this scenario, using claimTimeout would cause 80% of the contract’s balance to be sent to the zero address, where it would be permanently and irrecoverably lost.

ChatGPT explained these vulnerabilities to me and helped me fix them. Other related conversations - ChatGPT, Gemini.

First of all, it was fast. I didn't expect the whole process from the very beginning to take only 3 days (not 8-hour full-time corporate days, but more like lazy, chill freelancer days). Yeah, we're talking about a simple smart contract on a one-page website with primitive UX — but achieving a similar result in 2019, for someone with zero coding skills, would’ve taken... I don't know, maybe a month?

Cool things about vibe-coding with LLMs:

• I had almost zero interaction with the codebase (besides copy-pasting it). Every LLM I used (mostly ChatGPT and Gemini) was really great at pretty much everything related to coding — from transforming my plain English into code and back, to guiding me through all the processes, whether on Terminal, Cursor, or GitHub

• Gemini not only guided me through the whole process of frontend development, but it also felt like it was trying to teach me some basics through simple examples — like “let’s change layout.js a little bit so you’ll see the changes on your local server and get an intuition of how it works” (I didn’t ask for this in my prompt, at least not explicitly)

• in the middle of a frontend-development conversation (100+ messages) with Gemini, I switched from frontend topics to something related to my smart contract. I sent the code of my contract and asked a few questions, then switched back — Gemini was right on track, still keeping the whole development plan in mind

The funny thing is that most of the "job" I was doing wasn’t intellectual at all — mostly copy-pasting from Gemini to Cursor/Terminal/ChatGPT and back. I believe this kind of routine will be pushed to the background by working LLM swarms in a few years (or rather, months). The only tasks left for humans will be properly articulating ideas (describing the desired outputs), managing the process (“here’s a misunderstanding, let’s fix it,” “the plan is okay, but let’s add some extra steps,” “don’t use Fleek, use Pinata”), and occasional debugging.

Speaking of the human's role, here are some tips that were useful for me (though this list may be outdated in just a few months):

• ask for a detailed plan — it’s a must, even more so for the LLM than for you

• don’t automatically accept everything — sometimes Gemini was too proactive (e.g., at the start of frontend development, it came up with components that didn’t match my UI/UX vision), so it’s worth taking the time to really dig into what the LLM is suggesting

• ask questions — if you don’t understand something, don’t hesitate to ask for details. For example, if you feel like things are drifting off track, it always helps to write something like: “Wait, I want to achieve X. Our current status is Y. What’s our plan to get to X?”

• debugging - if you feel like LLM is heading in the wrong direction during debugging, use your brain to give it hints and clues (e.g., “Did you notice that component B also stopped working? Could that be important for the bug in component A we’re discussing?”)

• return to the starting point if needed — sometimes (especially while debugging), you may go too far from the main issue. Saying something like “Wait, let’s think about the problem again from the beginning” can really help

• use Cursor's AI — sometimes (e.g., when trying to find a string to change the element's size), the easiest option is just to ask Cursor. It’s great at navigating your codebase

Obviously, I still don’t understand programming languages, development environments, or, in general, more than 90% of what programmers know. But the point is that with the help of LLMs I can create working things without knowing all of that — simple things for now, more complicated stuff soon.

Today, the tough part of development is assembling a (pretty big) group of people with different skills — backend and frontend engineers, devops, various managers and analysts, and so on. Pretty soon, the tough part will be truly understanding what you're building and articulating it properly.

And no doubt — this future will be fun!

ChatGPT said it is — but only if you're early.

Gemini and DeepSeek (after 420 seconds of thinking) — yes, but only if you're late (after the 500th deposit).

But it's always better to do you own research!

Vibe coding is hyping right now. No doubt LLMs can help programmers with programming, but can they help humanitarians create something that works — and that is also decentralized, immutable, and free of vulnerabilities? I decided to check.

• it is possible to build a simple decentralized app with zero coding skills — it took me 3 days to build my Simple Gambling Machine (it works, it's fully decentralized and immutable, and it's ready to distribute >$500 to gamblers)

• ChatGPT, Gemini, and Cursor/Claude can guide you step by step through the whole process (even if you've never interacted with code before) — from setting up the environment to deploying the website on IPFS

• it really helps if you understand what emergence is, and if you grasp the structure and logic of how different elements come together into a unified whole

• debugging process is painful, and there will likely be some vulnerabilities in your smart contracts — always ask real security auditors to review the code if someone’s money is involved

Starting from basic questions like “Hey GPT, I wanna write and deploy a smart contract — what program do I need to install on my Mac to write code?”, I’m hoping to reach a point where I have a website providing access to my smart contract in a fully decentralized manner. Below you’ll find:

• a story of the whole process

• links to all conversations with various LLMs

• some thoughts on where vibe coding works and where it fails

• some random thoughts about this and that

I do know:

• something about writing contracts (not smart contracts though) since I used to be a lawyer

• something about web3 and smart contracts since I've been a degen since 2020

• something about software development since I'm a business analyst (at least my colleagues say so) in software development company

• a little bit about coding since I made small AI-powered game with friends some time ago (friends did all the coding)

• almost nothing about development environments, programming languages, GitHub repository management, and other important things

Ideally, I’d want to create a loop where I describe functional requirements to an LLM and get back instructions on what to do to implement them — without having to think about code at all.

There are three pillars DeFi (and crypto in general, and TradFi as well) is based on: gaming, greed, and addiction (also known collectively as gambling). Try to decompose almost any DeFi protocol, and you’ll likely find that these three concepts underpin its design. So I was thinking about building something very simple that combines all three.

For example, it could be a simple gambling machine that:

• has some initial ETH balance (say, 0.2 ETH)

• accepts some percentage of current ETH balance (say, 5%) from anyone willing to do it

• automatically transfers its entire ETH balance to the last depositor if no one makes a deposit within a certain period of time (say, 12 hours)

Brief research showed that web3 world has already seen similar projects in the past — FOMO3D and its clones, POwH, King of Ether, and others. Definitely should dive deeper, but will do it a little bit later.

And yes, I want everything to be fully decentralized. Smart contract must be immutable and non-upgradable, but everything else… not sure I fully understand what it means for the backend and frontend to be decentralized (besides the fact that the whole thing should not rely on any centralized intermediaries and must work without any maintenance from my side). By the way, do I need a backend at all?

Intuition tells me that I need a combination of:

• ChatGPT

• Gemini

• DeepSeek

The Lmarena leaderboard resonates with my intuition, so these will be the models I’ll chat with. I’ll share conversations with ChatGPT and Gemini — DeepSeek doesn’t have this feature.

With the help of ChatGPT, Gemini and DeepSeek I understood that I need:

• smart contract (this part is pretty clear)

• frontend (less clear, but understandable)

• backend (likely my contract will act as backend)

The general scheme of how these parts will communicate with each other — who should know what — is more or less clear. The details, however, are quite opaque. There are a lot of things mentioned in ChatGPT's answer, like IPFS, Fleek, Pin CID, ethers.js, web3.js, viem, wagmi, Pinata, Arweave, Hardhat, Foundry, React, Chainlink Keepers, and Truffle. Not sure if I need them… I’ll try to move step-by-step and start with installing Cursor and setting up GitHub.

At this point, it’s important to understand the conceptual design of previous similar projects and their issues. The most notable project is FOMO3D.

In FOMO3D, players bought “keys” to win a prize that would be handed out in 24 hours — as long as nobody else bought a key before the timer ran out. If someone else did, the timer was extended, and the whole process started again with the new buyer in the lead. At its peak, there was $12 million in ETH at stake.

Even though the concept is similar to the game I want to build, the details are quite different:

• there’s a revenue share (revenue from each key purchase is split according to a schedule), which makes FOMO3D a Ponzi-like game

• the winner gets only 48% of the pot (the rest goes to previous key holders, stakers, and the community)

• there’s a pretty complicated price function

• you can find more details here

The end of the game was described as a “block stuffing attack” by Nick Carter. You can find detailed explanation here and in other articles about FOMO3D - one, two, three, four, five, and so on. Other notable projects include Proof of Weak Hands 3D, King of Ether, and numerous FOMO3D clones (most of them were scams). I guess there have been many more attempts to rebuild FOMO3D.

I personally don’t like the Ponzi mechanics embedded in the game — first of all, Ponzi mechanics suck. Also, they add complexity to both the game and the codebase.

I want my game to be very straightforward and simple — no tokens, no revenue share, no other complex things. The last depositor gains (almost) everything. That’s it.

At the same time, some (just a little bit of) complexity is needed. Namely:

• deposit size (the percentage of ETH a player must pay) should not be a fixed number — a tiered approach with a gradual reduction in the required percentage is a much better option

• time period until the game ends should not be fixed as well — it could gradually decline from 24 hours to 1 hour

• game should automatically restart — e.g., 10% of the total pot could be kept for the next game

I asked ChatGPT and Gemini to help me with visualization of possible deposit structure and TVL growth scenarios, and after a number of iterations, I found parameters that look fine to me:

• initial ETH balance: 0.2 ETH (around $500)

• deposit size: 2% of the current ETH balance for the first 50 deposits, 1.5% for the next 75 deposits, 1.2% for the next 100 deposits, 1% for the next 200 deposits, 0.5% for the next 500 deposits, 0.2% for the next 1000 deposits, then 0.05%

• period of time: 24 hours for the first 50 deposits, 16 hours for the next 75 deposits, 12 hours for the next 100 deposits, 6 hours for the next 200 deposits, 3 hours for the next 500 deposits, 2 hours for the next 1000 deposits, then 1 hour

There's an inevitable internal contradiction here — the depositor wants no one to know about the game so they can easily win the pot. But for the game to truly flourish, I need as more gamblers as possible. Ponzi mechanics and referral schemes could help with that... but no — fuck Ponzi and fuck referral schemes.

That said, I will add a small lottery element to incentivize early deposits — say, 10% of the pot will be distributed among 5 random depositors.

Time to do some vibe coding. I will start with the very basics.

I’m writing a smart contract that:

• have some initial ETH balance...

• ... if no one deposits for some period (say, 12 hours)

Also, I need a website so that people can access this contract. Everything (including frontend, backend, etc.) must be decentralized.

Please describe the architecture/design of the project - what will be the major elements, how will they interact with each other, etc.

There’s something you need to know - I’m not a developer. I have Mac, so I can write code, but I don’t know anything about developer environments, standard frameworks and workflows.

Now I want you to provide me with a step-by-step high-level instruction on how to build the project described above. Please start with the basic info on where to start (eg, I heard from my friends that I need Github page and Cursor to build something).

Both ChatGPT and Gemini provided me with detailed and understandable (and in many ways similar) step-by-step guides, so the coding has started!

It was pretty easy. ChatGPT helped me with:

• setting up the environment (installing dependencies, getting started with Cursor, etc.)

• writing and running tests

• deploying the smart contract on the Sepolia testnet

• figuring out how to interact with the smart contract through Etherscan

It wasn’t ideal, though — for some reason, I couldn’t run my tests (Claude in Cursor helped me with that). There were also a few critical vulnerabilities, which my friends helped me detect and fix.

What I used: Cursor for code editing, Solidity for the smart contract, Foundry for building and deploying my dApp, and Alchemy as a node provider.

This was the tough part. Eventually Gemini made everything I needed, but explaining the desired frontend (especially UX/UI part) in words is such a painful experience. It helped with:

• choosing the framework: I chose next.js (Gemini said "if React is the engine, Next.js is like a well-designed car built around that engine" - obviously I chose the car)

• understanding the basics - creating next.js application, running the development server, explaining pretty much everything about core structure, basic layout and pages, components, etc.

• coding everything that need to be coded (from explanation of high-level logic of files and components to down to the lowest level of fixing minor bugs in specific files) and debugging

Currently, Gemini can't understand pictures so I had to explain the design I wanna use on my website. So I drafted it in Miro and asked ChatGPT to describe my future design in words. Flux.1 (accessible through Hyperbolic) helped with the images.

What I used: Cursor for code editing, next.js as a frontend framework.

I wanted my app to be fully decentralized, including hosting. I don't think any single entity would want to take down my site, or that a centralized server I choose would go down due to hardware failure — but why not do everything properly if I can? Both Gemini and ChatGPT said I need a combination of IPFS (as a decentralized storage network) and ENS (for a decentralized domain name) for this purpose. I also found out that I need an IPFS pinning service for everything to work reliably.

Since my website is built on next.js, I started with Vercel, but I couldn't register on their website. While trying to sign up, I was prompted to contact the Vercel team via email and wait up to 48 hours to complete registration. By the way, after 5 days, I still haven’t received a response.

Then I tried Fleek, but for some reason, it didn’t work for me — numerous deployment attempts failed for reasons that neither I nor my LLMs could understand.

Finally, I deployed my website with Pinata. It took some time due to numerous bugs and errors, but eventually Gemini worked everything out without me having to dig into the code.

I have access to about two-thirds of my conversation with Gemini. At some point, I stopped the generation of Gemini's response, and for some reason, Google doesn't allow you to share conversations with skipped responses ("Can’t share chats with skipped responses, try reloading the chat"). There's no way to share it in any other form.

What I used: IPFS as a decentralized storage network, Pinata as a pinning service, and ENS for a decentralized domain name.

Then I spent a few hours fixing a bunch of things:

• refined the deposit structure and pot distribution logic to make deposits more attractive for the first 5–10 depositors

• created a FAQ for my website with ChatGPT

• created a deposit structure table, again with ChatGPT

• also forgot how to interact with GitHub properly and asked Gemini to remind me about best practices (no conversation available, but it was definitely one of the toughest parts)

And then my friends — security auditors — checked the code...

Sure, there were some vulnerabilities.

1. Random numbers

There's no native VRF in Ethereum, so in the current implementation it's possible for the winner to manipulate the claim transaction — and potentially know the "random" 5 winners in advance — by reverting the claim until favorable randoms are selected. Proper randomness requires oracles. Obv I don’t want to pay for oracles, and I’d likely introduce even more vulnerabilities trying to implement them. So this vulnerability is now a feature — kinda extra bounty for smart depositors. You can find its description in FAQ section.

1. Donation address

My initial idea was to send 1% from every deposit to the public EVM donation address of some international organization helping with gambling addiction. But:

• I couldn’t find any such organizations with public EVM addresses

• this logic introduced a vulnerability — anyone could deploy a contract to that EVM address which reverts all incoming deposits. That would make new deposits impossible, meaning the last depositor would win by default.

So I decided to remove this logic.

1. Reentrancy

If the lastDepositor is a contract, it could withhold the 10% reserved for random winners by calling claimTimeout() multiple times during the transfer callback — each time draining 80% of the remaining balance. This was fixed using a reentrancy guard from OpenZeppelin.

1. No Guard Against “Dust” Rounding Errors in deposit()

There was a potential issue where a tiny fraction of wei was “lost” due to a rounding error.

1. Unbounded Growth of depositors[] Leading to Potential Gas/Storage DoS

In a busy game, the length of the depositors array can grow arbitrarily large (thousands or more). Storing — and eventually deleting — such a huge array costs a lot of gas, and on networks with high storage costs, this can become untenable. A circular buffer (fixed-size array) approach was used to fix this.

1. Malicious random winner reverting claim function

A malicious random winner could cause the entire claimTimeout function to revert, preventing the winner and all other random recipients from ever getting paid — effectively freezing the contract's main functionality. This was fixed by explicitly limiting the gas forwarded with the call.

1. Claim with zero depositors

Hypothetically, the pot could hold some ETH while having zero depositors. In this scenario, using claimTimeout would cause 80% of the contract’s balance to be sent to the zero address, where it would be permanently and irrecoverably lost.

ChatGPT explained these vulnerabilities to me and helped me fix them. Other related conversations - ChatGPT, Gemini.

First of all, it was fast. I didn't expect the whole process from the very beginning to take only 3 days (not 8-hour full-time corporate days, but more like lazy, chill freelancer days). Yeah, we're talking about a simple smart contract on a one-page website with primitive UX — but achieving a similar result in 2019, for someone with zero coding skills, would’ve taken... I don't know, maybe a month?

Cool things about vibe-coding with LLMs:

• I had almost zero interaction with the codebase (besides copy-pasting it). Every LLM I used (mostly ChatGPT and Gemini) was really great at pretty much everything related to coding — from transforming my plain English into code and back, to guiding me through all the processes, whether on Terminal, Cursor, or GitHub

• Gemini not only guided me through the whole process of frontend development, but it also felt like it was trying to teach me some basics through simple examples — like “let’s change layout.js a little bit so you’ll see the changes on your local server and get an intuition of how it works” (I didn’t ask for this in my prompt, at least not explicitly)

• in the middle of a frontend-development conversation (100+ messages) with Gemini, I switched from frontend topics to something related to my smart contract. I sent the code of my contract and asked a few questions, then switched back — Gemini was right on track, still keeping the whole development plan in mind

The funny thing is that most of the "job" I was doing wasn’t intellectual at all — mostly copy-pasting from Gemini to Cursor/Terminal/ChatGPT and back. I believe this kind of routine will be pushed to the background by working LLM swarms in a few years (or rather, months). The only tasks left for humans will be properly articulating ideas (describing the desired outputs), managing the process (“here’s a misunderstanding, let’s fix it,” “the plan is okay, but let’s add some extra steps,” “don’t use Fleek, use Pinata”), and occasional debugging.

Speaking of the human's role, here are some tips that were useful for me (though this list may be outdated in just a few months):

• ask for a detailed plan — it’s a must, even more so for the LLM than for you

• don’t automatically accept everything — sometimes Gemini was too proactive (e.g., at the start of frontend development, it came up with components that didn’t match my UI/UX vision), so it’s worth taking the time to really dig into what the LLM is suggesting

• ask questions — if you don’t understand something, don’t hesitate to ask for details. For example, if you feel like things are drifting off track, it always helps to write something like: “Wait, I want to achieve X. Our current status is Y. What’s our plan to get to X?”

• debugging - if you feel like LLM is heading in the wrong direction during debugging, use your brain to give it hints and clues (e.g., “Did you notice that component B also stopped working? Could that be important for the bug in component A we’re discussing?”)

• return to the starting point if needed — sometimes (especially while debugging), you may go too far from the main issue. Saying something like “Wait, let’s think about the problem again from the beginning” can really help

• use Cursor's AI — sometimes (e.g., when trying to find a string to change the element's size), the easiest option is just to ask Cursor. It’s great at navigating your codebase

Obviously, I still don’t understand programming languages, development environments, or, in general, more than 90% of what programmers know. But the point is that with the help of LLMs I can create working things without knowing all of that — simple things for now, more complicated stuff soon.

Today, the tough part of development is assembling a (pretty big) group of people with different skills — backend and frontend engineers, devops, various managers and analysts, and so on. Pretty soon, the tough part will be truly understanding what you're building and articulating it properly.

And no doubt — this future will be fun!

ChatGPT said it is — but only if you're early.

Gemini and DeepSeek (after 420 seconds of thinking) — yes, but only if you're late (after the 500th deposit).

But it's always better to do you own research!