DEV Community: Rafael Abuawad

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.

Rethinking Web3 Development

Rafael Abuawad — Tue, 06 Oct 2026 15:31:16 +0000

Why Most Devs Are Missing the Point

The problem here is that 80% of developers working in the industry have no idea how to think in terms of blockchain tech. What I've seen is that most developers use the blockchain as a replacement for their backend and their database, turning the blockchain into the most expensive database in the world. This, for me, is a problem not only because most developers are not using any of the virtues of blockchain tech, but because this is stopping developers from innovating and coming up with new ideas. And for most developers, it's difficult to think in terms outside of Web2 or databases. In this article, I want to go over how one can start thinking in terms of Web3 and make better use of the technology in general.

What Do I Mean by Web3 Thinking?

Now, what do I mean by Web3 thinking? Let's start with some examples to illustrate the shift from traditional approaches to ones that leverage blockchain's unique properties like decentralization, permissionlessness, and composability.

Example 1: User Login and Profiles

Let's say you've created an application that requires users to create a profile in order to access it. I'm going to give you a few seconds to think about how you can do that using Solidity... Well, most people come up with something like this:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.27;

contract Pixelmon {
    struct User {
        string username;
        string bio;
    }

    mapping (uint256 _id => User _user) public users;

    // ...
}

They pass that to a mapping, and after that you have an indexed mapping that maps each user to an ID. Is this inherently bad? No, but it doesn't benefit from working on a blockchain. It doesn't benefit from having a decentralized ledger and autonomous code keeping it working.

What would be a better way of registering users? How about a soulbound NFT with onchain dynamic metadata-something that can easily identify the user and sell as a benefit from at least some of the properties of the blockchain**. This way, the profile becomes transferable (or not, if soulbound), verifiable across chains, and composable with other apps. For instance, imagine linking it to DeFi protocols where the NFT could accrue reputation or rewards based on user activity, all without a centralized database.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.27;

import {ERC721} from "@openzeppelin/contracts/token/ERC721/ERC721.sol";

contract PixelmonUser is ERC721 {
    constructor() ERC721("PixelmonUser", "PIX") {}

    function tokenURI() public view (string memory) {
        // ... Dynamic profile
    }
}

Example 2: Building a Betting Application

Here's another example: Let's say you are creating a betting application. How do you represent a bet? Most people are going to create a struct similar to this:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.27;

contract Betting {
    struct Bet {
        string description;
        uint256 in_favor;
        uint256 against;
        // ...
    }

    mapping(uint256 _index => Bet _bet) public bets;
    mapping(uint256 => mapping(address => uint256)) public betAmounts;
}

And attach some mapping to say who voted for whom, and call it a day. That is not good.

What could have been done instead? What about a pool with two tokens, one ERC1155: one represents the IN FAVOR side of the bet and the other one represents the AGAINST side. The bet becomes something more, something other people can build upon and even use.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.27;

import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";

contract Betting is ERC1155
    uint256 public constant IN_FAVOR = 0;
    uint256 public constant AGAINST = 1;

    function bet(uint256 tokenId /* ... more params */) public {
        // ...
    }
}

It becomes permissionless.

For example, users could trade these tokens on a DEX, creating secondary markets around the bet’s outcome. Oracles could resolve the bet autonomously, distributing winnings based on token holdings. This turns a simple bet into a composable financial instrument that integrates with the broader Web3 ecosystem, rather than just a siloed entry in a smart contract.

Why does this matter? Because this kind of thinking, leveraging blockchain’s unique properties like permissionlessness and composability, unlocks innovation. Instead of rebuilding Web2 apps onchain, we’re creating systems that are open, interoperable, and extensible by anyone in the ecosystem.

Why Are Devs Missing This?

So why do we keep seeing the same old designs, smart contracts that mimic SQL databases or centralized apps with a blockchain sticker slapped on? Two reasons stand out. First, most developers are stuck in a Web2 mindset, trained to think in terms of SQL databases and front-end frameworks. Second, and this is the kicker, many Web3 developers don’t actually use Web3 themselves.

The Bigger Issue: Devs Not Eating Their Own Medicine

I’m not talking about the 1% of smart contract devs you see flexing on CT. I’m talking about the average developer who landed a job at a crypto company but whose only “crypto” experience is buying BTC on Coinbase or trading on Binance.

I’ve heard stories, too many stories, of developers who didn’t even know how to send USDC. No shade, but how do you innovate in a space you don’t live in?

This is why we’re stuck. If you’ve never swapped on a DEX, minted an NFT, or voted in a DAO, how can you dream up the next big thing? To break out of this rut, devs need to dive into the ecosystem headfirst. Only then will we stop building glorified databases and start pushing Web3 forward.

To fix this, you need to dive in and try to think in terms in terms of Web3. Then can see the tech's true potential.

Web3: The "Ghost Chains" Problem and the Token Bubble

Rafael Abuawad — Tue, 06 Oct 2026 14:55:04 +0000

Why most Web3 products still look like smoke and mirrors, and what we (as developers) can do to solve it.

1. The Problem: Multi-million Dollar Solutions for Non-existent Problems

The biggest failure of Web3 today is that we have solutions looking for problems, or multi-million dollar infrastructures that do not resolve real needs.

A clear example is the saturation of L1 Blockchains without users. You only need to look at the data to notice the disconnect: blockchains valued at billions with minuscule on-chain activity and fee generation.

2. The Solution: Apps > Infrastructure

As developers, we must shift our focus. The market doesn't need another L1 or another L2; it needs applications.

99.9% of use cases can be perfectly resolved on the current EVM or SVM. The infrastructure already exists. Our job now is to build products that people want and can use, whether for Web3 veterans or the common user.

3. The Token Paradox: Towards "Desensitization"

Here is where I have an unpopular opinion: we need more tokens, not fewer.

We need to reach a saturation point, similar to the dot-com bubble. In the 90s, having a website absurdly inflated a company's valuation, until the bubble burst and we understood that a website is a tool, not a guarantee of value.

The same must happen with tokens. We should generate millions a day, just as we generate HTML, videos, or posts. By flooding the market, we desensitize people: a project having a token shouldn't mean it has intrinsic financial value. Only then will we cleanse the industry of empty speculation.

Last year was the turning point. If you were active in crypto, you'll remember the memecoin fever, where even the President of the US launched his own. That saturation without intrinsic value was necessary: it taught the market that having a token guarantees no value and that the barrier to entry for creating magical money is null.

Building Pasanaku: From Trusted to Trustless

Rafael Abuawad — Mon, 21 Sep 2026 15:51:55 +0000

Putting pasanaku.fun onchain and online has been an amazing journey, and it is a journey that is still ongoing.

The protocol has gone through many, many iterations. I’m grateful for all of them, because I learned a lot while trying to build the perfect onchain rotating savings mechanism.

In this article, I want to go over Pasanaku’s development journey so far: the decisions I made, how I built it, what I learned, and, most importantly, what comes next.

If you want to create something similar, whether you need smart contracts or the full stack, please feel free to connect with me on X (@rabuawad_).

But first, let me explain how Pasanaku works. It all started with a much simpler idea.

What Is a Pasanaku?

A pasanaku is a rotating savings pool. A group of people contributes a fixed amount on a schedule, and one participant receives the complete payout during each round.

Traditional pasanakus depend on trust. You know the other participants, and everyone trusts that the people who receive an early payout will continue contributing to the later rounds.

What I wanted to explore was simple: how much of this mechanism could be moved onchain? And, eventually, could a pasanaku work between people who did not know one another?

Core v1: Putting a Trusted Pasanaku Onchain

For the first version, I wanted to build a simple rotating savings mechanism for trusted participants. You had to know the other people in the group, just like in a traditional rotating savings pool.

Even with that trust assumption, Pasanaku let me explore some interesting uses of blockchain technology.

The most interesting one was using ERC-1155 to represent each pasanaku. Every pool had a unique token ID. I liked this because it opened the possibility of making pasanakus composable.

The first version was written in Vyper. It was a simple and efficient smart contract, and it consumed very little gas.

Creating pasanakus was also simple. You created the pool and manually added every participant’s wallet. At launch, only a few currencies were supported: ETH, USDC, and USDT.

Money distribution happened in two steps. Each participant deposited their contribution, and the participant assigned to that round claimed the payout.

The contract used personal custody. It received the contributions and distributed the money, but it did not try to remove the trust assumptions of a traditional rotating savings pool.

That was v1: a minimal and efficient way to put rotating savings onchain.

At the time, I still did not understand how to build a trustless version of Pasanaku. I was also interested in another idea: dynamic NFTs.

Core v1.5: Trusted Pasanaku With Dynamic NFTs

For this intermediate iteration, I ported everything to Solidity with one purpose in mind: adding dynamic, fully onchain metadata to the NFTs.

I wanted to understand what was happening inside each pasanaku simply by looking at its NFT image.

That took me down an interesting path. I developed a custom ERC-1155 onchain descriptor that read the pool’s state and generated the information needed to represent that pasanaku.

The system was still trusted. You still needed to know every participant. The difference was that each NFT now had dynamically generated metadata showing what was happening inside its pool.

I still think onchain metadata is extremely cool and useful. But I realized that, in this case, it did not add enough value to what the protocol already did.

There was a more fundamental problem.

The Problem With the Trusted Model

If you already know and trust every participant, do you really need a smart contract?

You could simply send USDC directly to one another’s wallets without using an intermediary. Putting the process onchain made it more transparent, but it did not solve the hardest problem.

The real question was whether Pasanaku could work between people who did not know or trust one another.

That was when I started thinking about a new version.

Core v2: The Overcollateralization Breakthrough

For v2, I went back to Vyper. I kept ERC-1155 because I still wanted to enable composability between pasanakus in the future, and maybe even a secondary market.

The model started to take shape when I realized that a completely trustless onchain rotating savings pool could work with one simple trick: overcollateralization.

The first iteration of v2 was only an overcollateralized pasanaku. It worked through a factory where users could create pasanakus using supported currencies.

The mechanism was simple:

First, you supplied collateral.
If you had enough collateral, you could join a pasanaku.
Your collateral had to be worth more than the pool’s complete payout.

That was it.

The model worked, but there was nothing particularly special about it yet. It was an overcollateralized pasanaku, and users had little incentive to participate beyond the savings mechanism itself.

So I started working on an improvement.

Making the Collateral Productive

For this iteration, I dropped support for multiple assets and focused on one: USDC. I chose it because it is a widely used and widely available stablecoin.

Then I realized something. Users already had to supply collateral, and that collateral was sitting inside the protocol. It could be doing something.

So I decided to send that collateral to Fluid and make it productive.

That led to what I think is Pasanaku’s most innovative mechanism, and, as far as I know, the only rotating savings pool algorithm designed to work this way in a decentralized system.

The pool not only uses collateral to make participation between strangers possible. It also generates yield from that collateral, creating an additional game-theory incentive for people to participate.

You can read more about the current mechanism on the Pasanaku About page.

A Minimal Protocol

With this version, I think I created something special and useful.

I am planning several updates, but I do not plan to touch the smart contracts. What I wanted from the contract was something minimal and elegant, and I think that is what we have.

Pasanaku is a single smart contract that is also a soulbound ERC-1155. It does what it is supposed to do: create a decentralized, trustless rotating savings pool for people who do not know one another.

That was the idea, and I think the execution was excellent.

The protocol also generates yield from the collateral, giving participants an additional reason to join and remain in the system. I think that is one of the most interesting parts of the architecture.

If you have feedback about Pasanaku’s core architecture, please let me know. I will be more than happy to share my thoughts and hear yours.

Building a Frontend With Character

Something really important, and something that does not get enough attention, especially in the age of AI engineering, is that the landing page and the UI have to be pristine.

The old v1 interface is still online, and, well, I am not really proud of it.

It was built in only a few days with AI. It was not necessarily a flop, but it lacked something. For me, it lacked essence. It did not have anything I could call unique.

I mention this because an almost infinite number of AI-coded apps are reaching the market right now, and many of them feel the same. They look the same. They act the same.

They often have the same bugs and the same missing features. By many definitions of the term, they are AI slop.

The first version of the Pasanaku web app was probably somewhere in that territory. I built it for a hackathon, but I did not want the project to stay there.

I have around 10 years of frontend development experience, and I wanted to put that experience into practice.

For the v2 interface, I created a new design system. I also applied some of the most effective UI patterns available for Web3 applications.

The result is, I think, a genuinely good interface with a unique essence. It is not a shoddy template. It is useful, readable, responsive, and fast. It has achieved a 99% Lighthouse score.

The UI matters because it is how almost every user will experience the protocol. Almost no one is going to interact with Pasanaku directly through the smart contract.

The interface therefore has to make a fairly nuanced protocol feel understandable.

It has to display collateral, current interest rates, available pasanakus, and a user’s active pasanakus. It also has to coordinate all the steps required for each onchain interaction.

When someone creates a pool, the interface shows relevant active pasanakus so they can avoid paying a creation fee when a suitable pool already exists.

All of those pieces come together in an interface that I think is beautiful and, more importantly, useful.

I am grateful that I was able to deliver it in record time. I learned a lot, especially about reading onchain data quickly and reliably.

The frontend has features that you cannot create by simply prompting some code or copying a template. They required specialized knowledge of the protocol, Web3, and frontend development.

I was also able to compress that knowledge into a repository that I think is really clean. That is another part of the project I am proud of.

What Comes Next

Pasanaku is online, and its core protocol is working, but the journey is not finished.

The next updates will focus mainly on the product around the contract: making the experience clearer, improving how people discover and join pools, and continuing to refine the interface.

The smart contract is intentionally minimal. I do not want to add complexity simply for the sake of adding features. The goal is to keep the protocol elegant while making the product around it better.

There are also ideas I would still like to explore, including greater composability between Pasanaku and what a secondary market could eventually look like.

Closing

Building Pasanaku took me from a simple trusted savings pool to a protocol where strangers can save together through overcollateralization and productive collateral.

Every version taught me something. V1 taught me how to represent rotating savings onchain. V1.5 pushed me into dynamic NFTs. V2 forced me to solve the actual trust problem.

The frontend then forced me to make all of that complexity understandable and useful.

I think we now have something minimal, elegant, and genuinely interesting. There is still a lot to improve, and that is exactly what makes the journey exciting.

If you have feedback, want to discuss the architecture, or need help building something similar, from smart contracts to the full stack, please feel free to connect with me on X (@rabuawad_).

Yul Dark Arts: Understanding the EVM from first principles

Rafael Abuawad — Sun, 06 Sep 2026 22:54:04 +0000

In this article, I want to walk you through my experience learning Yul to better understand how the EVM manages memory and how you can use this to your advantage, whether it is for learning more about the EVM or for trying to squeeze extra performance from a smart contract.

What is Yul?

Yul is a type-ish, low-level intermediate representation where EVM opcodes are represented as simple function calls. The idea is to give the developer more control over memory management.

Yul is highly flexible. Since you can use it directly inside Solidity, it has high levels of interoperability with Solidity, and since you are managing the low-level opcodes, it is faster (if you know what you are doing).

Remember, Yul is like an EVM dialect, not a fully fledged programming language. This means that every data type is represented with u256, which includes strings, bools, enums, etc. You are going to do everything manually: storage management, memory management, event emissions, manual abi.encode and abi.encodePacked, and so on.

How do you use Yul?

The easiest way to use Yul is inside a Solidity smart contract, inside an assembly block.

Yul is extremely interesting as a programming language, but it adds a lot of mental overhead. You need to understand this before moving forward. I do not recommend you code all your smart contracts in Yul. The main reason is that you need to pay extreme attention to memory, how to move and manage it. Solidity and Vyper already have tons of abstractions to achieve the same task.

But I would recommend you use Solady if you are coding smart contracts in Solidity.

For basic stuff, Yul, it can be straightforward, as we are going to see shortly. But as soon as the function at hand does more than just reading and modifying a few storage slots, it can get really tricky.

Thinking in terms of slots

In Yul, you stop thinking in variables and start thinking in slots. That shift mattered a lot for me. It changed how I looked at storage, and especially mappings, when writing other smart contracts using Vyper.

Everything in contract storage is just a key-value pair: a slot holds a 32-byte word. You keep a mental map of those slots (and of memory, which is temporary and cheaper). Yes, it is that simple.

Pattern A: Reading a single key

To interact with a single value using Yul, we only need two opcodes, one to read and another to write. These opcodes are sload and sstore respectively. This pattern is the simplest one. You just need a storage slot and a value, and that is it.

For example, let's say we want to read the totalSupply of a super-optimized ERC20 (Solady-style namespaced slot). We would do this:

uint256 private constant _TOTAL_SUPPLY_SLOT = 0x05345cdf77eb68f44c;

function totalSupply() external view returns (uint256 result) {
    assembly {
        result := sload(_TOTAL_SUPPLY_SLOT)
    }
}

Writing is the same idea, just sstore:

function _setTotalSupply(uint256 newSupply) internal {
    assembly {
        sstore(_TOTAL_SUPPLY_SLOT, newSupply)
    }
}

Or, if you are minting and need to bump supply:

function _increaseTotalSupply(uint256 amount) internal {
    assembly {
        let before := sload(_TOTAL_SUPPLY_SLOT)
        sstore(_TOTAL_SUPPLY_SLOT, add(before, amount))
    }
}

Pattern B: Reading a mapping

Inside the EVM bytecode, there is no mapping per se. What there is is a pointer, a hashed key that points to a value. And mappings are no different. So, how do we calculate and use the concept of a mapping in Yul? Certainly, it is the most used data structure in all of EVM development, and the answer is actually really simple.

Instead of storing a slot, we store a slot seed that, in conjunction with the other key in the mapping, will give you the actual slot where the mapping value lives. So, for example, we want to calculate the balanceOf of a given user. We can do the following:

uint256 private constant _BALANCE_SLOT_SEED = 0x87a211a2;

function balanceOf(address owner) external view returns (uint256 result) {
    assembly {
        mstore(0x0c, _BALANCE_SLOT_SEED)
        mstore(0x00, owner)
        let balanceSlot := keccak256(0x0c, 0x20)
        result := sload(balanceSlot)
    }
}

Writing a balance is the same as math; then sstore:

function _setBalance(address owner, uint256 amount) internal {
    assembly {
        mstore(0x0c, _BALANCE_SLOT_SEED)
        mstore(0x00, owner)
        let balanceSlot := keccak256(0x0c, 0x20)
        sstore(balanceSlot, amount)
    }
}

Why `mstore(0x0c, seed)` works

This is the part that confused me the most at first, so let's slow down.

mstore is big-endian. When you write a 32-byte word at some offset, the most significant byte lands at that offset, and the least significant byte lands 31 bytes later. An address is only 20 bytes, so when you mstore(0x00, owner) the address does not sit at 0x00. It sits at mem[0x0c .. 0x1f], after 12 bytes of zero padding.

The Solady overlap trick uses that:

mstore(0x0c, _BALANCE_SLOT_SEED) puts the 4-byte seed at the end of the word starting at 0x0c, which means the seed lands at mem[0x28 .. 0x2b].
mstore(0x00, owner) puts the address at mem[0x0c .. 0x1f].
keccak256(0x0c, 0x20) hashes exactly 32 bytes: [ address 20B | pad 8B | seed 4B ].

That is why you start the hash at 0x0c, not at 0x00. You skip the left padding of the address word and pull the seed into the same 32-byte preimage.

You will also see the packed form, which builds the same preimage with one mstore:

let owner_ := shl(96, owner)
mstore(0x0c, or(owner_, _BALANCE_SLOT_SEED))
let balanceSlot := keccak256(0x0c, 0x20)

Same hash input. Fewer stores. This is not the same thing as cleaning an address (more on that later).

Pattern C: Reading a mapping of a mapping

This pattern is also used a lot, in places like allowances:

uint256 private constant _ALLOWANCE_SLOT_SEED = 0x7f5e9f20;

function allowance(address owner, address spender) external view returns (uint256 result) {
    assembly {
        mstore(0x20, spender)
        mstore(0x0c, _ALLOWANCE_SLOT_SEED)
        mstore(0x00, owner)
        let allowanceSlot := keccak256(0x0c, 0x34)
        result := sload(allowanceSlot)
    }
}

Notice the hash length is 0x34 (52 bytes), not 0x20. You are hashing owner + seed + spender layout across more than one word. Writing is again the same slot, then sstore(allowanceSlot, amount).

The seed pattern

This is pretty self-explanatory. We use a seed in conjunction with the other values we want to use as a key, then hash them together to generate the actual key we want to use to store the specific value. Solady uses namespaced seeds like _BALANCE_SLOT_SEED instead of compiler slots 0, 1, 2... so inherited contracts do not collide on storage.

Managing memory

In libraries like Solady, you are going to see a lot of use of scratch space. Slots 0x00 up to 0x3f are scratch memory, and you can essentially do whatever you want with them. You are mostly going to use memory to store values to calculate given slots, or to store (in memory) cleaned-up addresses. That is exactly why Patterns B and C hash in scratch: no free-memory allocation, just trash the first 64 bytes, hash, sload/sstore, done.

The free memory pointer lives at 0x40. If you need real allocated memory (dynamic returns, bigger ABI payloads, building structs in memory), you read it first with mload(0x40), write from that pointer, then bump it so the next allocation does not overwrite you.
The zero slot lives at 0x60. It is not recommended to write the zero slot, but if you ever need to do so, you have to set this slot back to 0. Solidity assumes that word stays zero.

So the mental map is:

0x00 to 0x3f: scratch, safe to trash for hashing and temps (in carefully scoped assembly)
0x40: free memory pointer
0x60: zero slot, put it back if you touch it

Footgun: cleaning addresses vs packing them

Two patterns look similar and are not the same.

Cleaning forces the upper 12 bytes of an address word to zero before you compare it or emit it as a topic:

owner := shr(96, shl(96, owner))

If you skip this and some upper bits are dirty, eq can fail against a clean address, or you can emit a weird topic that indexers will not match.

Packing shifts the address left and ors it with a seed so one mstore builds the balance-slot preimage:

mstore(0x0c, or(shl(96, from), _BALANCE_SLOT_SEED))

Cleaning is about the correctness of the address as an address. Packing is about building a storage key cheaply. Do not unify them in your head. I did. It bites.

Events

Since in Yul you are using plain EVM opcodes as functions, we need to compute the event signature and pass the parameters accordingly. If you don't know how events work under the hood, there is an amazing guide by RareSkills explaining how events work: Solidity Events by RareSkills.

For this article, we need to understand one thing: events can have up to 4 indexed topics, and topics are, in and of themselves, the data that the event is logging. The name of the event (its signature hash) is also considered a topic. An event can have a maximum of 3 indexed topics plus the signature topic. Essentially, we have to call the correct opcode. The opcodes to emit events are log0 through log4.

Emitting a Transfer event in Solidity

event Transfer(address indexed from, address indexed to, uint256 amount);

// Inside a function.
emit Transfer(from, to, amount);

Emitting a Transfer event in Solidity + Yul

uint256 private constant _TRANSFER_EVENT_SIGNATURE =
0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef;

function _emitTransfer(address from, address to, uint256 amount) internal {
    assembly {
        mstore(0x20, amount)
        log3(0x20, 0x20, _TRANSFER_EVENT_SIGNATURE, from, to)
    }
}

log3 means: signature topic + 2 indexed topics (from, to), and amount lives in the non-indexed data payload. Same fingerprint idea as seeds: compute the event hash once, never keccak the string at runtime.

To compute the event signature, you can do the following operation in chisel or cast:

`keccak256(bytes("Transfer(address,address,uint256)"))`

Custom errors

Custom errors in Yul follow a similar idea to events. You precompute the error selector (the first 4 bytes of keccak256("ErrorName()")), store it in memory, then revert with the right offset and size.

// InsufficientBalance() selector = 0xf4d678b8
function _revertInsufficientBalance() internal pure {
    assembly {
        mstore(0x00, 0xf4d678b8)
        revert(0x1c, 0x04)
    }
}

Why revert(0x1c, 0x04)? Because mstore is big-endian again. A 4-byte selector written as a small integer lands at the end of the 32-byte word (mem[0x1c .. 0x1f]). Offset 0x1c with length 0x04 returns exactly those four bytes. No ABI fluff.

If the error has arguments, you mstore them after the selector and increase the revert size accordingly. Same mental model: fingerprint once, then speak in opcodes.

Precompute

Something I learned is that many values can be precomputed using chisel or cast to save on compute. Solady does this a lot to squeeze the last drop of efficiency, making Solady's ERC20, for example, one of the cheapest ERC20s to interact with.
Selectors, event signatures, slot seeds, bitmasks: if it never changes at runtime, do not compute them at runtime.

# event topic0
cast keccak "Transfer(address,address,uint256)"

# error selector (first 4 bytes)
cast sig "InsufficientBalance()"

Paste the result as a uint256 private constant and you are done.

Final thoughts

Just to be clear, I don't think you should be writing Yul for smart contracts as your default. The whole point of this article is also the reason not to live there: you have to keep a mental map of how memory works, slots, scratch, free memory pointer, and dirty bits.

That overhead is real.

I have a lot of respect for the people behind many of the top protocols and libraries that squeeze the last drop of performance from their smart contracts using Yul, such as Solady and OpenSea, just to name a few. Learning to read that code is still worth it.
If you want to learn from a true expert, I recommend you watch this video.

In my opinion, Solidity should improve the language; they are targeting that with Core Solidity, and I hope it goes well. The generated opcodes should be as efficient as possible, so developers are not forced into assembly for performance. Vyper has this right, and the resulting opcode is really good and well optimized. The high-level language does more of the hard work for you.

Still, I don't think hand-rolled Yul is the way forward for writing regular smart contracts. That doesn't mean you can't become an expert in Yul, and Understanding Yul is a really good way to understand the EVM.

Staking rewards are just an accumulator (Vyper 🐍)

Rafael Abuawad — Wed, 02 Sep 2026 16:13:32 +0000

Staking rewards look complicated. They are not.

I went through a pile of articles on staking, and the mechanism is simpler than I expected. If you are going to ship a staking pool, you need to understand this model.

The naive way

First thought: an offchain bot that pays everyone every block.

@bot.on_(chain.blocks)
def distribute_rewards(block):
    for staker in stakers:
        token.transfer(staker, calculate_rewards_amount(staker))

Silverback can do this. It even looks clean.

You will hit two walls. Gas: looping every staker every block is expensive. Liveness: if the bot goes down, stakers earn less than they were promised.

There is a simpler way, and it lives onchain.

Lazy accounting

Lazy accounting means you do not push rewards every second. You keep a running index of how much one staked token is owed, and you only settle a user when they touch the pool.

The index is a counter that only goes up, from the start of the period to the end. From that one number you get two others: how much the user is owed, and a checkpoint (often called debt) of the index at the moment they staked.

You are storing how much a single staked token would have earned since the beginning. Not everyone has been in since the beginning, so you also store each staker's checkpoint.

Example. Rewards started at block 0. Bob deposits 100 tokens at block 10. The index is already 5. If you only stored reward_per_token_staked, the contract would show Bob owed 500 for a stake he just opened. He is owed 0.

So you store reward_per_token_stored_paid for Bob, and you subtract it later. He does not get paid for time he was not in.

That is the MasterChef idea, and it is small once you see it: track what one token has accrued since t=0, then store an offset per user because not everyone started at t=0. That offset is the reward debt.

Every time someone interacts (stake, unstake, harvest), you update the index first. No active staker is cheated for time they were in. Time with zero stake isn't paid to the next depositor, and you don't pay the whole set every block.

In this guide we implement it in Vyper, mostly from Unipool and the Synthetix staking rewards pattern. MasterChef and Unipool are not the same contract. I will mark where they split.

Setup

I am using Moccasin, a Vyper-first framework built on top of Titanoboa. This repo's tests and invariants live under tests/ (unitary, integration, fuzz) — steal that pattern for your own protocol rather than inlining it here.

Installing Moccasin

Python 3.11+ and uv. Install Moccasin as a global tool:

curl -LsSf https://astral.sh/uv/install.sh | sh
uv tool install moccasin
mox --version

mox is the CLI. If it is missing, restart the terminal (or source ~/.bashrc) after installing uv.

Project setup

mox init staking-rewards
cd staking-rewards

You get src/, tests/, script/, and moccasin.toml. Put the contract in src/StakingRewards.vy. This guide targets Vyper 0.4.3:

uv add moccasin
uv add "vyper==0.4.3"

Staking Rewards

Vyper 0.4.3, with the compiler flag that puts a contract-wide reentrancy lock on external functions (this is also the 0.4 default).

# pragma version ==0.4.3
# pragma nonreentrancy on

Two immutables: the token users stake, and the token you pay as rewards.

In MasterChef, users stake LP tokens and the contract mints a separate reward token. In Unipool you transfer a pre-funded reward token, so the contract must already hold enough for the whole period. In this Unipool-style contract the two tokens must be different, otherwise harvest can pay out other people's deposits.

# @dev We import the built-in IERC20 interface.
from ethereum.ercs import IERC20

# @dev Immutable staking token set at deploy.
staking_token: public(immutable(IERC20))

# @dev Immutable rewards token set at deploy.
rewards_token: public(immutable(IERC20))

Track how much staking_token is in the pool, and how much each staker put in.

# @dev The total amount of staking_token staked.
total_supply: uint256

# @dev The amount that each individual staker
# has staked.
balances: HashMap[address, uint256]

Then the index, the reward rate, and the timestamps. period_finish and reward_rate are Unipool-specific, and immutables here because this implementation never changes them after deploy. We store how much each staked token has accrued, tokens per second for the whole pool, when the period ends, and the last time the pool was updated. Remember: we only update on deposit, withdraw, and harvest.

Unipool keeps rewards separate. The user has to harvest to receive them. MasterChef pays on interaction: stake (if they already had a stake) or withdraw.

# @dev We store when the staking rewards period is going to end.
#      Since there is no way to update this in this implementation we
#      are going to store this as an immutable.
period_finish: public(immutable(uint256))

# @dev Reward tokens distributed per second across the whole pool.
#      Since there is no way to update this in this implementation we
#      are going to store this as an immutable.
reward_rate: public(immutable(uint256))

# @dev We store the last time someone interacted with the pool.
last_update_time: public(uint256)

# @dev We store how much each individual staked token has earned in rewards
reward_per_token_stored: public(uint256)

Per staker: the last index they were paid against, and rewards already owed but not harvested.

If they harvested when reward_per_token_stored was 3, and it is 7 now, those first 3 are done. rewards is the snapshot of unclaimed earnings, so a later deposit or withdraw does not drop them if they have not harvested yet.

# @dev Personal mark that each staker is going to have,
#      tracks what was the last `reward_per_token_stored`
#      that the user got paid
reward_per_token_stored_paid: public(HashMap[address, uint256])

# @dev Tracks how much rewards a user is owed.
rewards: public(HashMap[address, uint256])

This contract only pays for 9 days:

# @dev Duration in seconds. 9 days.
DURATION: constant(uint256) = 777600

And a WAD scale for the accumulator. This is Q-notation precision for reward_per_token_stored, not the token decimals.

# @dev Accumulator scale (1 WAD). This is Q-notation precision for
#      reward_per_token_stored, not the staking or rewards token decimals.
PRECISION: constant(uint256) = 10**18

Set period_finish, reward_rate, and last_update_time in the constructor. Assert that the two tokens are different.

@deploy
def __init__(
  _staking_token: IERC20,
  _rewards_token: IERC20,
  _reward_rate: uint256
):
  assert _staking_token != _rewards_token  # dev: staking and rewards tokens must differ
  staking_token = _staking_token
  rewards_token = _rewards_token
  period_finish = block.timestamp + DURATION
  reward_rate = _reward_rate
  self.last_update_time = block.timestamp

From this contract's point of view, rewards run from deployment until 9 days later.

Events you actually want in a production pool:

# @dev Emitted when a user stakes tokens.
event Staked:
  user: indexed(address)
  amount: uint256

# @dev Emitted when a user withdraws staked tokens.
event Withdrawn:
  user: indexed(address)
  amount: uint256

# @dev Emitted when a user harvests staking rewards.
event RewardPaid:
  user: indexed(address)
  reward: uint256

The index

The key function is _reward_per_token(). It answers one question: how much has a single staked token earned?

The formula is the same shape in Unipool and MasterChef. Unipool counts seconds. MasterChef counts blocks.

@internal
@view
def _reward_per_token() -> uint256:
  if self.total_supply == 0:
    return self.reward_per_token_stored

  return self.reward_per_token_stored + ((self._last_time_reward_applicable() - self.last_update_time) * reward_rate * PRECISION) // self.total_supply

If total_supply is 0, skip the accumulator. Nobody is there to credit, so that interval's rewards stay in the contract instead of going to whoever deposits next.

Otherwise add (time_delta * reward_rate * PRECISION) / total_supply to the stored index. Dilution is automatic: more stake in the pool, slower the index moves.

_last_time_reward_applicable is just min(block.timestamp, period_finish).

@internal
@view
def _last_time_reward_applicable() -> uint256:
  return min(block.timestamp, period_finish)

With those two, you can compute unclaimed rewards for any staker:

@internal
@view
def _earned(account: address) -> uint256:
  return self.balances[account] * (self._reward_per_token() - self.reward_per_token_stored_paid[account]) // PRECISION + self.rewards[account]

Then the function everything else hangs on: _update_pool.

@internal
def _update_pool(account: address):
  self.reward_per_token_stored = self._reward_per_token()
  self.last_update_time = self._last_time_reward_applicable()
  if account != empty(address):
    self.rewards[account] = self._earned(account)
    self.reward_per_token_stored_paid[account] = self.reward_per_token_stored

Call this before anything else, on every deposit, withdraw, and harvest. You settle the user against the current index before you change balances.

Line 1 moves the global index forward: how much one token has earned since the start.

Line 2 caps time at period_finish, so you stop accruing after the window.

If the account is not the zero address, you snapshot what they are owed into rewards, then move their paid checkpoint up to the current index so the next delta does not double-count.

Pool interactions

Once _update_pool, _earned, and the index are right, that is the staking algorithm. The external functions are just the doors.

Deposit:

@external
def deposit(amount: uint256):
  assert amount > 0 # dev: invalid deposit amount
  self._update_pool(msg.sender)
  self.total_supply += amount
  self.balances[msg.sender] += amount
  extcall staking_token.transferFrom(msg.sender, self, amount)
  log Staked(user=msg.sender, amount=amount)

Zero amount reverts. Then update the pool before any balance change. Then bump total_supply and the user's balance, transfer in (CEI), and emit Staked.

Withdraw:

@external
def withdraw(amount: uint256):
  assert amount > 0 # dev: invalid withdraw amount
  self._update_pool(msg.sender)
  self.total_supply -= amount
  self.balances[msg.sender] -= amount
  extcall staking_token.transfer(msg.sender, amount)
  log Withdrawn(user=msg.sender, amount=amount)

Same order: check, update pool, then accounting, then transfer out. Vyper reverts on underflow, so you do not need a separate "enough stake" check. Notice we do not send rewards here. That is harvest.

Harvest:

@external
def harvest():
  self._update_pool(msg.sender)
  earned: uint256 = self._earned(msg.sender)
  if earned > 0:
    self.rewards[msg.sender] = 0
    extcall rewards_token.transfer(msg.sender, earned)
    log RewardPaid(user=msg.sender, reward=earned)

Update the pool first so earned is current. If earned is 0, do nothing (no event). Else zero rewards, then transfer (CEI).

You could add exit() that withdraws and harvests in one call. If you want to write it, go for it.

Extra views

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

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

@external
@view
def last_time_reward_applicable() -> uint256:
    return self._last_time_reward_applicable()

@external
@view
def reward_per_token() -> uint256:
    return self._reward_per_token()

@external
@view
def earned(account: address) -> uint256:
    return self._earned(account)

Final notes

A few things you should not skip:

Be honest about funding. The pool has to hold enough rewards_token for the whole period. If it does not, harvest reverts, and that is a broken product, not a gas trick.
This is Unipool, by k06a, not MasterChef. Read the original if you want the smallest version of the idea.
Do the math once on paper. The RareSkills staking algorithm post is the cleanest path to this formula. Useful if you care about algorithmic thinking, not just copying the contract.

Don't only ship the pool. Understand the index.

StakingRewards source and tests

DEV Community: Rafael Abuawad

How to Implement the ERC-165 in Vyper

Polymarket and the oracle problem

What is an Oracle?

Polymarket and Bias

How to create your own cryptocurrency using Vyper and Python

What is a Cryptocurrency? What is an ERC20?

Setup

Developing our Cryptocurrency

Pragma

Implementing totalSupply and Immutables

Implementing balanceOf

Implementing transfer

Delegating Power: approve and transferFrom

Events: The Final Touch

Optimizations: Saving Gas with immutable

Why use immutable?

The Optimized Code

When to use it?

Key points of this implementation:

Full Code (Vyper 0.4.3)

Python Script: Blockchain Deployment

1. Script Setup

2. Security First: The Keystore

3. The Deployment Code

4. Launching the Token

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

Hackathons have changed completely.

Grants have disappeared.

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

Liquidity is going to concentrate.

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

An account is not a wallet

Self-custody is great

About Sandia

Web3 Security: How to Protect Your Private Key using Python

Project Setup

The Code: Keystore Manager

Key Security Points

Usage

Onchain experiments, and why we need them

Rethinking Web3 Development

What Do I Mean by Web3 Thinking?

Example 1: User Login and Profiles

Example 2: Building a Betting Application

Why Are Devs Missing This?

The Bigger Issue: Devs Not Eating Their Own Medicine

Web3: The "Ghost Chains" Problem and the Token Bubble

1. The Problem: Multi-million Dollar Solutions for Non-existent Problems

2. The Solution: Apps > Infrastructure

3. The Token Paradox: Towards "Desensitization"

Building Pasanaku: From Trusted to Trustless

What Is a Pasanaku?

Core v1: Putting a Trusted Pasanaku Onchain

Core v1.5: Trusted Pasanaku With Dynamic NFTs

The Problem With the Trusted Model

Core v2: The Overcollateralization Breakthrough

Making the Collateral Productive

A Minimal Protocol

Building a Frontend With Character

What Comes Next

Closing

Yul Dark Arts: Understanding the EVM from first principles

What is Yul?

How do you use Yul?

Thinking in terms of slots

Pattern A: Reading a single key

Pattern B: Reading a mapping

Why mstore(0x0c, seed) works

Pattern C: Reading a mapping of a mapping

The seed pattern

Managing memory

Events

Emitting a Transfer event in Solidity

Custom errors

Precompute

Final thoughts

Staking rewards are just an accumulator (Vyper 🐍)

The naive way

Lazy accounting

Implementing `totalSupply` and Immutables

Implementing `transfer`

Delegating Power: `approve` and `transferFrom`

Why `mstore(0x0c, seed)` works