DEV Community: Rafael Abuawad

The House Always Wins: How pump.fun Turned Crypto Into a Fee Machine

Rafael Abuawad — Mon, 26 Oct 2026 01:53:11 +0000

Between January 2024 and June 2026, pump.fun produced more than 18.6 million tokens that traded at least once. Nearly seven in ten of them made their last trade on the same day they were born. Eight in ten were gone within 48 hours. Fewer than one in twenty were still trading three months later (CoinGecko, via CryptoPotato).

The odds of "making it" are worse. A study of 832,941 launches between May and June 2026 found a graduation rate of 0.198%: about two tokens in every thousand reached the point where they leave Pump.fun's bonding curve for an open market (Kamat, arXiv 2607.02823).

Over the same period, the platform collected more than $1.2 billion in revenue (DefiLlama).

Those three facts are the whole story. Almost every token dies. Most traders lose. The house gets paid either way. I build smart contracts for a living, and I've come to believe pump.fun is the single most damaging product this industry has shipped. And if things don't change, it's time to walk away from it.

How the machine works

On pump.fun, anyone can create a token in seconds by filling in a short form. There is no team to vet, no code to audit, and no liquidity to provide. Each new token starts on a bonding curve: an automated price formula where every buy pushes the price up, and every sell pushes it down.

If enough money flows in, the token "graduates" at roughly $80,000 to $100,000 in market cap and moves to a regular trading pool. Almost none get there. The rest simply stop trading, usually within hours.

The key detail is where the money goes. pump.fun charges fees on trades along the curve and on its own exchange, PumpSwap. It does not need any token to succeed. It needs tokens to be launched and traded, as many as possible, as fast as possible. As one analysis of CoinGecko's data put it, the platform is paid whether a token lasts six minutes or six months (Crypto Briefing).

That is not a flaw in the design. It is the design.

Who wins

The platform does, spectacularly. pump.fun has generated about $1.9 billion in fees and $1.2 billion in revenue since launch (DefiLlama). Its best month, January 2025, brought in $137 million (Unchained). In a 2026 job listing for a Chief Legal Officer, offering up to $5 million a year, the company itself said it made over $500 million in profit the previous year with fewer than 100 people (Mitrade).

Much of that money has left the chain. Onchain trackers estimate the platform has sold about 4.47 million SOL, roughly $780 million, mostly through Kraken (Pluang). In late 2025, wallets linked to pump.fun also moved 436.5 million USDC to Kraken; co-founder Noah Tweedale called reports of a cash-out misinformation and said it was treasury management (ForkLog).

Then there was the token. In February 2025, co-founder Alon Cohen dismissed reports of a pump.fun token as wrong (The Defiant). Five months later, the PUMP sale raised hundreds of millions of dollars and sold out in 12 minutes (Cointelegraph). Half of the platform's net revenue now goes to buying back and burning PUMP (DefiLlama). Put plainly: trader losses are recycled into support for the platform's own token.

The three founders, Noah Tweedale, Alon Cohen and Dylan Kerler, say they built pump.fun out of frustration with rug pulls (Wikipedia). That origin story sits awkwardly next to a 2025 WIRED investigation. It linked a developer using Kerler's name to eight tokens launched in 2017, two of which collapsed amid rug-pull accusations, earning that developer up to an estimated $75,000. Neither pump.fun nor Kerler responded to WIRED's requests for comment (Bitcoinist, summarizing WIRED).

Who loses

Everyone else, mostly. In the first half of 2024, Dune data showed 62.5% of pump.fun traders had lost money, while just 311 wallets, under 0.01% of the total, had made more than $1 million (crypto.news). By June 2025, only 30.1% of active wallets finished the month in profit (CoinGecko).

The pattern held into 2026. In March, about half of the roughly 1.4 million wallets trading pump.fun tokens lost money, and around 96% either lost or made less than $500 (crypto.news, via MEXC). Over the six months before that, the top 250 token deployers pulled an estimated $79 million out of traders while launching 194,000 tokens between them (Protos, via MEXC).

Those are wallet counts, and one person can run many wallets. But the shape is unmistakable: a thin layer of insiders and "professionals" at the top, and a large base of ordinary people paying for the game.

An earlier study by Solidus Labs found that of more than 7 million pump.fun tokens with at least five trades, 98.6% had collapsed below $1,000 in liquidity (The Defiant). Not every one of those was a deliberate scam. But a market where 98.6% of products collapse is not a market. It's a lottery with a fee on every ticket.

The first block

If the odds were merely bad, you could call it gambling and move on. The deeper problem is that the game is often decided before a normal person can even click "buy."

On Solana, a token's creator, or a bot watching for new launches, can buy in the very same block the token is created. Pine Analytics found that this kind of same-block sniping is no longer an edge case but the dominant launch pattern on pump.fun. Looking only at the most obvious form of collusion, snipers funded directly by the token's own deployer, it accounted for about 1.75% of all launches. That is a floor: insiders who route funds through a few extra wallets slip past the method (Pine Analytics).

An entire industry has grown up to serve this. "Bundler" tools, advertised openly, let a launcher buy from up to 20 wallets in the creation block, and many launches use between 20 and 50 (The Coin Republic). The supply is spread across fresh wallets so that it looks organic. Then it is sold to whoever arrives next.

By the time a token appears in your feed, the cheapest supply has usually been claimed by software. The retail buyer is not a participant. The retail buyer is the exit.

What it did to crypto

The damage doesn't stay on pump.fun. For two years, it set the tone for what a "crypto app" is. Attention, liquidity, and talent flowed toward launching and flipping tokens rather than building things people use. New users arrived through a casino, lost money, and left believing that this is what crypto is.

The platform's culture made it worse. In late 2024, pump.fun had to shut down livestreaming after creators broadcast animal cruelty, threats of violence, and self-harm to pump their tokens (Decrypt). It was also reportedly geo-blocked in the UK after action by the Financial Conduct Authority (Mitrade).

And the activity it generated proved hollow. When the memecoin tide went out in 2026, daily Solana network fees fell about 84% between January and June, and pump.fun's own graduation rate dropped 80% in three months (DEXTools). Growth built on extraction doesn't compound. It just ends.

The lawsuit

Pump.fun's operator, Baton Corporation, and its three founders are defendants in a federal class action in New York. The plaintiffs estimate retail losses at $4 billion to $5.5 billion, a figure that has not been tested in court (Decrypt).

On August 31, 2026, Judge Colleen McMahon split her ruling. She dismissed the claims that pump.fun tokens were unregistered securities, rejected the theory that trading memecoins counts as illegal gambling under New York law, and cleared Solana Labs, the Solana Foundation and their executives (SolanaFloor). But she let the racketeering (RICO) claims proceed against Baton and its founders personally (Burwick Law).

Nothing has been proven yet. But a federal judge has found the racketeering allegations against the people running pump.fun detailed enough to go forward.

Their defense, answered

Pump.fun's defenders make four arguments. Each deserves a straight answer.

"It's permissionless. Adults choose to play." Choice requires information. A buyer who doesn't know that about 2 in 1,000 tokens graduate, that most die on day one, and that the cheapest supply was often taken by software in the first block is not making an informed choice. Permissionless shouldn't mean rigged.

"They're reforming." To their credit pump.fun has shipped changes, including cashback for traders and BOOST, a launch mechanism that briefly lifted the daily graduation rate to 6.7% in July 2026 (The Block). Better odds are welcome.

"It brought millions of users to Solana." It did. Most of them left with losses, and the activity evaporated once the hype did. Onboarding people into a machine that takes their money isn't adoption. It's burning the users the industry will need later.

"PUMP holders benefit from buybacks." They do, but it's not sustainable. The token's support comes from fees paid by traders who mostly lose. The platform itself states that PUMP carries no right to its revenue (DefiLlama).

What you can do

To be honest, I've barely used pump.fun. This isn't the story of a burned trader. I'm joining the boycott because a company earning hundreds of millions of dollars responds to one kind of pressure above all: people choosing not to use it.

I also want to give credit where it's due. The bonding curve is genuinely a good idea. It gives every token open price discovery from the first trade, with no insider-arranged liquidity. With real protections, such as limits on first-block buys, vesting for creators, and a visible history for every deployer, it could be a strong tool for ICOs and community funding.

That isn't how it's used. People come to pump.fun to find the next WIF, or to ride the pump and get out before the dump. The platform is built around that behavior. It takes a fee on all of it, and gives remarkably little back to the communities that generate it.

Competition won't fix this on its own, because pump.fun is the template. It showed every launchpad that came after it how to make hundreds of millions while not caring what happens to users. It has given a home to serial deployers who pulled tens of millions of dollars out of traders. That lesson is spreading, and it has tainted the whole industry.

I believe enough pressure can change the product. I'm far less convinced it can change the people running it, and that matters most. Products follow incentives, and a boycott changes incentives. But culture comes from leadership, which is why accountability for the people in charge, including in court, matters as much as any new feature.

Crypto's promise was a fairer financial system. Pump.fun took a good mechanism and built a casino on top of it. I'd like to see the bonding curve outlive the casino, and the only way that happens is if we stop feeding it.

Ministable: a CDP engine and a stablecoin in one contract

Rafael Abuawad — Fri, 23 Oct 2026 15:16:21 +0000

"We believe that stable digital assets [...] are essential to realizing the full potential of blockchain technology." (The Maker Protocol whitepaper)

For the last few days, I've been working on a new project called ministable. It started with a simple question: can you fit an entire CDP engine and the stablecoin it issues into a single smart contract? That was the whole premise. It turns out you can.

I'd been reading a lot about stablecoins: how they're designed and what each design trades away. One thing kept bothering me. Years after the Terra/LUNA collapse, no decentralized stablecoin has come close to the scale of USDT or USDC. So I started digging into the designs.

What is a CDP?

A CDP (collateralized debt position) is a loan you take out against your own crypto. You lock collateral in a contract, for example, ETH, and mint stablecoins against it. You always have to lock more value than you borrow. To get your collateral back, you repay the stablecoins you minted plus interest.

If the price of your collateral drops and your position falls below the required ratio, anyone can liquidate it. They repay part of your debt and receive some of your collateral at a discount. That's what keeps every stablecoin in circulation backed by more than a dollar of collateral.

Inspiration: DAI and Microstable

Ministable is inspired by two projects: DAI from MakerDAO and Microstable.

DAI is the original decentralized, crypto-backed stablecoin. It's widely accepted, widely used, and has a lot of unique properties. The first version, Single-Collateral DAI, was backed only by ETH, and that's the version ministable is closest to. Reading the DAI whitepaper, I was struck by how simple and useful the core idea is.

Building a stablecoin isn't easy, though. You can build something that technically holds its peg. The hard part is building something that scales.

DAI is the king of decentralized stablecoins (I'm counting DAI and USDS as one). Plenty of protocols have tried to take its place, and so far they've all failed. But even DAI has a scaling problem. It's huge compared to any other decentralized stablecoin, yet I don't see it overtaking USDC or USDT. Overcollateralization is part of the reason: every dollar of DAI needs more than a dollar of crypto locked behind it, so supply is limited by how much collateral people are willing to lock up.

Still, the design is solid and worth exploring onchain. So I set out to build a stablecoin engine and its token in a single contract, and thanks to Vyper's module system, I could.

Ministable: mUSD

The first ministable deployment is mUSD, a stablecoin pegged to the US dollar and backed by ETH. Like everything else in this project, the design is minimal, and it works like any other CDP-backed stablecoin:

Minting. You deposit ETH and mint mUSD against it, as long as your position stays at a 150% minimum collateral ratio. That means at least $150 of ETH for every $100 of mUSD.
Liquidations. If your position falls below 150%, anyone can liquidate it. The liquidator repays part of your debt and gets 110% of what they repaid in ETH, which is a 10% bonus. They only repay enough to bring you back to 150%, and you keep the rest of your collateral.
Redemptions. Anyone can swap mUSD for $1 of ETH from any healthy position, minus a 0.5% fee that goes to that position's owner. If mUSD trades below $1, buying it and redeeming it is profitable, so redemptions put a floor under the peg.
Stability fee. Debt grows over time at a fixed per-second rate, set at deployment and capped at 10% a year. The interest is charged in mUSD and minted into the protocol's surplus.
Surplus and bad debt. If a liquidated position's collateral can't cover its debt, the shortfall becomes bad debt, and the surplus is burned to cancel it. Anyone can also buy surplus mUSD with ETH at the oracle price. That ETH goes into a reserve, which can cover any bad debt the surplus can't.

Building this taught me how hard stablecoin design really is. Every mechanism exists to close a gap left by another one.

Minimal code

The engine and the token live in a single contract. The goal from the start was something tiny: simple to audit and simple to reason about. Without comments, the whole system (token, CDP engine, and native-ETH wrapper) is under 300 lines of Vyper, without counting the ERC-20 functions.

Security

The code has not been audited yet, and although I'm looking for money to do an audit, I think that is somewhat far away. It has undergone a few code reviews by other developers, but nothing substantial.

Software Was Never About Code

Rafael Abuawad — Thu, 22 Oct 2026 12:53:11 +0000

Ask an AI to build you a website, and you'll get vanilla HTML, CSS, and JavaScript. Ask for a web app, and you'll get React, probably with Next.js. Ask for a cross-platform app, and you'll get React Native. Ask for a desktop app, and you'll get Electron. The pattern holds for nearly everything that involves code: the model reaches for the most common, most widely used tool.

On its own, that isn't a bad thing. Those defaults are popular for a reason. At scale, though, it's a disaster.

Every tool existed for a reason

Software has so many tools because each one was built to solve something. Vue and Svelte exist because people kept running into the same problems with React. There's a long line of cross-platform frameworks because building for every platform at once has been a headache for years. Each of them started with someone who hit a limit and decided to build something better.

A model doesn't hit limits that way. It reaches for what it has seen most, and what it has seen most is whatever was already popular. New tools never get enough use to become the default, so the defaults keep getting more entrenched.

Follow that forward. If models keep getting smarter and costs stay roughly where they are, AI ends up writing most software. Every web app gets built with the same stack, and so does every static site and every smart contract. The huge variety of languages, frameworks and tools we had in the past stops growing. When AI can build anything faster and cheaper than any person, what's the point of building a new one?

Code is cheap now

Take that one step further. If everyone uses the same models to generate the same stack, code stops being an advantage. Whatever you built, your competitor can rebuild in a fraction of the time it took you.

AI hasn't made code good; that's a whole other essay. But it has made code cheap, and cheap things don't set you apart.

That's uncomfortable if you think of software as code. But software was never really about code.

What software is actually about

Software is distribution, marketing, getting in front of users, maintaining the product long after launch, and a lot more that has nothing to do with writing code. AI has made the code cheap, but it hasn't changed any of the rest.

People use a product because they expect it to work and they expect its makers to still be maintaining it next year. That trust is as much a part of the product as the code is.

Look at how many Notion copycats there are, and how many Granola copycats. Will any of them become a billion-dollar company? No. Most of the people behind them don't give a damn about the software itself. They care about the money, and getting the money takes far more than writing code. You can clone the features in a weekend. You can't clone the users, the trust, or the years of maintenance.

Disposable software

Something I find fascinating is the rise of disposable software: apps you spin up with AI in an afternoon and then forget ever existed, like a TikTok video. I'm not going to pretend I haven't done it myself.

The trend is going to grow. Most of that software is harmless, because it's built for one person and one use, and then it's gone. But it changes what people value. When anyone can make an app in an afternoon, an app by itself means nothing. What means something is software that someone stands behind.

The correction

All of this is hitting the job market. A lot of engineers can't find work that pays enough for an upper-middle-class life. That's assuming they can find a job at all and get through the interview.

I think a real crash is coming in tech, and it isn't about the AI bubble. The market is going to stop paying people who only produce code, because the machine produces it more cheaply. For years, producing code was enough to build a career on. It isn't anymore.

Smaller, and more elite

I don't think we'll ever see as many software jobs as we did in 2020. But I do think the market will recover. Once the hype settles, things will stabilize, and companies will still need people.

They'll need fewer people, and better ones. Programming is going to become more elitist, and only the best of the best will make meaningful money long-term. "Best" won't mean whoever solves LeetCode fastest. It will mean the people who understand the tradeoffs the machine makes, and the people who bring what the machine can't: product sense, the ability to reach users, and the commitment to keep something running for years.

When every app is built on the same stack by the same models, the code is the one thing that's identical everywhere. What sets a product apart is the people behind it.

How USDT Actually Works: From Treasury Bills to Smart Contracts

Rafael Abuawad — Mon, 19 Oct 2026 13:54:08 +0000

USDT is one of the world's largest stablecoins, and most people who use it every day have no idea how it works. In this article, we'll look at it from both ends: the business model that keeps it pegged to the dollar, and the smart contract that makes it move onchain. By the end, you'll have built your own version of USDT in Vyper.

Tether vs. USDT

First, the names. Tether is the company. USDT is the token it issues.

Tether manages the reserves that, in theory, back every USDT in existence across every chain it lives on: Ethereum, Tron, Solana, and many others. Each USDT is supposed to be redeemable for one US dollar, and Tether's reserves are what make that promise credible.

Where the money actually goes

This is where it gets interesting. Tether doesn't keep a giant pile of dollars in a vault. Most of its reserves are held in US Treasury bills, which are short-term debt issued by the US government. The rest is a mix of cash equivalents, gold, Bitcoin, and secured loans.

The scale is huge. Tether is one of the largest holders of US government debt in the world, ranking alongside entire countries. It has said it was among the top buyers of US Treasuries, competing with nations like Germany and South Korea.

What's a Treasury bill?

A Treasury bill (T-bill) is a short-term loan to the US government, maturing in one year or less. T-bills don't pay coupons. You buy them at a discount and receive the full face value at maturity, and the difference is your interest.

For example, you might pay $95,000 for a T-bill that pays you $100,000 a year later. That $5,000 is your return.

T-bills are considered about as close to risk-free as an investment gets, and they're highly liquid. That matters for a stablecoin: if many people want to redeem USDT at once, Tether needs to turn its reserves into cash quickly.

The business model

Look at this from Tether's side. People hand Tether dollars to get USDT, and USDT pays them no interest. Tether takes those dollars, buys T-bills, and keeps the yield.

With over a hundred billion dollars in reserves, even a 4–5% yield adds up to billions per year. That's why Tether is one of the most profitable companies in the world per employee. It reported roughly $10 billion in net profit in 2025, and it has a relatively small team.

It's a brilliant model. You create a digital dollar that people around the world use to save and transact, and in return you slowly build one of the largest Treasury portfolios on the planet.

What about fees?

If you've ever sent USDT, you've noticed that sending 1 USDT means the recipient gets 1 USDT. The gas fee goes to the blockchain's validators, not to Tether. So Tether doesn't earn anything from everyday transfers.

Where Tether does charge fees is at the edges of the system: minting and redemption. Regular users don't deal with Tether directly. Large, verified institutions such as exchanges, market makers, and payment companies deposit dollars to mint new USDT, or send USDT back to redeem dollars. Tether charges a small percentage fee on these operations and requires high minimums. It's a nice revenue stream, but the real money comes from the reserves.

Tether has other products and investments that we won't cover here. If you're curious, check out tether.to.

The catch: it's centralized

Everything above depends on trusting Tether. The peg holds because the market believes Tether actually has the reserves and will honor redemptions. Tether publishes quarterly attestations of its reserves, prepared by an accounting firm. But an attestation is a snapshot of holdings on a given date, not a full audit, and Tether has faced criticism over the years about transparency.

The smart contract reflects this centralization too. As we'll see, Tether can mint tokens, burn them, pause the contract, and freeze specific addresses.

Going to the source code

Now for the fun part. We'll look at USDT's Ethereum implementation and rebuild it ourselves in Vyper, a Pythonic language for writing Ethereum smart contracts.

If you're new to programming or Ethereum, don't worry. We'll go step by step.

USDT is (mostly) an ERC20

ERC20 is the Ethereum standard for fungible tokens. It's a small interface: six core functions (totalSupply, balanceOf, transfer, transferFrom, approve, allowance), three optional metadata functions (name, symbol, decimals), and two events (Transfer, Approval). Any contract that implements this interface can be held in wallets, traded on exchanges, and shown on block explorers as a token.

Here's a fun detail: the USDT contract on Ethereum isn't fully ERC20-compliant. It was written in 2017 in an old version of Solidity, and its transfer and transferFrom functions don't return a bool as the standard requires. This has broken many DeFi integrations over the years, and it's the reason libraries like OpenZeppelin's SafeERC20 exist. We'll come back to this when we write our own version.

Setting up the project

We'll keep the setup minimal. We'll use uv to manage dependencies and Titanoboa to compile and test our Vyper code.

Install uv.
Create the project: uv init <project_name>, move into it with cd <project_name>, then delete the generated main.py.
Create a virtual environment: uv venv
Activate it:
- Linux/macOS: source .venv/bin/activate
- Windows: .venv\Scripts\activate
Install Titanoboa: uv add titanoboa
Install pytest for testing: uv add --dev pytest

Titanoboa installs the Vyper compiler as a dependency. This article uses Vyper 0.4.3, and every file starts with # pragma version ==0.4.3 to pin it.

Project structure

<project_name>/
├── modules/          # reusable modules
│   ├── erc20.vy
│   ├── ownable.vy
│   ├── pausable.vy
│   └── blacklist.vy
├── contracts/        # smart contracts
│   └── usdt.vy
├── tests/            # tests
│   └── test_usdt.py
└── pyproject.toml

A quick word on modules

Solidity reuses code through inheritance. The original USDT is a tower of contracts: TetherToken inherits from Pausable, StandardToken and BlackList, which in turn inherit from Ownable and BasicToken.

Vyper takes a different approach: modules. A module is a regular .vy file with state and functions that a contract can import and reuse. There are no virtual or override keywords. Instead, a contract chooses which of a module's external functions to export into its own ABI. If it needs different behavior, it skips the export and writes its own version on top of the module's internal helpers.

We'll build four modules, one for each piece of the original contract, and then assemble them into the token.

ERC20

The first module holds the token's books: who owns how much (_balances), who may spend whose tokens (_allowances), and how many tokens exist (_total_supply).

It has two layers. The standard ERC20 functions are external, so any contract can export them as they are. The real logic lives in internal functions (_transfer, _approve, _spend_allowance, _mint, _burn) that other contracts can build on. That split will matter when USDT adds its own rules to transfer.

# modules/erc20.vy
# pragma version ==0.4.3
# pragma nonreentrancy on
"""
@title ERC20
@notice Minimal ERC20 accounting module. Holds balances, allowances
        and total supply, and exposes the standard ERC20 functions.
"""

from ethereum.ercs import IERC20
implements: IERC20


_balances: HashMap[address, uint256]
_allowances: HashMap[address, HashMap[address, uint256]]
_total_supply: uint256


@view
@external
def balanceOf(owner: address) -> uint256:
    return self._balances[owner]


@view
@external
def allowance(owner: address, spender: address) -> uint256:
    return self._allowances[owner][spender]


@view
@external
def totalSupply() -> uint256:
    return self._total_supply


@external
def approve(spender: address, amount: uint256) -> bool:
    self._approve(msg.sender, spender, amount)
    return True


@external
def transfer(receiver: address, amount: uint256) -> bool:
    self._transfer(msg.sender, receiver, amount)
    return True


@external
def transferFrom(owner: address, receiver: address, amount: uint256) -> bool:
    self._spend_allowance(owner, msg.sender, amount)
    self._transfer(owner, receiver, amount)
    return True


@internal
def _approve(owner: address, spender: address, amount: uint256):
    self._allowances[owner][spender] = amount
    log IERC20.Approval(owner=owner, spender=spender, value=amount)


@internal
def _transfer(sender: address, receiver: address, amount: uint256):
    assert receiver != empty(address), "erc20: transfer to zero address"
    # Vyper arithmetic is checked: this reverts if the balance is too low.
    self._balances[sender] -= amount
    self._balances[receiver] += amount
    log IERC20.Transfer(sender=sender, receiver=receiver, value=amount)


@internal
def _spend_allowance(owner: address, spender: address, amount: uint256):
    allowed: uint256 = self._allowances[owner][spender]
    # An allowance of max_value(uint256) is treated as infinite.
    if allowed != max_value(uint256):
        self._allowances[owner][spender] = allowed - amount


@internal
def _mint(receiver: address, amount: uint256):
    assert receiver != empty(address), "erc20: mint to zero address"
    self._balances[receiver] += amount
    self._total_supply += amount
    log IERC20.Transfer(sender=empty(address), receiver=receiver, value=amount)


@internal
def _burn(owner: address, amount: uint256):
    self._balances[owner] -= amount
    self._total_supply -= amount
    log IERC20.Transfer(sender=owner, receiver=empty(address), value=amount)

A few things worth noticing:

No SafeMath. The 2017 USDT contract needed a SafeMath library to guard against overflows. Vyper checks all arithmetic by default, so self._balances[sender] -= amount simply reverts if the sender doesn't have enough.
implements: IERC20 makes the compiler check that we match the standard, including returning bool from transfer and transferFrom. With this line, the compiler would have caught the original USDT's missing return value.
Minting is a transfer from the zero address, and burning is a transfer to it. This is the standard way to log supply changes, and block explorers rely on these Transfer events.
# pragma nonreentrancy on puts a reentrancy lock on every external function. Our token never calls other contracts, but it's a sensible default that costs us nothing to turn on.

Ownable

USDT is centralized, and this is the module that makes it so. Ownable stores one address, the owner, and gives other code a way to say "only the owner can do this."

# modules/ownable.vy
# pragma version ==0.4.3
# pragma nonreentrancy on
"""
@title Ownable
@notice Single-owner access control. Other modules call `_check_owner()`
        to restrict functions to the owner.
"""

event OwnershipTransferred:
    previous_owner: indexed(address)
    new_owner: indexed(address)


owner: public(address)


@deploy
def __init__():
    self._transfer_ownership(msg.sender)


@external
def transferOwnership(new_owner: address):
    self._check_owner()
    assert new_owner != empty(address), "ownable: new owner is zero address"
    self._transfer_ownership(new_owner)


@internal
def _check_owner():
    assert msg.sender == self.owner, "ownable: caller is not the owner"


@internal
def _transfer_ownership(new_owner: address):
    previous_owner: address = self.owner
    self.owner = new_owner
    log OwnershipTransferred(previous_owner=previous_owner, new_owner=new_owner)

@deploy marks the constructor. It runs once, when the contract is deployed, and makes the deployer the owner. public(address) tells Vyper to generate an owner() getter for us.

Solidity uses an onlyOwner modifier here. Vyper has no modifiers, so we call _check_owner() on the first line of each restricted function. It's more explicit, and you can see every check when you read the code.

Pausable

Pausable is an emergency brake. If something goes wrong, such as a hack or a bug, the owner can freeze all transfers at once.

# modules/pausable.vy
# pragma version ==0.4.3
# pragma nonreentrancy on
"""
@title Pausable
@notice Emergency stop switch controlled by the owner.
"""

from . import ownable
uses: ownable


event Pause:
    account: address


event Unpause:
    account: address


paused: public(bool)


@external
def pause():
    ownable._check_owner()
    assert not self.paused, "pausable: already paused"
    self.paused = True
    log Pause(account=msg.sender)


@external
def unpause():
    ownable._check_owner()
    assert self.paused, "pausable: not paused"
    self.paused = False
    log Unpause(account=msg.sender)


@internal
def _require_not_paused():
    assert not self.paused, "pausable: paused"

The key line is uses: ownable. Pausable needs to read the owner, but it shouldn't own the Ownable state. If it did, our final contract could end up with two owners. uses means "I depend on a module that someone else will initialize." When we assemble the token, we'll tell the compiler which ownable to plug in.

_require_not_paused() is the hook the token will call at the start of transfer and transferFrom.

BlackList

This is the feature people talk about most. Tether can freeze any address, and it does so regularly, often at the request of law enforcement. The original contract can also destroy the funds of a blacklisted address, which removes those tokens from circulation. Tether can then reissue them elsewhere, for example to the victim of a hack.

# modules/blacklist.vy
# pragma version ==0.4.3
# pragma nonreentrancy on
"""
@title BlackList
@notice Lets the owner freeze addresses and destroy the funds they hold.
"""

from . import ownable
uses: ownable


from . import erc20
uses: erc20


event AddedBlackList:
    account: indexed(address)


event RemovedBlackList:
    account: indexed(address)


event DestroyedBlackFunds:
    account: indexed(address)
    amount: uint256


is_black_listed: HashMap[address, bool]


@view
@external
def isBlackListed(account: address) -> bool:
    return self.is_black_listed[account]


@external
def addBlackList(account: address):
    ownable._check_owner()
    self.is_black_listed[account] = True
    log AddedBlackList(account=account)


@external
def removeBlackList(account: address):
    ownable._check_owner()
    self.is_black_listed[account] = False
    log RemovedBlackList(account=account)


@external
def destroyBlackFunds(account: address):
    ownable._check_owner()
    assert self.is_black_listed[account], "blacklist: account not blacklisted"
    amount: uint256 = erc20._balances[account]
    erc20._burn(account, amount)
    log DestroyedBlackFunds(account=account, amount=amount)


@internal
def _require_not_blacklisted(account: address):
    assert not self.is_black_listed[account], "blacklist: account is blacklisted"

This module uses two modules. It needs ownable for access control and erc20 so that destroyBlackFunds can read a balance and burn it.

Notice the two naming styles. Inside the module, the storage variable is is_black_listed, in Python-style snake_case. But the external functions and events (isBlackListed, addBlackList, destroyBlackFunds, and so on) keep the camelCase names of the original contract. The explicit isBlackListed getter is the bridge between the two.

Note that destroyBlackFunds only works on an address that is already blacklisted. Tether has to freeze the funds before it can destroy them.

USDT Token

Now we bring all the modules together.

# contracts/usdt.vy
# pragma version ==0.4.3
# pragma nonreentrancy on
"""
@title Tether USD (Vyper edition)
@notice An educational rebuild of the USDT Ethereum contract: an ERC20
        token that the owner can issue, redeem, pause and freeze.
"""

from ethereum.ercs import IERC20
implements: IERC20


from ethereum.ercs import IERC20Detailed
implements: IERC20Detailed


from ..modules import ownable
initializes: ownable


from ..modules import erc20
initializes: erc20


from ..modules import pausable
initializes: pausable[ownable := ownable]


from ..modules import blacklist
initializes: blacklist[ownable := ownable, erc20 := erc20]


exports: (
    erc20.balanceOf,
    erc20.allowance,
    erc20.totalSupply,
    ownable.owner,
    ownable.transferOwnership,
    pausable.paused,
    pausable.pause,
    pausable.unpause,
    blacklist.isBlackListed,
    blacklist.addBlackList,
    blacklist.removeBlackList,
    blacklist.destroyBlackFunds,
)


event Issue:
    amount: uint256


event Redeem:
    amount: uint256


@deploy
def __init__(initial_supply: uint256):
    ownable.__init__()
    erc20._mint(msg.sender, initial_supply)


@view
@external
def name() -> String[10]:
    return "Tether USD"


@view
@external
def symbol() -> String[4]:
    return "USDT"


@view
@external
def decimals() -> uint8:
    return 6


@external
def transfer(receiver: address, amount: uint256) -> bool:
    pausable._require_not_paused()
    blacklist._require_not_blacklisted(msg.sender)
    erc20._transfer(msg.sender, receiver, amount)
    return True


@external
def transferFrom(owner: address, receiver: address, amount: uint256) -> bool:
    pausable._require_not_paused()
    blacklist._require_not_blacklisted(owner)
    erc20._spend_allowance(owner, msg.sender, amount)
    erc20._transfer(owner, receiver, amount)
    return True


@external
def approve(spender: address, amount: uint256) -> bool:
    # Same rule as the original USDT: to change a non-zero allowance you
    # must first set it to zero. This mitigates the approve front-running
    # race, but it's also why `approve` on USDT trips up many integrations.
    assert amount == 0 or erc20._allowances[msg.sender][spender] == 0, "usdt: reset allowance to zero first"
    erc20._approve(msg.sender, spender, amount)
    return True


@external
def issue(amount: uint256):
    """
    @notice Mint new tokens to the owner. In practice this happens after an
            institution has wired dollars to Tether.
    """
    ownable._check_owner()
    erc20._mint(ownable.owner, amount)
    log Issue(amount=amount)


@external
def redeem(amount: uint256):
    """
    @notice Burn tokens from the owner's balance, e.g. after an institution
            has sent USDT back to Tether in exchange for dollars.
    """
    ownable._check_owner()
    erc20._burn(ownable.owner, amount)
    log Redeem(amount=amount)

Let's go through it piece by piece.

initializes says this contract owns the state of each module and is responsible for setting it up. This is where the uses dependencies get wired together. pausable[ownable := ownable] means "the ownable that Pausable depends on is this ownable." As a result, the whole contract shares a single owner and a single set of balances. The compiler checks this wiring for you. If you forget to initialize a module, or initialize one twice, the contract won't compile.

exports picks which module functions become part of the token's public ABI. The getters and admin functions are exported as they are. Notice that erc20.transfer, erc20.transferFrom and erc20.approve are not exported.

We write our own transfer, transferFrom and approve because USDT needs extra rules before a transfer goes through:

The contract must not be paused.
The sender (or, for transferFrom, the token owner) must not be blacklisted.

After those checks, we hand off to the ERC20 module's internal _transfer. Checking the token owner in transferFrom matters. Otherwise a frozen address could approve a friend, and the friend could move the funds out.

The approve quirk. The real USDT refuses to change an allowance from one non-zero value to another. You must set it to 0 first. This is meant to block a front-running attack on approve, and it's another famous source of broken integrations. We kept it so our token behaves like the real one.

issue and redeem are the onchain side of the business model. When an institution wires dollars to Tether, Tether calls issue to mint fresh USDT to its own treasury and then sends the tokens to the customer. When the customer sends USDT back for dollars, Tether calls redeem to burn them.

What we left out. The real contract has two more features that we skipped:

Transfer fee: basisPointsRate and maximumFee allow a fee on every transfer. It has always been set to zero, which is why, as we saw earlier, Tether earns nothing from transfers.
Upgrade: deprecate and upgradedAddress let Tether point all calls to a new contract.

What we did differently. Our transfer and transferFrom return bool, as ERC20 requires, so our token works with any DeFi protocol without special wrappers. Our issue also emits a standard Transfer event, which the 2017 contract doesn't.

Testing our USDT

Titanoboa lets us deploy the contract to a local EVM from Python and call it like a regular object. Create tests/test_usdt.py:

import boa
import pytest

INITIAL_SUPPLY = 1_000_000 * 10**6  # 1M USDT, 6 decimals


@pytest.fixture
def owner():
    return boa.env.eoa


@pytest.fixture
def alice():
    return boa.env.generate_address("alice")


@pytest.fixture
def bob():
    return boa.env.generate_address("bob")


@pytest.fixture
def usdt():
    return boa.load("contracts/usdt.vy", INITIAL_SUPPLY)


def test_metadata(usdt, owner):
    assert usdt.name() == "Tether USD"
    assert usdt.symbol() == "USDT"
    assert usdt.decimals() == 6
    assert usdt.totalSupply() == INITIAL_SUPPLY
    assert usdt.balanceOf(owner) == INITIAL_SUPPLY
    assert usdt.owner() == owner


def test_transfer(usdt, owner, alice):
    assert usdt.transfer(alice, 100) is True
    assert usdt.balanceOf(alice) == 100
    assert usdt.balanceOf(owner) == INITIAL_SUPPLY - 100


def test_transfer_insufficient_balance(usdt, alice, bob):
    with boa.env.prank(alice), boa.reverts():
        usdt.transfer(bob, 1)


def test_transfer_from(usdt, owner, alice, bob):
    usdt.approve(alice, 500)
    with boa.env.prank(alice):
        assert usdt.transferFrom(owner, bob, 200) is True
    assert usdt.balanceOf(bob) == 200
    assert usdt.allowance(owner, alice) == 300


def test_approve_must_reset_to_zero(usdt, alice):
    usdt.approve(alice, 500)
    with boa.reverts("usdt: reset allowance to zero first"):
        usdt.approve(alice, 100)
    usdt.approve(alice, 0)
    usdt.approve(alice, 100)
    assert usdt.allowance(boa.env.eoa, alice) == 100


def test_issue_and_redeem(usdt, owner, alice):
    usdt.issue(1_000)
    assert usdt.totalSupply() == INITIAL_SUPPLY + 1_000
    assert usdt.balanceOf(owner) == INITIAL_SUPPLY + 1_000

    usdt.redeem(1_000)
    assert usdt.totalSupply() == INITIAL_SUPPLY

    with boa.env.prank(alice), boa.reverts("ownable: caller is not the owner"):
        usdt.issue(1_000)


def test_pause(usdt, alice):
    usdt.pause()
    assert usdt.paused()
    with boa.reverts("pausable: paused"):
        usdt.transfer(alice, 1)

    usdt.unpause()
    usdt.transfer(alice, 1)
    assert usdt.balanceOf(alice) == 1


def test_only_owner_can_pause(usdt, alice):
    with boa.env.prank(alice), boa.reverts("ownable: caller is not the owner"):
        usdt.pause()


def test_blacklist(usdt, owner, alice, bob):
    usdt.transfer(alice, 100)
    usdt.addBlackList(alice)
    assert usdt.isBlackListed(alice)

    # Alice can't send...
    with boa.env.prank(alice), boa.reverts("blacklist: account is blacklisted"):
        usdt.transfer(bob, 1)

    # ...and nobody can move her funds with an allowance either.
    with boa.env.prank(alice):
        usdt.approve(bob, 100)
    with boa.env.prank(bob), boa.reverts("blacklist: account is blacklisted"):
        usdt.transferFrom(alice, bob, 1)

    usdt.removeBlackList(alice)
    with boa.env.prank(alice):
        usdt.transfer(bob, 1)
    assert usdt.balanceOf(bob) == 1


def test_destroy_black_funds(usdt, alice):
    usdt.transfer(alice, 100)

    with boa.reverts("blacklist: account not blacklisted"):
        usdt.destroyBlackFunds(alice)

    usdt.addBlackList(alice)
    usdt.destroyBlackFunds(alice)
    assert usdt.balanceOf(alice) == 0
    assert usdt.totalSupply() == INITIAL_SUPPLY - 100


def test_transfer_ownership(usdt, alice):
    usdt.transferOwnership(alice)
    assert usdt.owner() == alice
    with boa.reverts("ownable: caller is not the owner"):
        usdt.pause()
    with boa.env.prank(alice):
        usdt.pause()

A few Titanoboa tools do most of the work here:

boa.load compiles the contract and deploys it, passing INITIAL_SUPPLY to the constructor.
boa.env.eoa is the default account that sends our transactions, so it's also the deployer and owner.
boa.env.prank(alice) sends the calls inside the with block as Alice.
boa.reverts("...") checks that a call fails with the expected error message.

Run the suite from the project root:

$ pytest
...........                                                              [100%]
11 passed

Wrapping up

Strip away the billions of dollars, and USDT is a surprisingly small program. It's an ERC20 token with four admin powers: issue, redeem, pause and blacklist. Every one of them belongs to a single owner.

That's the whole story in code. The token is only worth a dollar because Tether holds T-bills offchain and honors redemptions, and the contract gives Tether complete control over who can hold and move it. Decentralized it is not, but it's one of the most successful products crypto has produced.

You now have a working version of it. Some ideas to take it further:

Add the transfer fee (basisPointsRate and maximumFee) from the original contract.
Replace the single owner with multiple roles, for example, separate minter, pauser, and blacklister addresses, the way newer stablecoins do.
Deploy it to a testnet and add it to your wallet.

Just don't expect it to hold its peg without a hundred billion dollars in Treasury bills behind it.

How to detect if an address is a smart contract using Vyper

Rafael Abuawad — Thu, 15 Oct 2026 14:19:48 +0000

1. Setup

For this guide, we'll use a minimal setup with uv as the dependency manager and Titanoboa to compile and test Vyper contracts.

If you're unfamiliar with Vyper, it's an EVM programming language with Python-like syntax. It's simple and direct, making it a great choice for developing efficient and secure smart contracts.

Create the project

Initialize a new project with uv:

uv init <project_name>

Create a virtual environment:

uv venv

Install Titanoboa:

uv add titanoboa

Ready!

2. Vyper Built-in Features

Now that Titanoboa is installed, how do we detect whether an address is a smart contract?

The `.is_contract` Property

All address variables in Vyper have an .is_contract property.

.is_contract → bool

Returns a boolean indicating whether a contract is deployed at the address.

It's that simple!

Create a file named Detector.vy inside a contracts folder:

contracts/Detector.vy

# pragma version ==0.4.3

@external
@pure
def is_target_a_contract(target: address) -> bool:
    return target.is_contract

Let's Test It!

In the main.py file at the project root, write the following:

main.py

import boa

USER = "0xC14fF56E720f79d08413CE00533256433D2ED928"
USDC = "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48"
VITALIK_ETH = "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"


def main():
    with boa.fork("https://ethereum-rpc.publicnode.com"):
        detector = boa.load("contracts/Detector.vy")

        assert detector.is_target_a_contract(USDC)
        assert not detector.is_target_a_contract(USER)
        assert not detector.is_target_a_contract(VITALIK_ETH)


if __name__ == "__main__":
    main()

Run the script:

uv run main.py

The Problem: EIP-7702

When performing an assertion on Vitalik's wallet, Vyper identifies it as a contract. Why?

This happens because the wallet uses EIP-7702 delegation. Technically, the account now has code, but how can we distinguish this case from a traditional smart contract?

3. Special Case: EIP-7702

To handle this, we need to inspect the code stored at the address.

If the code corresponds to EIP-7702 delegation, we'll consider the address not to be a traditional smart contract, even though .is_contract may return True.

The bytecode associated with EIP-7702 delegation starts with the same three bytes:

0xef0100

This prefix is the delegation designator. It indicates that an account delegates execution to another address.

We can read the address's .code property to inspect these bytes.

.code → Bytes

Returns the code associated with the address.

Updated Implementation

With this adjustment, we can distinguish between a traditional contract and an externally owned account (EOA) using EIP-7702 delegation.

contracts/Detector.vy

# pragma version ==0.4.3

@external
@view
def is_target_a_contract_and_not_an_eoa(_target: address) -> bool:
    if not _target.is_contract:
        return False

    # EIP-7702 delegation designator
    eip_7702: Bytes[3] = x"ef0100"

    # If the first three bytes match, treat it as a delegated EOA
    return slice(_target.code, 0, 3) != eip_7702

Tips

Why use slice? In Vyper, slice extracts a portion of a byte sequence. Here, it reads only the first three bytes, which is sufficient to check the prefix.
EIP-7702 context: This EIP allows EOAs to delegate execution to smart contract code, complicating traditional contract detection methods based on code presence.

4. Other Detection Methods

Although .is_contract is a native Vyper property, you may encounter other approaches in older codebases or Solidity projects.

Method 1: Comparing `msg.sender` and `tx.origin`

This approach is sometimes used to check whether the caller is an EOA or another contract.

If msg.sender == tx.origin, the caller is often assumed to be a regular wallet. However, this only validates the current caller; it does not let you check an arbitrary address.

# pragma version ==0.4.3

@external
@view
def only_humans():
    # If they are equal, the caller is traditionally considered an EOA.
    assert msg.sender == tx.origin

The relevant properties are:

msg.sender → address: The immediate caller of the current call.
tx.origin → address: The original account that initiated the transaction.

Caution: This check is not a reliable way to establish that a caller is human or that it cannot be a smart wallet. It can also break compatibility with account abstraction and smart-wallet systems.

Method 2: Checking Code Size with `.codesize`

A classic approach is to check whether the address has any code.

If the code size is greater than zero, the address is traditionally considered a contract.

# pragma version ==0.4.3

@external
@view
def is_target_a_contract(target: address) -> bool:
    return target.codesize > 0

However, code-size checks share the same EIP-7702 limitations as other methods based on detecting whether code exists.

5. Which Method Should You Use?

For modern Vyper development:

.is_contract — The preferred option when you want a readable, direct check for whether an address has code associated with it.
msg.sender == tx.origin — Avoid using this as a general contract-detection or security mechanism. It is limited to the current caller and can break compatibility with smart wallets.
.codesize > 0 — A classic alternative, but it has the same EIP-7702 limitations as other code-size checks.
Inspecting .code for the EIP-7702 prefix — Useful when your application specifically needs to distinguish delegated EOAs from traditional contracts.

The key takeaway: Choose your detection method based on what you actually need to establish. An address having code, being an EOA, and being controlled by a human are three different properties.

How to Implement the ERC-165 in Vyper

Rafael Abuawad — Mon, 12 Oct 2026 19:57:22 +0000

Liquid syntax error: Unknown tag 'preview'

Polymarket and the oracle problem

Rafael Abuawad — Mon, 12 Oct 2026 19:42:23 +0000

When I first heard about Polymarket, I really liked the idea, and I still do. The fact that any future event can become tradable and, by doing so, people will put their money on what they TRULY believe will happen is actually pretty good, especially for large, important events.

But most prediction markets, including Polymarket, have many flaws. The main one, and the most apparent, is the fact that the Oracle they use is not neutral.

What is an Oracle?

If you are new to crypto or are not too deep into web3 lore, there is a problem called the Oracle Problem. This problem arises from the fact that blockchains are isolated systems, and getting data from the outside world is complicated, especially because you don't want to rely on a single entity to supply you with this information.

A lot of products have raised millions of dollars in capital just to solve this issue. These products are known as Oracles, and their job is essentially to feed smart contracts data coming from external systems, like markets and events.

" width="800" height="290">

Chainlink is a well-known one, providing price feeds and random numbers using a decentralized network of independent node operators. UMA tries to solve the oracle problem using tokenomics. UMA holders can dispute results by posting bonds at the optimistic-oracle layer, and staked UMA tokenholders vote when disputes escalate to the DVM. The core idea is simple: it is not in UMA holders' best interest to fake the data they feed to the oracle, because that would instead make the data coming from the oracle worthless.

Polymarket and Bias

Here is where this becomes a theory, but what I think is happening on markets like "MicroStrategy sells Bitcoin by May 31st" is the following:

A lot of UMA holders position themselves deep in the most likely outcome. In this case, on the NO side of the trade. This is a simple trade: something that has a 99% chance of happening, and if you invest $1,000,000 into it, you can easily make more than ~$10,000 almost risk-free.

Key word here: almost

In the unlikely scenario that the event happens (or doesn't happen, depending on the market), the losses can be devastating, transferring millions of dollars from the market. What I think is happening is that a lot of UMA whales enter these trades in order to make a few mil on the side, almost risk-free, but when things don't go their way, they favor their original position at resolution time.

A WSJ-cited analysis reported that in roughly 1 in 5 disputed bets, at least one voter had a direct financial interest.

The MicroStrategy facts — Important nuance:

Strategy did sell 32 BTC between May 26 and 31 (inside the deadline).
The fight was whether the resolution requires public confirmation by May 31, not just the sale occurring.
Polymarket posted additional context after the June 1 8-K, stating confirmation outside the window doesn't qualify.
Final DVM vote reportedly backed NO with ~98.6% of voting power.

In the MicroStrategy market, Strategy disclosed a sale that occurred before May 31, but Polymarket later clarified that confirmation outside the deadline would not count. The dispute then went to UMA tokenholders, who overwhelmingly ratified NO.

How to create your own cryptocurrency using Vyper and Python

Rafael Abuawad — Thu, 08 Oct 2026 15:56:31 +0000

Welcome. This article covers something very simple: how to create a cryptocurrency using Vyper and Python. This guide is designed for beginners or enthusiasts who already know a bit about blockchain and want to dive deeper.

This is not an introduction to programming (we won't cover basic variables or functions) or fundamental blockchain concepts. It assumes you already understand what a cryptocurrency and a wallet address are. By the end, we will have a cryptocurrency written in Vyper ready for the Arbitrum network.

Throughout this article, I will use the terms "cryptocurrency" and "ERC20" interchangeably.

What is a Cryptocurrency? What is an ERC20?

An ERC20 is the technical standard used for smart contracts on the Ethereum Virtual Machine (EVM). EIP-20 defines the rules a contract must follow to be considered a cryptocurrency and be compatible with exchanges and wallets.

Essentially, we need to implement 6 basic functions:

totalSupply: The total number of coins in circulation.
balanceOf: Shows the balance of a specific address.
transfer: Sends coins from the owner to a destination.
allowance: The amount a third party is permitted to move on behalf of the owner.
approve: Authorizes an external address to move coins on behalf of the owner.
transferFrom: Allows an authorized address to execute the movement of funds.

Additionally, we will implement 3 optional functions that improve the user experience:

name: Name of the cryptocurrency (e.g., Bitcoin).
symbol: Cryptocurrency symbol (e.g., BTC).
decimals: Number of decimal places (usually 18).

Setup

We will use a minimal setup with uv as a dependency manager and Titanoboa to compile Vyper.

Install UV.
Create the project: uv init <project_name>
Create a virtual environment: uv venv
Activate the environment:
Linux/macOS: source .venv/bin/activate
Windows: .venv\Scripts\activate
Install Titanoboa: uv add titanoboa

Project Structure
📂 contracts/: Where we will store the smart contract.
📂 scripts/: Python scripts for deployment.
📂 tests/: Unit tests for our ERC20.

Developing our Cryptocurrency

Create the file contracts/ERC20.vy.

Pragma

The pragma indicates which compiler version was used. We will use 0.4.3.

# pragma version ==0.4.3

Implementing `totalSupply` and Immutables

We will define the name and symbol as state variables. For the total supply, we will use a public variable.

name: public(String[32])
symbol: public(String[10])
decimals: public(uint8)
totalSupply: public(uint256)

@deploy
def __init__(_name: String[32], _symbol: String[10]):
    self.name = _name
    self.symbol = _symbol
    self.decimals = 18

By using public(...), Vyper automatically creates the getter function for us.

Implementing balanceOf

We will use a HashMap to track how much each wallet holds.

balanceOf: public(HashMap[address, uint256])

💡 It is a good idea to mark internal variables with an _ (underscore), but by using public(), Vyper handles external visibility for us efficiently.

Implementing `transfer`

The transfer function is the heart of our coin. It allows moving value from point A to point B.

In Vyper, the logic is straightforward: we subtract from the sender and add to the receiver.

@external
def transfer(_to: address, _value: uint256) -> bool:
    """
    @dev Transfers tokens to a specified address.
    @param _to The address to transfer to.
    @param _value The amount to transfer.
    """
    self.balanceOf[msg.sender] -= _value
    self.balanceOf[_to] += _value
    return True

What is happening here?

@external: Allows anyone or any contract to call this function.
msg.sender: A global variable representing the address of whoever is executing the transaction.
Extra security: Unlike older versions of other languages, Vyper natively handles overflow. If you try to send more than you have, the transaction automatically fails without extra code.

Delegating Power: `approve` and `transferFrom`

The concept of Allowance is what makes ERC20s so powerful. It allows you to authorize an address (for example, a Decentralized Exchange) to withdraw a specific amount of tokens from your wallet.

1. The Allowance Mapping

First, we need a structure to store who has permission to withdraw from whom. We will use a nested HashMap:

# Owner -> (Spends for me -> Amount)
allowance: public(HashMap[address, HashMap[address, uint256]])

2. approve Function

With this function, the user says: "I authorize this application to spend X amount of my tokens."

@external
def approve(_spender: address, _value: uint256) -> bool:
    """
    @dev Authorizes `_spender` to transfer up to `_value` tokens.
    """
    self.allowance[msg.sender][_spender] = _value
    return True

3. transferFrom Function

This is the function called by the authorized application. Note that here the sender is not the token owner, but the "spender".

@external
def transferFrom(_from: address, _to: address, _value: uint256) -> bool:
    """
    @dev Moves tokens from `_from` to `_to` using the allowance mechanism.
    """
    # If there is not enough permission, Vyper will throw an overflow error
    self.allowance[_from][msg.sender] -= _value

    # Move the balances
    self.balanceOf[_from] -= _value
    self.balanceOf[_to] += _value

    return True

Events: The Final Touch

For interfaces like MetaMask or Etherscan to show your transactions in real-time, you need Events. Without them, the contract works, but it will be "invisible" to many applications.

Add this to the top of your file, below the pragma:

event Transfer:
    sender: indexed(address)
    receiver: indexed(address)
    value: uint256


event Approval:
    owner: indexed(address)
    spender: indexed(address)
    value: uint256

Important: Make sure to call log Transfer(...) and log Approval(...) inside their respective functions so the standard is 100% official.

@external
def transfer(...) -> bool:
    # ...
    log Transfer(_from=msg.sender, _to=_to, _value=_value)
    return True


@external
def approve(...) -> bool:
    # ...
    log Approval(_owner=msg.sender, _spender=_spender, _value=_value)
    return True


@external
def transferFrom(...) -> bool:
    # ...
    log Transfer(_from=_from, _to=_to, _value=_value)
    return True

You now have a complete and functional ERC20 contract. It is minimalist, secure, and follows Vyper 0.4.3 best practices.

Optimizations: Saving Gas with immutable

If you are launching your coin on a network, every unit of gas counts. In the version we wrote above, the name, symbol, and decimals are saved in the blockchain's storage. Reading from storage is one of the most expensive operations in terms of gas.

For values that never change after deploying the contract, Vyper offers the immutable wrapper.

Why use immutable?

By marking a variable as immutable, Vyper does not save it in expensive storage space. Instead, the value is embedded directly into the contract's bytecode during deployment. This makes reading this data extremely cheap (almost free).

The Optimized Code

Here is what the implementation looks like using immutables in Vyper 0.4.3:

# Declare immutable variables (UPPERCASE is recommended)
NAME: immutable(String[10])
SYMBOL: immutable(String[5])
DECIMALS: immutable(uint8)


@deploy
def __init__(_name: String[10], _symbol: String[5]):
    # Assigned only once in the constructor
    NAME = _name
    SYMBOL = _symbol
    DECIMALS = 18


# Create external functions to comply with the ERC20 standard
@external
@view
def name() -> String[10]:
    return NAME


@external
@view
def symbol() -> String[5]:
    return SYMBOL


@external
@view
def decimals() -> uint8:
    return DECIMALS

When to use it?

YES: For the name, symbol, decimals, or an initial owner's address that will not change.
NO: For balances or any value you need to update in the future.

Mint Implementation

We implement this logic by dividing it into parts: an immutable variable to know who the smart contract creator is, an external function for access control, and an internal one for accounting logic.

OWNER: immutable(address)


@deploy
def __init__(...):
    # ...
    OWNER = msg.sender


@external
def mint(_to: address, _value: uint256) -> bool:
    assert msg.sender == OWNER, "Only the OWNER can mint"
    self._mint(_to, _value)
    return True


@internal
def _mint(_to: address, _value: uint256):
    self.balanceOf[_to] += _value
    self.totalSupply += _value
    log Transfer(_from=empty(address), _to=_to, _value=_value)

Key points of this implementation:

Access Control: We use assert msg.sender == OWNER to ensure no one else can arbitrarily inflate the token supply.
Total Supply Management: Unlike a standard transfer, mint increases the self.totalSupply variable, maintaining global balance integrity.
Emission Convention: Following best practices, we emit the Transfer event using empty(address) (the 0x00... address) as the origin. This indicates to block explorers that the tokens didn't come from another user but were just created.
Logic Separation: Defining _mint as an @internal function is a recommended practice. It allows us to reuse the minting logic from other contract functions in future versions without repeating code or exposing access publicly.

💡 Adding functions like mint doesn't break compatibility with the standard. The ERC20 defines a minimum mandatory interface; as long as those base functions exist and behave as expected, you can add all the extra logic you need.

Full Code (Vyper 0.4.3)

Here is the final, optimized contract ready for deployment:

# pragma version ==0.4.3


event Transfer:
    _from: indexed(address)
    _to: indexed(address)
    _value: uint256


event Approval:
    _owner: indexed(address)
    _spender: indexed(address)
    _value: uint256


# Immutables
NAME: immutable(String[10])
SYMBOL: immutable(String[5])
DECIMALS: immutable(uint8)
OWNER: immutable(address)

# Storage Variables
balanceOf: public(HashMap[address, uint256])
allowance: public(HashMap[address, HashMap[address, uint256]])
totalSupply: public(uint256)


@deploy
def __init__(_name: String[10], _symbol: String[5]):
    NAME = _name
    SYMBOL = _symbol
    DECIMALS = 18
    OWNER = msg.sender


@external
def transfer(_to: address, _value: uint256) -> bool:
    """
    @dev Transfers tokens to a specified address.
    @param _to The address to transfer to.
    @param _value The amount to transfer.
    """
    self.balanceOf[msg.sender] -= _value
    self.balanceOf[_to] += _value
    log Transfer(_from=msg.sender, _to=_to, _value=_value)
    return True


@external
def approve(_spender: address, _value: uint256) -> bool:
    """
    @dev Authorizes `_spender` to transfer up to `_value` tokens.
    """
    self.allowance[msg.sender][_spender] = _value
    log Approval(_owner=msg.sender, _spender=_spender, _value=_value)
    return True


@external
def transferFrom(_from: address, _to: address, _value: uint256) -> bool:
    """
    @dev Moves tokens from `_from` to `_to` using the allowance mechanism.
    """
    self.allowance[_from][msg.sender] -= _value
    self.balanceOf[_from] -= _value
    self.balanceOf[_to] += _value
    log Transfer(_from=_from, _to=_to, _value=_value)
    return True


@external
def mint(_to: address, _value: uint256) -> bool:
    """
    @dev Mints `_value` amount of coins to `_to`
    """
    assert msg.sender == OWNER, "Only the OWNER can mint"
    self._mint(_to, _value)
    return True


@external
@view
def name() -> String[10]:
    return NAME


@external
@view
def symbol() -> String[5]:
    return SYMBOL


@external
@view
def decimals() -> uint8:
    return DECIMALS


@internal
def _mint(_to: address, _value: uint256):
    self.balanceOf[_to] += _value
    self.totalSupply += _value
    log Transfer(_from=empty(address), _to=_to, _value=_value)

Python Script: Blockchain Deployment

For the final touch, we will use Titanoboa (or boa), an extremely lightweight and powerful framework for deploying and testing Vyper contracts using pure Python.

1. Script Setup

Create a folder called scripts/ and, inside it, a file named deploy.py.

Install eth-account to manage our keys securely: uv add eth-account

2. Security First: The Keystore

Golden Rule: Never leave your private key in plain text in your code or in .env files. It's the easiest way to get your funds stolen.

We will use a Keystore JSON file (a password-encrypted file). If you use tools like Ape or Foundry, you already have them; if not, make sure to generate one with eth-account.

3. The Deployment Code

Here is the complete script. It is configured for the Arbitrum Mainnet RPC, but you can change it to Sepolia if you prefer to test first.

import getpass
import boa
from eth_account import Account

def load_keystore_account():
    """Securely loads an account from a keystore file."""
    with open("account.keystore.json", "r") as acc:
        password = getpass.getpass("\t Enter your Keystore password: ")
        encrypted_account = acc.read()
        account_pk = Account.decrypt(encrypted_account, password)
        return Account.from_key(account_pk)

def main():
    # 1. Define the network (Arbitrum in this case)
    # You can use a provider like Alchemy/Infura if you want
    rpc_url = "https://arb1.arbitrum.io/rpc"

    with boa.set_network_env(rpc_url):
        # 2. Load the account and add it to the boa environment
        account = load_keystore_account()
        boa.env.add_account(account)

        print(f"Deploying contract with account: {account.address}...")

        # 3. Deploy the contract
        # boa.load compiles and sends the deployment transaction
        erc20_contract = boa.load(
            "contracts/ERC20.vy", 
            "My Token",    # _name
            "MT"           # _symbol
        )

        print(f"Success! Contract deployed at: {erc20_contract.address}")
        return erc20_contract

if __name__ == "__main__":
    main()

4. Launching the Token

To execute it, simply run in your terminal: uv run scripts/deploy.py

Titanoboa will compile your Vyper code on the fly, sign the transaction with your encrypted account, and send it to the Arbitrum network.

Crypto is changing, and that is a good thing... In the long term

Rafael Abuawad — Wed, 07 Oct 2026 23:22:11 +0000

Hackathons have changed completely.

You are now most likely not competing for money but for the chance to make money in the long run. That is understandable: most hackathons were won by “bounty hunters,” people who did not want to build the product and only wanted a quick cash grab- literal bounty hunters. That hurt hackathons, and chains have realized there are few incentives left for hosting them. Now hackathons are focused on taking your idea (or MVP) to a real product that generates revenue and has users. That is a better approach in the long term because you reward people who are building real solutions and want to build for the long term, instead of people who build only to collect a check and say goodbye.

Grants have disappeared.

Most grant programs have disappeared completely, but many of the chains that gave those grants have not stopped making revenue, so the funds are still there. What I imagine is that grants will focus on key tooling (compilers, frameworks, etc.) and on already existing protocols, which makes a lot of sense. Grants were used to bootstrap ideas; how many successful ideas did they bootstrap? A really small number. Now you have to put yourself out there first, and then you can get the money to keep going, which rewards builders in the long term.

Blockchains are (finally) becoming just part of the stack, not the unique selling point.

Let me explain: in the early 2020s, protocols were valued at millions (millions!!) just because they were the only ones doing X on Y blockchain. That was misguided. Blockchains should always have been an implementation detail, not the USP. For example, look at something like Polymarket: do people using Polymarket know they are on Polygon? No. Most of them do not even know they are using a blockchain, and that was the end goal all along. The blockchain should just be part of the stack. Users do not care which blockchain you are building on; they care about the product. You (the developer) are the one who should care, but the end user should not. Good examples of this are Hyperliquid, Polymarket, and USDT.

Liquidity is going to concentrate.

In the next couple of years, we are going to see a lot of protocols and chains close and wind down. That is a good thing in the long term, but it is going to signal a new age in crypto. Protocols with no purpose or use case are going to become irrelevant, which, if you think about it, is exactly what happens in every industry. For example, I never saw the use case for POAPs. A lot of people seem shaken by the news of them discontinuing the product, but in reality, the product was overvalued.

Why "create a wallet" is where most people quit crypto

Rafael Abuawad — Wed, 07 Oct 2026 23:00:12 +0000

Ask a new user to "create an account" and they know what to do. Ask them to "create a wallet" and you've already lost half of them.

I've worked in Web3 for the last five years as a full-stack and smart contract developer at startups and protocols. I've given talks to both technical and non-technical audiences, and one theme keeps coming up: Web3 is extremely complicated for 99% of people. The trouble starts on the very first screen.

An account is not a wallet

Every app people use has accounts. You sign up with your email, you forget your password, you click "reset password," and you're back in. Nobody thinks twice about it.

A crypto wallet works differently. There's no "forgot password" button. You get a seed phrase, which is 12 or 24 random words that you're told to write on paper and never show anyone. If you lose those words, or the private key behind them, your money is gone. Forever. No support team can get it back.

For someone who just wants to receive a payment, that's terrifying. It also opens the door to scams: a fake "support agent" asking for your seed phrase is one of the most common ways people get drained.

Self-custody is great

Self-custody has real benefits, and people who want it should have it. But making it the entry point means most people never get past step one. They don't want to manage keys. They want to log in and get to their money.

✨🍉 Sandia lets you log in with your email. Simple as that.

Use it now at: sandiapay.app

About Sandia

Sandia started with a simple question: what if using Web3 wasn't complicated? Log in with your email and get all the good parts of Web3 (stablecoins, yield, tokenized stocks) without the headaches.

Sandia is live, and every feature is free. It's under active development, so if you find a bug, want a feature, or have a suggestion, I'd love to hear it.

👉 sandiapay.app

This post is part of the **What's broken in Web3* series:*

Why "create a wallet" is where most people quit crypto
"So I need ETH to move my USDT?" The gas fee problem
"Oh. That's on Ultraminion Chain." Why crypto payments keep getting lost
DeFi shouldn't need three approvals and a scam detector

Web3 Security: How to Protect Your Private Key using Python

Rafael Abuawad — Tue, 06 Oct 2026 19:14:15 +0000

In Smart Contract development, the most common (and costly) mistake is leaving private keys in plaintext within .env files or directly in the code. If accidentally pushed to GitHub, your funds will disappear in seconds.

The professional solution is to use a Keystore JSON: an encrypted file that protects your key with a password. This guide explains how to create a Keystore manager using Python.

Project Setup

We will use uv, the fastest Python package manager, and the official Ethereum Foundation library.

Initialize the project: uv init keystore_manager
Install dependencies: uv add eth-account
Create the file: touch manager.py

The Code: Keystore Manager

The script prompts for your private key and a password to generate an encrypted file.

import getpass
import json

from eth_account import Account


def main():
    print("/*´:°•.°+.*•´.*:˚.°*.˚•´.°:°•.°•.*•´.*:˚.°*.˚•´.°:°•.°+.*•´.*:*/")
    print("/*                      KEYSTORE MANAGER                      */")
    print("/*.•°:°.´+˚.*°.˚:*.´•*.+°.•°:´*.´•*.•°.•°:°.´:•˚°.*°.˚:*.´+°.•*/")

    private_key = getpass.getpass("\n Enter your private key: ")

    password = getpass.getpass("\n Enter a password: ")
    password_confirm = getpass.getpass("Confirm your password: ")

    if password != password_confirm:
        print("\n ---ERROR \nPasswords do not match")
        return

    loaded_account = Account.from_key(private_key)
    json_key_store = loaded_account.encrypt(password=password)

    with open("account.keystore.json", "w") as fp:
        json.dump(json_key_store, fp)
        print("\n Keystore created successfully")
        return


if __name__ == "__main__":
    main()

Key Security Points

getpass: Essential for terminal scripts. It prevents your private key or password from appearing in console history or being visible to onlookers.
Account.encrypt: Uses the Ethereum encryption standard. This generates a file that can only be decrypted with the correct password.
.gitignore: Even if encrypted, never upload these files to public repositories. Add *.json or your specific keystore filename to your .gitignore.

Usage

To run your manager, execute:
uv run manager.py

Once the account.keystore.json file is generated, you can securely use it in your deployment scripts with Titanoboa, Ape, or Foundry.

Onchain experiments, and why we need them

Rafael Abuawad — Tue, 06 Oct 2026 15:55:35 +0000

The blockchain industry should never go stale, but something’s off. What used to feel wide open is getting squeezed by prediction markets and memecoins. That can’t be the whole story.

When I first ran into Web3, CryptoKitties were a thing, NFTs were everywhere, and DeFi was exploding. You could seriously imagine building the next decentralized stablecoin, the next onchain collectible, the next lending protocol, with millions of people actually using the chain.

Then a lot changed. Thousands of protocols never shipped. Thousands more faded away. And many of the same names that have been here forever seem to have stopped pushing new ideas.

People stopped caring, but it doesn’t have to stay that way. We can still build a better future for blockchains; we just need new onchain experiences: less speculation, more real use cases, more things that hold up over time.

Developers need a web3-first mindset.

What I mean: build truly permissionless, trustless protocols- protocols anyone can extend and compose on without an API key- a better use of blockchain tech. Onchain experiments need to feel exciting again. We need novel DeFi, new onchain games, etc. And goes without saying, we should also revisit older ideas that faded because of tech limits or market cycles. Bring that energy back.

Projects like COINS by @z0r0zzz are exactly the kind of direction that’s interesting and has real room to grow.

We should build applications people want to use, applications that use what blockchains are uniquely good at. The old excuse list is shorter now: many technical limitations are gone, and we have the tooling to make UX genuinely smooth.

How much value have something like ve(3,3) & Solidly added to DeFi? Something like Aave? Something like Uniswap Hooks? We need that... but times ten.

I’ll go further: we should bring decentralized algorithmic stablecoins back into the conversation; the current landscape still isn’t good enough.

To be clear: I’m not telling anyone to dump their life savings into a random DeFi protocol coded in a basement with two fever dreams and a chatbot.

I am saying we should give serious experiments a fair shot, because something real can still come out of them.

The industry has centered itself on speculation. Crypto can do more, and even where speculation exists, we can still aim for setups that are more decentralized, more trustless, with stronger game theory, and less extractive.

TLDR: Make onchain experiments cool again. Build with a web3-first developer mentality. Explore new ideas, and revive old ones worth another look.