DEV Community: Rafael Abuawad

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

Create your own Uniswap DeFi Application🦄! From scratch using Vyper & Python🐍

Rafael Abuawad — Fri, 08 Dec 2023 15:45:42 +0000

Introduction

DeFi, short for Decentralized Finance, is a prominent use case for blockchain technology. Among the many protocols that exist, Uniswap was one of the earliest to implement the automatic market maker (AMM) model and remains one of the most widely used solutions to date.

To develop our solution, we have chosen to use Vyper. This is because it offers clear readability, built-in security features, and optimization capabilities right out of the box. By leveraging Vyper, we aim to enhance the overall quality and reliability of our code.

What is an AMM?

Automated market makers (AMMs) are part of the decentralized finance (Defi) ecosystem. They allow digital assets to be traded in a permissionless and automatic way by using liquidity pools rather than a traditional market of buyers and sellers. AMM users supply liquidity pools with crypto tokens, whose prices are determined by a constant mathematical formula. Liquidity pools can be optimized for different purposes, and are proving to be an important instrument in the Defi ecosystem. In this tutorial, we are going to use a constant-product AMM.

Setup project

For this particular project, we have decided to use ApeWorx, a novel framework for smart contract development that utilizes Python. We chose ApeWorx for its simplicity, ease of use, and powerful capabilities. Additionally, the framework supports plugins, allowing us to extend its functionality and enhance our development process even further.

By leveraging ApeWorx, we aim to streamline our smart contract development workflow, improve the readability of our code, and maximize the efficiency of our development efforts. We believe that ApeWorx's advanced features and flexibility will allow us to build high-quality smart contracts that meet our specific needs and requirements.

To begin using ApeWorx for this project, you will need to have Python installed along with a virtual environment. You can set up these prerequisites by following the links provided.

If you are new to this process, do not be intimidated. The setup process is simple, and we are confident that you will be able to get started quickly. With the necessary tools in place, we can begin leveraging ApeWorx's powerful features to build robust and reliable smart contracts.

To start creating our project, we first need to create a new folder called uviswap and navigate to it using the terminal:

$ mkdir uviswap
$ cd ./uviswap

Now we need to create a Python Virtual Enviroment, this is to keep our dependencies isolated from other packages. And we install our packages, in this case, we just need to install ApeWorx.

$ python3 -m venv .venv
$ source .venv/bin/activate
$ pip install eth-ape

Next, we will initialize a new ApeWorx project and name it uviswap:

$ ape init
$ Please enter project name: uviswap

🚧 If you encounter the issue of No module named 'pkg_resources', you need to run pip install setuptools to fix it.

Finally, we need to install Vyper as a plugin so that we can work with it using ApeWorx. Fortunately, the process is straightforward to understand, and can be accomplished using a single command:

$ ape plugins install vyper

Great! With our project now set up, we can move on to implementing the smart contracts.

Smart contract development

For this DeFi application, we will define two smart contracts: the Pair and the Factory.

The Pair contract is the heart of our automated market maker project and will be responsible for holding a pair of tokens.
The Factory contract will be responsible for creating new pairs using new tokens or returning the address of a pair if it already exists.

Together, these contracts will form the backbone of our DeFi application and allow us to implement our automated market-maker model.

UviswapPair

To begin implementing the Pair contract, we will create a new file named UviswapPair.vy in the contracts/ directory. We will specify the Vyper version as ^0.3.10 and import the ERC20 and ERC20 Detailed interfaces from Vyper.

This boilerplate code will provide us with the basic foundation for developing our Pair contract.

# pragma version ^0.3.10

from vyper.interfaces import ERC20
from vyper.interfaces import ERC20Detailed

implements: ERC20
implements: ERC20Detailed

This is our basic boilerplate, we need the ERC20 definition to allow our users to use their shares however they want.

# pragma version ^0.3.10

from vyper.interfaces import ERC20
from vyper.interfaces import ERC20Detailed

###### EVENTS ######

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

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

###### STATE ######

# Share token name
name: public(String[32])

# Share token symbol
symbol: public(String[32])

# Share token decimals
decimals: public(uint8)

# By declaring `balanceOf` as public, vyper automatically generates a 'balanceOf()' getter
# method to allow access to account balances.
balanceOf: public(HashMap[address, uint256])

# By declaring `allowance` as public, vyper automatically generates the `allowance()` getter
allowance: public(HashMap[address, HashMap[address, uint256]])

# By declaring `totalSupply` as public, we automatically create the `totalSupply()` getter
totalSupply: public(uint256)

###### CONSTRUCTOR ######
@external
def __init__():
    self.name = "Uviswap"
    self.symbol = "UVI"
    self.decimals = 18


###### INTERNAL METHODS ######
@internal
def _mint(_to: address, _value: uint256):
    assert _to != empty(address), "ERC20: mint to the zero address"
    self.balanceOf[_to] += _value
    self.totalSupply += _value
    log Transfer(empty(address), _to, _value)


@internal
def _burn(_to: address, _value: uint256):
    assert _to != empty(address), "ERC20: burn to the zero address"
    self.balanceOf[_to] -= _value
    self.totalSupply -= _value
    log Transfer(_to, empty(address), _value)


###### EXTERNAL METHODS ######
@external
def transfer(_to : address, _value : uint256) -> bool:
    assert _to != empty(address), "ERC20: transfer to the zero address"

    self.balanceOf[msg.sender] -= _value
    self.balanceOf[_to] += _value
    log Transfer(msg.sender, _to, _value)
    return True


@external
def transferFrom(_from : address, _to : address, _value : uint256) -> bool:
    self.allowance[_from][msg.sender] -= _value
    self.balanceOf[_from] -= _value
    self.balanceOf[_to] += _value

    log Transfer(_from, _to, _value)
    return True


@external
def approve(_spender : address, _value : uint256) -> bool:
    self.allowance[msg.sender][_spender] = _value
    log Approval(msg.sender, _spender, _value)
    return True


@external
def burn(_value: uint256):
    self._burn(msg.sender, _value)

This code is the implementation of the Uviswap Pair smart contract, which represents a liquidity pool that holds two tokens. The Pair contract is written in Vype and uses two ERC20 interfaces - ERC20 and ERC20Detailed - to define the basic functionality and properties of a token.

The code defines the following state variables:

name: the name of the share token
symbol: the symbol of the share token
decimals: the number of decimal places for the share token
balanceOf: a mapping of addresses to their token balances
allowance: a mapping of addresses to their approved spending limits
totalSupply: the total number of tokens in circulation

The constructor sets the initial values for the name, symbol, and decimal state variables.

The code also defines several internal and external methods:

_mint: an internal method used to mint new tokens and update the balances of the token holder and the total supply
_burn: an internal method used to burn existing tokens and update the balances of the token holder and the total supply
transfer: an external method used to transfer tokens between accounts and update their balances
transferFrom: an external method used to transfer tokens between accounts with the approval of the token holder and update their balances
approve: an external method used to approve a third-party spender to use the tokens on behalf of the token holder
burn: an external method used to burn tokens from the caller's account and update their balance

Finally, the code defines two events, Transfer and Approval, that are emitted when tokens are transferred or approved for spending. The smart contract is divided on:

EVENTS
STATE
INTERNAL METHODS
EXTERNAL METHODS

🐍⚠️ This part is important since we are going to jump between those. So take note so you don't get lost.

In addition to the ERC20 functionality, we need to add some state variables to our smart contract to implement the AMM functionality. These state variables include the two tokens in the pair and the corresponding reserves for each token. We will also define the invariant constant k, which is the product of the two reserves and is constant in a balanced pair:

###### STATE ######
...

# Tokens in the pair
token0: public(address)
token1: public(address)

# Reserves for each token
reserve0: public(uint256)
reserve1: public(uint256)

...

To enable our pool to track the tokens it handles and the amount of reserves available for each token, we need to add the token variables and reserve variables to our smart contract. These variables will be used to keep track of the balances for each token and the amount of liquidity in the pool.

We also need to create an internal update method to keep track of the reserves each time we add or remove liquidity. This method will be called internally every time liquidity is added or removed from the pool and will update the reserves accordingly.

###### INTERNAL METHODS ######
...

@internal
def _update(_reserve0: uint256, _reserve1: uint256):
    self.reserve0 = _reserve0
    self.reserve1 = _reserve1

...

To set up the Pair, we need to add a setup function that initializes the tokens and reserves. To ensure that it can only be called once, we'll add a flag variable that will be set to true once the setup is complete. This function will be called by the Factory when a new Pair is created.

###### STATE ######
...

# Setup flag
_setup: bool

...

Since the method will be called from the outside we need to define it in the external methods section.

###### EXTERNAL METHODS ######
...

@external
def setup(_token0: address, _token1: address):
    assert self._setup == False, "Uviswap Pair: already initialized"
    self.token0 = _token0
    self.token1 = _token1
    self._setup = True

...

Add liquidity

The addLiquidity method is responsible for allowing users to deposit tokens into our smart contract, which is necessary for the AMM to function. When a user deposits tokens, the smart contract mints some share tokens in return. These share tokens can be redeemed later along with some collected fees resulting from other users swapping tokens with this liquidity.

To prevent bad actors from exploiting this functionality, we added a reentrancy guard.

###### EXTERNAL METHODS ######
...

@external
@nonreentrant("add")
def addLiquidity(_amount0: uint256, _amount1: uint256) -> uint256:
    # add liquidity
    ERC20(self.token0).transferFrom(msg.sender, self, _amount0)
    ERC20(self.token1).transferFrom(msg.sender, self, _amount1)

    # keep the pool balanced (k=x*y)
    if self.reserve0 > 0 or self.reserve1 > 0:
        assert self.reserve0 * _amount1 == self.reserve1 * _amount0, "Uviswap Pair: x / y != dx / dy" 

    shares: uint256 = 0
    if self.totalSupply == 0:
        shares = isqrt(_amount0 * _amount1)
    else:
        shares = min(
            (_amount0 * self.totalSupply) * self.reserve0,
            (_amount1 * self.totalSupply) * self.reserve1
        )

    assert shares > 0, "Uviswap Pair: shares were zero"

    # mint shares to liquidity provider
    self._mint(msg.sender, shares)

    # update reserves
    self._update(ERC20(self.token0).balanceOf(self), ERC20(self.token1).balanceOf(self))

    return shares

...

This code is defining the addLiquidity in Vyper.

The @external decorator indicates that this function can be called externally. The @nonreentrant("add") decorator prevents reentrancy attacks on the function.

When a user calls this function, they must pass in two arguments _amount0 and _amount1, which represent the amount of token0 and token1 they want to add to the liquidity pool.

First, the function transfers _amount0 and _amount1 from the sender to the smart contract using the transferFrom method of the ERC20 token contract.

Next, the function checks if the reserves of token0 and token1 are greater than 0. If they are, it verifies that the new reserves maintain the constant product (k=x*y), which is necessary for the AMM to function properly. If the new reserves do not maintain this constant product, an assertion error is raised.

The function then calculates the amount of shares to mint for the liquidity provider, based on the amount of tokens they deposited, the current reserves, and the total supply of shares already in circulation. If this is the first liquidity deposit, the function sets the initial shares based on the square root of the product of the deposited token amounts.

If the calculation of shares results in a value of 0, an assertion error is raised.

The function then mints the calculated amount of shares to the liquidity provider and updates the reserves using the _update method and the function returns the amount of shares minted to the liquidity provider.

Remove liquidity

To remove liquidity from the pool, the user needs to call the removeLiquidity function, passing the number of shares to burn. In exchange for burning the shares, the user will receive a proportional amount of the tokens that were originally deposited into the pool.

The code for the removeLiquidity function is as follows:

###### EXTERNAL METHODS ######
...

@external
@nonreentrant("remove")
def removeLiquidity(_shares: uint256) -> (uint256, uint256):
    _token0: ERC20 = ERC20(self.token0)
    _token1: ERC20 = ERC20(self.token1)

    bal0: uint256 = _token0.balanceOf(self)
    bal1: uint256 = _token1.balanceOf(self)

    amount0: uint256 = (_shares * bal0) / self.totalSupply
    amount1: uint256 = (_shares * bal1) / self.totalSupply

    # _burn checks if the user has enough shares
    self._burn(msg.sender, _shares)
    # update reserves
    self._update(bal0 - amount0, bal1 - amount1)

    # transfers the tokens back
    _token0.transfer(msg.sender, amount0)
    _token1.transfer(msg.sender, amount1)

    return (amount0, amount1)

...

First, the function calculates the proportional amounts of each token based on the number of shares being burned. It then burns the shares that the user passed in and transfers the proportional amounts of each token back to the user. Finally, it updates the reserves to reflect the removed liquidity.

As with the addLiquidity function, a reentrancy guard has been added to prevent reentrancy attacks.

Swap

The swap function is a critical feature of any automated market maker. In this function, a user provides a token and an amount, and based on these inputs, we return the opposite token of the pair along with the corresponding amount. In the process, we charge a small fee to compensate our liquidity providers.

To protect against malicious actors exploiting this feature, we have added a reentrancy guard.

###### EXTERNAL METHODS ######
...

@external
@nonreentrant("swap")
def swap(_tokenIn: address, _amountIn: uint256) -> uint256:
    assert _tokenIn == self.token0 or _tokenIn == self.token1, "Uviswap Pair: invalid token"
    assert _amountIn > 0, "Uviswap Pair: amount in is zero"

    # variables to interact with the liquidity pool
    tokenIn: ERC20 = empty(ERC20)
    tokenOut: ERC20 = empty(ERC20)
    reserveIn: uint256 = 0
    reserveOut: uint256 = 0

    # determine which token is being swapped in
    # and assigning variables accordingly
    isToken0: bool = _tokenIn == self.token0
    if isToken0:
        tokenIn = ERC20(self.token0)
        tokenOut = ERC20(self.token1)
        reserveIn = self.reserve0
        reserveOut = self.reserve1
    else:
        tokenIn = ERC20(self.token1)
        tokenOut = ERC20(self.token0)
        reserveIn = self.reserve1
        reserveOut = self.reserve0

    # transfer in the tokens
    tokenIn.transferFrom(msg.sender, self, _amountIn)

    # 0.3% fee
    amountInWithFee: uint256 = (_amountIn * 997) / 1000

    # calculate tokens to transfer
    amountOut: uint256 = (reserveOut * amountInWithFee) / (reserveIn + amountInWithFee)
    tokenOut.transfer(msg.sender, amountOut)

    # update reserves
    self._update(ERC20(self.token0).balanceOf(self), ERC20(self.token1).balanceOf(self))

    # transfer in the tokens
    return amountOut

...

The function allows a user to swap a given token for its counterpart in the pair by calling the method with the token address and the amount to be swapped.

The function first checks whether the token being swapped is one of the tokens in the pair, and whether the amount being swapped is greater than zero. If either of these conditions fails, the function will not execute.

Next, determines which token in the pair is being swapped in, and assigns variables accordingly. It then transfers the input token from the user to the contract.

Then calculates the fee for the swap, which is 0.3% of the input amount, and calculates the corresponding amount of the output token to transfer back to the user based on the current reserves in the pool.

Finally, it transfers the output tokens to the user, updates the reserves, and returns the amount of output tokens transferred.

🦄 You can find the complete UviswapPair smart-contract here.

UviswapFactory

To begin implementing the Factory contract, we will create a new file named UviswapFactory.vy in the contracts directory and specify the Vyper version as 0.3.10. This smart contract will be responsible for creating liquidity pools that use two tokens that can be provided by users.

The code for our initial implementation should look something like this:

# pragma version ^0.3.10

###### INTERFACES ######

###### STATE ######

###### CONSTRUCTOR ######

###### METHODS ######

The following code block defines an interface for the UviswapPair smart contract. This interface only includes one method, setup, which we will use to create a new liquidity pool.

...
###### INTERFACES ######

interface UviswapPair:
    def setup(_token0: address, _token1: address): nonpayable

...

This interface declares the method signature for the setup function that takes two parameters, _token0 and _token1 of type address, representing the two tokens that will be used in the liquidity pool. The nonpayable modifier ensures that this method does not accept any Ether as payment.

Next, we'll declare the state of the smart contract. We need to map the token pairs that we have created and add an array to store each one of them. Additionally, we need to declare a master pair contract address, which will be used as a blueprint by Vyper to create and deploy new pair smart contracts.

Here's the code:

###### STATE ######
...

# Pair Contract => Token <=> Token
getPair: public(HashMap[address, HashMap[address, address]])

# All pairs list
allPairs: public(DynArray[address, 30])

# Uviswap Pair contract address used to create clones of it
pairContract: address

...

After declaring the state variables, we can define the constructor function. This function is important because it allows us to pass the address of an empty pair smart contract that we must deploy before we deploy this one.

###### CONSTRUCTOR ######
...

@external
def __init__(_pairContract: address):
    self.pairContract = _pairContract

...

That would be everything we need before defining the main createPair method, which will allow our users to create a token pair freely.

Create pair

The create pair method is simple, we pass in two tokens, token A and token B., with these two tokens we deploy a new pair smart contract (using the pairContract state variable we defined in the constructor) and we add to the pairs mapping and the pairs array, and that's it!

###### METHODS ######
...

@external
def createPair(_tokenA: address, _tokenB: address) -> address:
    assert _tokenA != _tokenB, "Uviswap Factory: identical addresses"
    assert _tokenA != empty(address) and _tokenB != empty(address), "Uviswap Factory: zero address"
    assert self.getPair[_tokenA][_tokenB] == empty(address),  "Uviswap Factory: pair exists"

    # create pair smart contract
    pair: address = create_forwarder_to(self.pairContract)
    UviswapPair(pair).setup(_tokenA, _tokenB)

    # populate mapping in, and in the reverse direction
    self.getPair[_tokenA][_tokenB] = pair
    self.getPair[_tokenB][_tokenA] = pair

    # append pair to all pairs array
    self.allPairs.append(pair)

    return pair

...

🦄 You can find the complete Uviswap Factory smart-contract here.

Testing

Now, we need to cover the testing section, which is a crucial part of our application. In this section, we will cover the basics of token swaps and liquidity addition. To begin with, we need to deploy mock smart contracts for testing, and for that, we will use Vyper's official example.

🚧 To do this, we need to create a mocks/ folder inside the contracts/ folder, and within it, create an Token.vy file. You can add the code from the following link to this file: Vyper ERC20 Token.

🐍⚠️ It is important to note that while the current testing strategy covers the basics, it is not sufficient for production. It is recommended to conduct thorough testing that includes fuzz testing and stateful testing before deploying an application to production.

After setting up the necessary mock smart contracts, we will create a conftest.py file inside the tests folder. This file will be used to define reusable elements such as fixtures, which act like functions that return a new deployment each time to test our application. For testing our automated market maker, we will only need two demo tokens.

import pytest


@pytest.fixture(scope="function")
def usdt_token(project, accounts):
    """
    Returns a new instance of a mock USDT token contract, with an initial supply of 1,000.
    """
    return project.Token.deploy("USDT", "USDT", 18, 1000, sender=accounts[0])


@pytest.fixture(scope="function")
def usdc_token(project, accounts):
    """
    Returns a new instance of a mock USDC token contract, with an initial supply of 1,000.
    """
    return project.Token.deploy("USDC", "USDC", 18, 1000, sender=accounts[0])


@pytest.fixture(scope="function")
def uviswap_pair(project, accounts):
    """
    Returns a new instance of an empty Pair contract, primarily to be used as a blueprint.
    """
    return project.UviswapPair.deploy(sender=accounts[0])


@pytest.fixture(scope="function")
def uviswap_factory(project, accounts, uviswap_pair):
    """
    Returns a new instance of a Factory contract, the main entry point of our AMM.
    """
    return project.UviswapFactory.deploy(uviswap_pair.address, sender=accounts[0])

The code defines four fixtures: usdt_token, usdc_token, uviswap_pair, and uviswap_factory.

The uviswap_pair fixture creates and deploys a new instance of the UviswapPair contract.

The uviswap_factory fixture creates and deploys a new instance of the UviswapFactory contract, which requires the address of an empty UviswapPair contract as an argument. In this case, the address of the uviswap_pair fixture is used as the argument for the UviswapFactory deployment.

To test the functionality that we defined earlier, we will create a file called test_uviswap.py inside the tests folder. At the top of this file, we should import project from Ape. This allows us to access the contracts on some of the tests.

from ape import project

🧪 Creating a Liquidity Pool

The test creates a new pair contract by calling the createPair function of the uviswap_factory contract and passing the addresses of two tokens as arguments. It then retrieves the address of the created pair contract and uses it to instantiate a new UviswapPair object. Finally, it asserts that the UviswapPair object has the expected default values for its token0, token1, reserve0, reserve1, and totalSupply variables.


def test_create_pair(accounts, usdt_token, usdc_token, uviswap_factory):
    # Create a new pair contract by calling the method with the addresses of two tokens
    uviswap_factory.createPair(usdt_token.address, usdc_token.address, sender=accounts[0]) 

    # Access the address of the created pair contract
    pair_address = uviswap_factory.allPairs(0) 

    # Access the pair contract object by its address
    pair = project.UviswapPair.at(pair_address)

    # Assert that the pair contract object has the expected default values
    assert pair.token0() == usdt_token.address
    assert pair.token1() == usdc_token.address
    assert pair.reserve0() == 0
    assert pair.reserve1() == 0
    assert pair.totalSupply() == 0

🧪 Adding liquidity to the Pool

This code is testing the functionality of creating a new pair contract, adding liquidity to the contract, and checking if all the values are set correctly.


def test_add_liquidity(accounts, usdt_token, usdc_token, uviswap_factory):
    # Create a new pair contract by calling the method with the addresses of two tokens
    uviswap_factory.createPair(usdt_token.address, usdc_token.address, sender=accounts[0]) 

    # Access the address of the created pair contract
    pair_address = uviswap_factory.allPairs(0) 

    # Access the pair contract object by its address
    pair = project.UviswapPair.at(pair_address)

    # Define the amount to add liquidity to the pair contract (500 USDC/USDT)
    amount = int(500e18)

    # Approve pair to use our tokens
    usdt_token.approve(pair_address, amount, sender=accounts[0])
    usdc_token.approve(pair_address, amount, sender=accounts[0])

    # Add liquidity to the pair contract
    pair.addLiquidity(amount, amount, sender=accounts[0])

    # Check if the liquidity is added correctly
    assert pair.balanceOf(accounts[0]) == amount # minted shares
    assert pair.reserve0() == amount
    assert pair.reserve1() == amount
    assert usdt_token.balanceOf(pair) == amount
    assert usdc_token.balanceOf(pair) == amount

🧪 Removing liquidity from the Pool

This code tests the functionality of creating a new pair contract, adding liquidity to the contract, then removing value from the contract and checking if all the values are set correctly.


def test_remove_liquidity(accounts, usdt_token, usdc_token, uviswap_factory):
    # Create a new pair contract by calling the method with the addresses of two tokens
    uviswap_factory.createPair(usdt_token.address, usdc_token.address, sender=accounts[0]) 

    # Access the address of the created pair contract
    pair_address = uviswap_factory.allPairs(0) 

    # Access the pair contract object by its address
    pair = project.UviswapPair.at(pair_address)

    # Define the amount to add liquidity to the pair contract (500 USDC/USDT)
    amount = int(500e18)

    # Approve pair to use our tokens
    usdt_token.approve(pair_address, amount, sender=accounts[0])
    usdc_token.approve(pair_address, amount, sender=accounts[0])

    # Add liquidity to the pair contract
    pair.addLiquidity(amount, amount, sender=accounts[0])

    # Get the number of shares owned by the account
    shares = pair.balanceOf(accounts[0])

    # Remove liquidity from the pair
    pair.removeLiquidity(shares, sender=accounts[0])

    # Assert that the pool reserves and token balances are now all zero
    assert pair.balanceOf(accounts[0]) == 0 # confirm shares have been removed
    assert pair.reserve0() == 0
    assert pair.reserve1() == 0
    assert usdc_token.balanceOf(pair) == 0
    assert usdt_token.balanceOf(pair) == 0

🧪 Swapping assets

This code is testing the swap() function of the pair contract. The code creates a new pair contract with mock USDT and USDC tokens, adds liquidity to it, and then performs a swap of 100 USDT for USDC. The balances of the accounts before and after the swap are compared to ensure the swap was performed correctly.


def test_swap(accounts, usdt_token, usdc_token, uviswap_factory):
    # Create a new pair contract by calling the method with the addresses of two tokens
    uviswap_factory.createPair(usdt_token.address, usdc_token.address, sender=accounts[0]) 

    # Access the address of the created pair contract
    pair_address = uviswap_factory.allPairs(0) 

    # Access the pair contract object by its address
    pair = project.UviswapPair.at(pair_address)

    # Define the amount to add liquidity to the pair contract (500 USDC/USDT)
    amount = int(500e18)

    # Approve pair to use our tokens
    usdt_token.approve(pair_address, amount, sender=accounts[0])
    usdc_token.approve(pair_address, amount, sender=accounts[0])

    # Add liquidity to the pair contract
    pair.addLiquidity(amount, amount, sender=accounts[0])

    # Save the initial balances before the swap
    initial_balances = {
        "usdt": usdt_token.balanceOf(accounts[0]),
        "usdc": usdc_token.balanceOf(accounts[0])
    }

    # Define the amount to be swapped for the other token on the pair contract (100 USDT)
    swap_amount = int(100e18) 

    # Approve token for a swap
    usdt_token.approve(pair_address, swap_amount, sender=accounts[0])

    # Perform the swap
    pair.swap(usdt_token.address, swap_amount, sender=accounts[0])

    # Get the balances after the swap
    final_balances = {
        "usdt": usdt_token.balanceOf(accounts[0]),
        "usdc": usdc_token.balanceOf(accounts[0])
    }

    # Test that we swapped tokens correctly
    assert initial_balances["usdt"] - swap_amount == final_balances["usdt"] # USDT balance should decrease (initial - swapped amount)
    assert initial_balances["usdc"] < final_balances["usdc"] # USDC balance should increase

🧪 Collecting fees

This code is testing the removeLiquidity() function of the pair contract. The code creates a new pair contract with mock USDT and USDC tokens, adds liquidity to it, and then performs a swap of 10 USDT for USDC. The balances of the accounts before and after the swap are compared to ensure the swap was performed correctly.


def test_collecting_fees(accounts, usdt_token, usdc_token, uviswap_factory):
    # Create a new pair contract by calling the method with the addresses of two tokens
    uviswap_factory.createPair(usdt_token.address, usdc_token.address, sender=accounts[0]) 

    # Access the address of the created pair contract
    pair_address = uviswap_factory.allPairs(0) 

    # Access the pair contract object by its address
    pair = project.UviswapPair.at(pair_address)

    # Define the amount to add liquidity to the pair contract (100 USDC/USDT)
    amount = int(100e18) 

    # Approve pair to use our tokens
    usdt_token.approve(pair_address, amount, sender=accounts[0])
    usdc_token.approve(pair_address, amount, sender=accounts[0])

    # Add liquidity to the pair contract
    pair.addLiquidity(amount, amount, sender=accounts[0])

    # Save the initial balances before the swap
    balances = {
        "usdt": usdt_token.balanceOf(accounts[0]),
        "usdc": usdc_token.balanceOf(accounts[0])
    }

    # Define the amount to be swapped for the other token on the pair contract (10 USDT)
    swap_amount = int(10e18)  

    # Approve token for a swap
    usdt_token.approve(pair_address, swap_amount, sender=accounts[0])

    # Perform the swap
    pair.swap(usdt_token.address, swap_amount, sender=accounts[0])

    # Get shares
    shares = pair.balanceOf(accounts[0])
    assert shares == int(100e18) # shares received should be equal to the amount of liquidity added

    # Remove liquidity
    pair.removeLiquidity(shares, sender=accounts[0])

    # Get the balances after claiming all the shares
    balances = {
        "usdt": usdt_token.balanceOf(accounts[0]),
        "usdc": usdc_token.balanceOf(accounts[0])
    }

    # Test that we collected fees correctly
    assert balances["usdt"] == int(1000e18) # USDT balance should be the original mint
    assert balances["usdc"] == int(1000e18) # USDC balance should be the original mint
    assert pair.balanceOf(accounts[0]) == 0 # confirm shares have been removed
    assert pair.reserve0() == 0
    assert pair.reserve1() == 0
    assert usdc_token.balanceOf(pair) == 0
    assert usdt_token.balanceOf(pair) == 0

This concludes the testing process for the smart contracts. Run the ape test on the terminal to execute the tests on a local network.

$ ape test

We defined several tests for the smart contracts that were implemented in the project. These tests cover various functionalities, including adding and removing liquidity, swapping tokens, and collecting fees. Each test is written in a way that clearly describes the functionality being tested and sets up the necessary conditions to execute the test.

You can extend the tests to cover additional scenarios because the current set of tests is not exhaustive.

🧪 You can find the complete test_uviswap.py file here.

Scripts

We'll be adding a deploy script to make it easy to deploy our application to any blockchain. For this demonstration, we'll be deploying to Avalanche, and thanks to ApeWorx, the process is incredibly simple. All we need to do is install the official Avalanche plugin provided by ApeWorx.

In this case, since we'll be deploying our Uviswap App to Avalanche, we'll need to install the Avalanche plugin. You can easily do this by running the command on your terminal:

$ ape plugins install avalanche

Also, we need to configure the RPC URL endpoints ape is going to connect to, this can be done on the ape-config.yaml file, yours should look something like this:

# ape-config.yaml
name: uviswap

plugins:
  - name: avalanche
  - name: vyper

geth:
  avalanche:
    mainnet:
      uri: https://api.avax.network/ext/bc/C/rpc
    fuji:
      uri: https://avalanche-fuji.drpc.org/

It's worth noting that plugins are a great way to expand the functionality of ApeWorx.

Accounts

To deploy our smart contracts, we'll need an account with AVAX (if you are on testnet you can fund your wallet using the official faucet). While many frameworks suggest adding your private key to a .env file, this approach can be a serious security vulnerability. Luckily, ApeWorx provides a better solution out of the box that allows us to work with accounts more securely.

With ApeWorx, all we need to do is execute a few simple commands to get set up. We won't have to worry about storing our private key in a file or exposing it to potential attackers. This way, we can work with our accounts and deploy our smart contracts with confidence and peace of mind. Let's dive in and get started!

For this guide I will be using the name test_account to deploy the smart contract, you can choose any name you like, but be sure to use the same name on your script.

$ ape accounts generate <name_of_your_account>

This will prompt you to put in your private key and a password, you can get your private key from MetaMask or any other wallet that you are using, and the password is going to be used to encrypt your account.

After we complete that inside your scripts folder create a deploy.py, this is going to hold the code for our deployments.


from ape import project, accounts

def main():
    test_account = accounts.load("test_account")
    uviswap_pair = project.UviswapPair.deploy(sender=test_account)
    project.UviswapFactory.deploy(uviswap_pair.address, sender=test_account)

That would be it, just type ape run deploy --network <network> and Ape will run the deploy script.

Command to deploy on Avalanche Tesnet

$ ape run deploy --network avalanche:fuji

Command to deploy on Avalanche Mainnet

$ ape run deploy --network avalanche:mainnet

Conclusion

Automatic Market Makers are a wonderful tool used in the decentralized finance space, it allows users to swap tokens without "normal" market makers almost instantly. These kinds of smart contracts have a lot of use cases, and you can expand a lot more on this automatic market maker idea. Be creative!

Uviswap GitHub Repository

Explore Uviswap on GitHub: https://github.com/rafael-abuawad/uviswap

Discover the complete source code, smart contracts, testing scripts, and deployment instructions. Contribute, open issues, and engage with the community.

Challenge #2: 🪙 Multi Token Vendor | Speedrun Ethereum With Vyper

Rafael Abuawad — Thu, 09 Mar 2023 14:32:39 +0000

🪙 Introduction
📦 Setup
📑 Code
🔬 Conclusion

🪙 Introductionn

ERC1155 is a novel token standard that draws inspiration from previous standards like ERC20, ERC721, and ERC777 to create a more efficient and fungibility-agnostic token contract. This standard is designed to be gas-efficient and allow for the creation of multiple token types within a single contract, which can significantly reduce transaction costs and increase flexibility for developers.

By taking the best ideas from previous standards, ERC1155 aims to provide a more streamlined and versatile approach to token development. If you're not already familiar with ERC20, ERC721, and ERC777, it's worth reviewing their guides to better understand the context and benefits of ERC1155. Overall, this standard represents an exciting step forward in token development and has the potential to unlock new possibilities for DeFi and other blockchain applications.

📦 Setup

For setting up the project on a local machine, only one essential component is required:

Python

Python is the primary programming language used in the project, it includes PIP, which serves as the package manager for Python and Virtual ENV is an essential tool used for creating a virtual environment that will house the application's code.

While the process for setting up these components is beyond the scope of this challenge, in essence, it involves installing Python and configuring a virtual environment for the application's code. It is important to note that creating a virtual environment for the project ensures that the application's dependencies and requirements are isolated from those of the host system, thereby improving stability and reproducibility.

Brownie

If you are going to use Brownie in this challenge, in your virtual environment, go ahead and install Brownie, after you installed it, create a new folder called vaults and inside it run the following command:

$ brownie init

Also, you might want to use the Hardhat node to test our smart contracts, so inside your project folder, run the following command:

$ npm install --save-dev hardhat

ApeWorx

If you are going to use ApeWorx in this challenge, activate your virtual environment and install ApeWorx:

$ pip install eth-ape'[recommended-plugins]'

After you installed it, create a new folder called vaults and inside it run the following command:

$ ape init

📑 Code

The ERC-1155 standard is a novel token standard that aims to take the best from previous standards to create a fungibility-agnostic and gas-efficient token contract. ERC1155 draws ideas from all of ERC20, ERC721, and ERC777. Inside your contracts folder, create a file called token.vy this will contain all of the code necessary to implement the ERC-1155.

Token (ERC-1155)

In this chanllege, there is no barebones implementation of the 1155 token standard in Vyper. Can you make it from scratch?

# @version >=0.3.3

# ... missing ERC-1155 implementation

Important: ⚠️🐍 If you are new to Vyper, don't worry, it was designed to be simple and readable, making it easier for programmers with any level of experience to quickly grasp the language. If you need more guidance, there are many resources available online to help you get started, such as the Vyper documentation, tutorials, and community forums.

Feel stuck? Take a look at the Vyperlang Official Implemenation

🔬 Conclusion

In this challenge, we have explored the ERC1155 token standard and its role as a fundamental building block of DeFi and NFT applications on EVM-compatible blockchains, and in conclusion, ERC1155 is a novel standard that combines the best ideas from previous standards like ERC20, ERC721, and ERC777 to create a more efficient and flexible token contract. By allowing for the creation of multiple token types within a single contract, ERC1155 can significantly reduce transaction costs and increase flexibility for developers.

Finally, implementing the ERC1155 token standard in Vyper can be done from scratch by following the guidelines and resources provided. Overall, ERC1155 represents an exciting step forward in token development, and its potential to unlock new possibilities for DeFi and other blockchain applications makes it a standard worth exploring.

📒 Note: Whether using Brownie or ApeWorx, creating a virtual environment for the project ensures that the application's dependencies and requirements are isolated from those of the host system, improving stability and reproducibility.

🐍 Note: The Vyper programming language offers several advantages over other languages, including higher security, improved gas efficiency, and enhanced code readability, making it a great option for NFT development projects.

Challenge #1: 🥩 Decentralized Staking App | Speedrun Ethereum With Vyper 🐍

Rafael Abuawad — Fri, 17 Feb 2023 15:16:42 +0000

🥩 Introduction
📦 Setup
📑 Code
🔬 Conclusion

🥩 Introductionn

The ERC20 standard has long been the backbone of token development on EVM-compatible blockchains, serving as a fundamental component not only for DeFi but for a wide range of blockchain applications. However, as the DeFi ecosystem continues to evolve, the need for new standards that can support more advanced features and functions has become increasingly apparent.

ERC4626 is one such standard, specifically designed for yield-generating vaults. By providing a more consistent and interoperable framework for developing these critical components of DeFi, ERC4626 promises to open up new opportunities for developers and users alike.

In the upcoming challenge, we will delve into the implementation process for both tokens and vaults, leveraging the Vyper programming language to explore the key concepts and principles involved in this exciting area of blockchain development. Through this process, participants will gain a deeper understanding of the challenges and opportunities involved in building DeFi applications, and be equipped with the skills and knowledge necessary to succeed in this dynamic and rapidly-evolving field.

📦 Setup

For setting up the project on a local machine, only one essential component is required:

Python

Brownie

$ brownie init

Also, you might want to use the Hardhat node to test our smart contracts, so inside your project folder, run the following command:

$ npm install --save-dev hardhat

ApeWorx

If you are going to use ApeWorx in this challenge, activate your virtual environment and install ApeWorx:

$ pip install eth-ape'[recommended-plugins]'

After you installed it, create a new folder called vaults and inside it run the following command:

$ ape init

📑 Code

The ERC-20 token standard serves as the foundation for DeFi applications on EVM blockchains. Inside your contracts folder, create a file called token.vy this will contain all of the code necessary to implement the ERC-20.

Token (ERC-20)

Here is a barebones implementation of the ERC20 token standard in Vyper, can you turn it into a working smart contract?

Important: ⚠️🐍 If you are new to Vyper, don't worry, it was designed to be simple and readable, making it easier for programmers with any level of experience to quickly grasp the language. If you need more guidance, there are many resources available online to help you get started, such as the Vyper documentation, tutorials, and community forums.

# @version >=0.3.3
from vyper.interfaces import ERC20
from vyper.interfaces import ERC20Detailed

### INTERFACES ###
implements: ERC20
implements: ERC20Detailed

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

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

### METHODS ###
@view
@external
def name() -> String[10]:
    # ... TODO: Implementation
    return NAME


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


@view
@external
def decimals() -> uint8:
    # ... TODO: Implementation
    return DECIMALS


@external
def transfer(_to : address, _value : uint256) -> bool:
    # ... TODO: Implementation 
    return False


@external
def transferFrom(_from : address, _to : address, _value : uint256) -> bool:
    # ... TODO: Implementation 
    return False


@external
def approve(_spender : address, _value : uint256) -> bool:
    # ... TODO: Implementation
    return False


@external
def mint(_to: address, _value: uint256):
    # ... TODO: Implementation
    # ... TODO: Security
    pass


@external
def burn(_value: uint256):
    # ... TODO: Implementation
    # ... TODO: Security
    pass


@external
def burnFrom(_to: address, _value: uint256):
    # ... TODO: Implementation
    # ... TODO: Security
    pass

Feel stuck? Take a look at the Vyperlang Official Implemenation

Here is a barebones implementation of the ERC4626 token standard in Vyper, can you turn it into a working smart contract?

Note: 💡 There are many ways to generate yield. Take a look at this one, implemented in Solidity

# @version >=0.3.3
from vyper.interfaces import ERC20
from vyper.interfaces import ERC4626

### INTERFACES ####
implements: ERC20
implements: ERC4626

#### ERC20 | EVENTS ####

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

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

#### ERC4626 | EVENTS ####

event Deposit:
    depositor: indexed(address)
    receiver: indexed(address)
    assets: uint256
    shares: uint256

event Withdraw:
    withdrawer: indexed(address)
    receiver: indexed(address)
    owner: indexed(address)
    assets: uint256
    shares: uint256


### METHODS ###
@view
@external
def name() -> String[10]:
    # ... TODO: Implementation
    return NAME


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


@view
@external
def decimals() -> uint8:
    # ... TODO: Implementation
    return DECIMALS


@external
def transfer(receiver: address, amount: uint256) -> bool:
    # ... TODO: Implementation
    return True


@external
def approve(spender: address, amount: uint256) -> bool:
    # ... TODO: Implementation
    return True


@external
def transferFrom(sender: address, receiver: address, amount: uint256) -> bool:
    # ... TODO: Implementation
    return True


@view
@external
def totalAssets() -> uint256:
    # ... TODO: Implementation
    return 0


@view
@external
def convertToAssets(shareAmount: uint256) -> uint256:
    # ... TODO: Implementation
    return 0


@view
@external
def convertToShares(assetAmount: uint256) -> uint256:
    # ... TODO: Implementation
    return 0


@view
@external
def maxDeposit(owner: address) -> uint256:
    # ... TODO: Implementation
    return 0


@view
@external
def previewDeposit(assets: uint256) -> uint256:
    # ... TODO: Implementation
    return 0


@external
def deposit(assets: uint256, receiver: address=msg.sender) -> uint256:
    # ... TODO: Implementation
    return 0


@view
@external
def maxMint(owner: address) -> uint256:
    # ... TODO: Implementation
    return 0


@view
@external
def previewMint(shares: uint256) -> uint256:
    # ... TODO: Implementation
    return 0


@external
def mint(shares: uint256, receiver: address=msg.sender) -> uint256:
    # ... TODO: Implementation
    return 0


@view
@external
def maxWithdraw(owner: address) -> uint256:
    # ... TODO: Implementation
    return 0

@view
@external
def previewWithdraw(assets: uint256) -> uint256:
    # ... TODO: Implementation
    return 0


@external
def withdraw(assets: uint256, receiver: address=msg.sender, owner: address=msg.sender) -> uint256:
    # ... TODO: Implementation
    return 0


@view
@external
def maxRedeem(owner: address) -> uint256:
    # ... TODO: Implementation
    return 0


@view
@external
def previewRedeem(shares: uint256) -> uint256:
    # ... TODO: Implementation
    return 0


@external
def redeem(shares: uint256, receiver: address=msg.sender, owner: address=msg.sender) -> uint256:
    # ... TODO: Implementation
    return 0

Feel stuck? Take a look at the Vyperlang Official Implemenation

🔬 Conclusion

In this challenge, we have explored the ERC20 token standard and its role as a fundamental building block of DeFi applications on EVM-compatible blockchains. We have learned how to use the Vyper programming language to create a basic implementation of the ERC20 standard, including the definition of token properties, the specification of events, and the implementation of essential token transfer methods.

Going beyond this, we have also introduced the ERC4626 standard, which is specifically designed for yield-generating vaults. By providing a consistent and interoperable framework for the development of these critical DeFi components, ERC4626 offers a significant opportunity for developers and users alike to benefit from new features and functionality in the DeFi ecosystem.

📒 Note: Whether using Brownie or ApeWorx, creating a virtual environment for the project ensures that the application's dependencies and requirements are isolated from those of the host system, improving stability and reproducibility.

🐍 Note: The Vyper programming language offers several advantages over other languages, including higher security, improved gas efficiency, and enhanced code readability, making it a great option for NFT development projects.

Challenge #0: 🖼️ Simple NFT Example | Speedrun Ethereum With Vyper 🐍

Rafael Abuawad — Wed, 15 Feb 2023 15:56:05 +0000

🎟 Introduction
📦 Setup
📑 Code
🔬 Conclusion

🎟 Introduction

The ERC-721 token standard serves as the foundation for Non-Fungible Tokens (NFTs), providing developers with the capability to design unique digital assets that cannot be duplicated on a blockchain. This feature unlocks the potential for an entirely new realm of experiences, including exclusive access to gated websites or communities restricted to select token holders, as well as innovative games where each item possesses distinct properties such as resealability, multi-functionality, and complete ownership.

In the initial segment of this challenge, we will explore the process of implementing an NFT through the utilization of the Vyper programming language.

The ability to create and exchange unique digital assets through NFTs has opened up new opportunities for content creators, artists, and collectors to monetize and showcase their work in innovative ways. NFTs have enabled the creation of digital art, music, and collectibles that can be traded bought, and sold as one-of-a-kind assets while providing a secure and transparent record of ownership on the blockchain.

Furthermore, the utilization of Vyper programming language in implementing NFTs offers a number of advantages, including higher security, improved gas efficiency, and enhanced readability of the code, which in turn increases the ease of development and maintenance of NFT projects.

📦 Setup

For setting up the project on a local machine, only one essential component is required:

Python

Brownie

If you are going to use Brownie in this challenge, in your virtual environment, go ahead and install Brownie, after you installed it, create a new folder called nft and inside it run the following command:

$ brownie init

Also, you might want to use the Hardhat node to test our smart contracts, so inside your project folder, run the following command:

$ npm install --save-dev hardhat

ApeWorx

If you are going to use ApeWorx in this challenge, activate your virtual environment and install ApeWorx:

$ pip install eth-ape'[recommended-plugins]'

After you installed it, create a new folder called nft and inside it run the following command:

$ ape init

📑 Code

The ERC-721 token standard serves as the foundation for Non-Fungible Tokens (NFTs). Inside your contracts folder, create a file called nft.vy this will contain all of the code necessary to implement the ERC-721.

Non-Fungible Token (ERC-721)

Here is a barebones implementation of the ERC721 token standard in Vyper, can you turn it into a working smart contract?

Important: ⚠️🐍 If you are new to Vyper, don't worry, it was designed to be simple and readable, making it easier for programmers with any level of experience to quickly grasp the language. If you need more guidance, there are many resources available online to help you get started, such as the Vyper documentation, tutorials, and community forums.

# @version >=0.3.7
from vyper.interfaces import ERC165
from vyper.interfaces import ERC721

### INTERFACES ###
implements: ERC721
implements: ERC165

### EVENTS ###
event Transfer:
    sender: indexed(address)
    receiver: indexed(address)
    tokenId: indexed(uint256)

event Approval:
    owner: indexed(address)
    approved: indexed(address)
    tokenId: indexed(uint256)

event ApprovalForAll:
    owner: indexed(address)
    operator: indexed(address)
    approved: bool


### METHODS ###
@external
@view
def balanceOf(_owner: address) -> uint256:
    # ... TODO: Implementation
    return 0


@external
@view
def ownerOf(_tokenId: uint256) -> address:
    # ... TODO: Implementation
    return empty(address)


@external
def safeTransferFrom(_from: address, _to: address, _tokenId: uint256, _data: Bytes[1024]=b"")
    # ... TODO: Implementation
    pass


@external
def transferFrom(_from: address, _to: address, _tokenId: uint256):
    # ... TODO: Implementation
    pass


@external
def approve(_to: address, _tokenId: uint256):
    # ... TODO: Implementation
    pass


@external
def setApprovalForAll(_operator: address, _approved: bool):
    # ... TODO: Implementation
    pass


@external
@view
def getApproved(_tokenId: uint256) -> address:
    # ... TODO: Implementation
    return empty(address)


@external
def isApprovedForAll(_owner: address, _operator: address) -> bool:
    # ... TODO: Implementation
    return false

Feel stuck? Take a look at the Vyperlang Official Implemenation

🔬 Conclusion

In this challenge, we explored the process of implementing an NFT using the Vyper programming language, which provides developers with a secure and gas-efficient approach to creating unique digital assets that cannot be duplicated on a blockchain. We provided a barebones implementation of the ERC-721 token standard in Vyper and challenged readers to turn it into a working smart contract by implementing the necessary methods and events.

Creating and exchanging unique digital assets through NFTs has opened up new opportunities for content creators, artists, and collectors to monetize and showcase their work in innovative ways. NFTs have enabled the creation of digital art, music, and collectibles that can be traded bought, and sold as one-of-a-kind assets while providing a secure and transparent record of ownership on the blockchain.

📒 Note: Whether using Brownie or ApeWorx, creating a virtual environment for the project ensures that the application's dependencies and requirements are isolated from those of the host system, improving stability and reproducibility.

🐍 Note: The Vyper programming language offers a number of advantages over other languages, including higher security, improved gas efficiency, and enhanced code readability, making it a great option for NFT development projects.

Understanding Chainlink VRF: A Tool for Random Number Generation on the Blockchain

Rafael Abuawad — Mon, 23 Jan 2023 15:55:23 +0000

Random number generation (RNG) is a fundamental building block for many decentralized applications (dApps), from games to smart contracts. However, generating truly random numbers on a blockchain, which is a deterministic system, is a non-trivial task. Chainlink VRF (Verifiable Random Function) is a new tool that aims to solve this problem by providing a secure and verifiable way to generate random numbers on the Ethereum blockchain.

What is Chainlink VRF?

Chainlink VRF is a smart contract that implements a verifiable random function (VRF) on the Ethereum blockchain. A VRF is a cryptographic primitive that generates a random value, and also provides proof that the value was generated at random. This is achieved by using a combination of a pseudorandom function (PRF) and a digital signature.

The Chainlink VRF smart contract is designed to be used as an oracle, meaning it can be queried by other smart contracts to provide a random value. The smart contract also provides proof of the randomness of the value, which can be verified by any other contract or user.
How is it useful?

Chainlink VRF is useful for several reasons:

True randomness: Chainlink VRF provides a way to generate truly random numbers on the blockchain, which is essential for many dApps that rely on randomness, such as games or lotteries.

Verifiability: Chainlink VRF provides proof of the randomness of the generated value, which can be verified by any other contract or user. This ensures that the random value has not been tampered with and was truly generated randomly.

Decentralization: Chainlink VRF is a decentralized solution, meaning that it is not controlled by any single entity and is resistant to censorship and tampering. This makes it a more secure and trustless option compared to centralized RNG solutions.

Flexibility: Chainlink VRF can be integrated with other smart contracts and dApps, making it a versatile tool for a wide range of use cases.

Conclusion

Chainlink VRF is a powerful tool for generating truly random numbers on the Ethereum blockchain. It provides a secure, verifiable, and decentralized solution for dApps that rely on randomness, and can be integrated with Solidity and Vyper contracts. As more developers and projects start to adopt this technology, we can expect to see it become a standard building block for many decentralized applications.

Understanding Polygon: The L2 Scaling Solution for Ethereum

Rafael Abuawad — Thu, 19 Jan 2023 15:45:04 +0000

As the popularity of decentralized applications (dApps) on the Ethereum network continues to grow, the need for a high-performance, low-cost infrastructure has become increasingly important. This is where Polygon comes in.

Polygon (formerly known as Matic Network) is an open-source, multichain scaling solution that aims to provide a high-performance and low-cost infrastructure for decentralized applications (dApps) built on the Ethereum network. It is considered a Layer 2 scaling solution, which means that it runs in parallel to the main Ethereum blockchain, allowing for faster and cheaper transactions.

One of the key features of Polygon is its use of a modified version of the Ethereum consensus mechanism called "Proof of Stake" with a variant called "Plasma" for its side chains. This allows for faster and cheaper transactions, while still maintaining the security of the main Ethereum blockchain.

Another important feature of Polygon is its concept of "Supernets." Supernets are a collection of interconnected Polygon chains that share a common governance model and token economy. Each Supernet is designed to serve a specific use case or community, and they are designed to be interoperable with each other and with Ethereum.

Polygon also provides a suite of other protocols and services, including a decentralized oracle network, a cross-chain communication protocol, and a decentralized governance model. All of these features work together to provide a robust and flexible infrastructure for dApp developers.

In terms of deployment, developers can use Polygon's SDKs to easily deploy and interact with their dApps on Polygon's networks, and in order to use Polygon's infrastructure, developers need to pay in $MATIC, the native token of the network, as a transaction fee.

Overall, Polygon is a highly promising scaling solution for the Ethereum network. Its use of a modified version of the Ethereum consensus mechanism, its concept of Supernets, and its suite of other protocols and services make it a powerful infrastructure for dApp development.

It's worth noting that Polygon also has on its networks a variety of independent projects and protocols that can be used to build decentralized oracle systems, such as Chainlink, API3, others, as well as AMMs, Lending Protocols, and more.

Svelte for Beginners: A Beginner's Guide to Building Web Applications

Rafael Abuawad — Wed, 18 Jan 2023 21:48:14 +0000

Svelte is a popular JavaScript framework for building web applications. Thanks to some tricks it is lightweight and easy to use, making it a great option for beginners. In this blog post, we'll take a look at how to set up Svelte and give code samples for working with forms, reactive states, and stores.

Setting up Svelte

To get started, you'll need to have Node.js installed on your machine. Once you have Node.js installed, you can use Vite to create a new Svelte project:

npm create vite@latest my-svelte-app -- --template svelte

This will create a new directory called my-svelte-app and initialize it with the Svelte template. Next, navigate to the new directory and install the necessary dependencies:

cd my-svelte-app
npm install

Now that you have your project set up, you can start the development server using the following command:

npm run dev

This will start a development server and open your project in a web browser. You should see a "Vite + Svelte" message on the page, on top of a count button, if you press that button you will see how the count increases, we will learn how to do that ourselves in the following section.

Open that directory on a code editor of your choice, you can see an App.svelte file inside the src folder, remove all of its contents. Also delete the src/lib folder, we will not use it in this case.

Working with Reactive State

Svelte uses a reactive system to automatically update the DOM when the state of a component changes. In the following example, we'll create a simple counter that increments and decreases a value when clicking buttons.

Open the App.svelte file, and type the following:


<script>
  let count = 0;

  function increment() {
    count += 1;
  }

  function decrement() {
    count -= 1;
  }
</script>

<button on:click={decrement}>-</button>
<span>{count}</span>
<button on:click={increment}>+</button>

In this example, we created two buttons, one to increment the count and one to decrease the count. The on:click directive is used to attach click events to the buttons, which call the increment and decrement functions respectively. The count variable is used to store the current value of the counter, which is displayed in a span element using curly braces ({}).

When the increment or decrement function is called, the value of the count variable is updated, and Svelte's reactive system automatically updates the span element to reflect the new value.

Working with forms

Svelte makes it easy to work with forms and inputs. In the following example, we'll create a simple form with text input and a submit button. The form will have a submit event that will output the text input's value to the console when the button is clicked.

Remove all of the contents on App.svelte, and write:


<script>
  let name = "";

  function handleSubmit() {
    console.log(name);
  }
</script>

<form on:submit|preventDefault={handleSubmit}>
  <input type="text" bind:value={name}>
  <button type="submit">Submit</button>
</form>

In this example, we are using the bind:value directive to bind the value of the text input to a variable called name. The on:submit|preventDefault directive is used to attach a submit event to the form, which calls the handleSubmit function when the button is clicked. The preventDefault modifier is used to prevent the default behavior of the form, which is to refresh the page.

Working with Stores

Svelte also allows you to create global stores, which can be used to share states across multiple components. In the following example, we'll create a store for a user's name and age and use it in multiple components.

Create a folder inside src called stores, and inside that folder create a main.js, this will be our main store for this application, you can have multiple stores that can do multiple things, but for the sake of simplicity, we will keep this short.


// stores/main.js
import { writable } from "svelte/store";

export const name = writable("");
export const age = writable(0);

After that create another folder called components, we will create two Svelte files, one called ComponentA.svelte and the other will be called ComponentB.svelte, you can call the components whatever you like.

In the first component, we are going to get the name from the store and updated it to something else on that component.

To subscribe to a store value, you just need to prepend $ to each variable.


<!-- Component A -->
<script>
    import { name } from '../stores/main.js';
</script>

<form>
    <label for="name">Name: </label>
    <input id="name" type="text" bind:value={$name}>
</form>

Now in the second component, we are going to get the age from the store and updated it to something else on that component.


<!-- Component B -->
<script>
    import { age } from '../stores/main.js';
</script>

<form>
    <label for="age">Age: </label>
    <input id="age" type="number" bind:value={$age}>
</form>

After that, we can go back to our App.svelte file, remove all of its contents and import the two components:


<script>
  import ComponentA from "./components/ComponentA.svelte";
  import ComponentB from "./components/ComponentB.svelte";
  import { name, age } from "./stores/main.js"
</script>

<ComponentA />
<ComponentB />

<h1>Hello I'm {$name}, and I'm {$age} years old</h1>

In this example, we have created two stores for a user's name and age in the stores/main.js file. We then import and use these stores in two different components. We use the bind:value directive to bind the input value to the store. As you can see, the value of the store is reactive and will change if the input is changed.

In summary, Svelte is a powerful and easy-to-use JavaScript framework for building web applications. It allows you to work with forms, reactive states, and stores in a simple and intuitive way. This guide should give you a good starting point for building your own Svelte applications.

Create a blockchain asset tracking system using an ERC-721-inspired smart contract!

Rafael Abuawad — Thu, 12 Jan 2023 17:26:09 +0000

Introduction

Most asset tracking done today is done using something as basic and as insecure as a simple spreadsheet, in some cases a most sophisticated approach is done with some kind of database with custom software as an interface.

Both are extremely insecure and can be altered by an attacker. Let us imagine a company that distributes high-end computer boards, not only sells them but leases them to different types of organizations for testing, marketing, and more. If an attacker wanted to modify this register using the current approach it would be as simple as accessing the database or spreadsheet and changing a simple record.

Using multi-ownable smart contracts would prevent this kind of behavior by default, and asset tracking with NFTs can give better control of where is each asset and with some extra code give a lot more information than what can be stored in a simple spreadsheet.

Solving this problem

This problem can be solved using blockchain technology:

Create smart contracts that enable the company to track its assets transparently and reliably.
Create a custom blockchain to solve this issue.

in this article, we are going to see the first approach, but the second one can be as, if not more interesting and reliable.

Smart-contracts

For this approach, we only need one smart contract for tracking the assets.

We are going to use a similar approach to the ERC-721 token standard, but with a lot of parts removed and a lot of modifications.

Since we don't want users to trade tokens like a normal NFT, we also what the ability to remove token access to a given access, and we want to control who can have what.

Interfaces

This interface defines the asset collection itself and is a stripped-down version of an ERC-721.

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

interface IAssetCollection {
    event Transfer(
        address indexed from,
        address indexed to,
        uint256 indexed tokenId
    );

    function name() external view returns (string memory);

    function balanceOf(address owner) external view returns (uint256);

    function tokensOf(address tokenHolder)
        external
        view
        returns (uint256[] memory);

    function ownerOf(uint256 tokenId) external view returns (address owner);

    function tokenURI(uint256 tokenId) external view returns (string memory);

    function mint(address tokenHolder, string memory tokenURI) external;

    function burn(address tokenHolder, uint256 tokenId) external;

    function transfer(uint256 tokenId) external;

    function transferFrom(
        address tokenHolder,
        address to,
        uint256 tokenId
    ) external;
}

This interface describes is to allow control over the smart contract.

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

interface IOwnable {
    event TransferOwnership(address indexed from, address indexed to);

    function owner() external view returns (address);

    function transferOwnership(address _newOwner) external;
}

Smart-contract

The main smart contract is the Asset Collection smart contract, this contract is responsible for managing all the assets inside a particular collection, we (as the owners of the smart contract) can mint, burn, move and transfer tokens, each token represents an asset.

We don't want users to trade tokens (like NFTs), but we need the basic functionality from an ERC-721.

Due to limitations on smart contract data storage, we are storing all the relevant information outside the blockchain, preferably on a persistent storage platform (like Machina or Arweave), and using the token URI metadata pattern used commonly for NFTs.

Based on our work on the interface defined above, we will overview some functions.

Mint
The "mint" function can only be called ourselves (the owner) and is similar to the mint function found on any other NFT smart contracts. It gives us the ability to create a token.

function mint(address tokenHolder, string memory _tokenURI)
    public
    onlyOwner
{
    uint256 tokenId = _tokenIds;
    _tokenIds += 1;
    _setTokenURI(tokenId, _tokenURI);
    _mint(tokenHolder, tokenId);
}

Burn
The "burn" method allows us to destroy a token permanently.

function burn(address tokenHolder, uint256 tokenId)
    public
    onlyOwner
{
    _mint(tokenHolder, tokenId);
}

Transfer
The "transfer" method returns a token back to us, and can only be called by the token owner itself.

function transfer(uint256 tokenId) public {
    _transfer(msg.sender, _owner, tokenId);
}

Transfer from
The "transfer from" method allows us (the owner) to control tokens on behalf of a user. If we want to change the holder or if we need to take it back and assign it to ourselves again.

// Moves a token from one user to another
function transferFrom(
    address tokenHolder,
    address to,
    uint256 tokenId
) public onlyOwner {
    _transfer(tokenHolder, to, tokenId);
}

The final smart contract should look something like this.

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

import "./interfaces/IAssetCollection.sol";
import "./interfaces/IOwnable.sol";

contract AssetCollection is IAssetCollection, IOwnable {
    // Token ID counter
    uint256 private _tokenIds;

    // Owner of the smart-contract
    address private _owner;

    // Name of the asset collection
    string private _name;

    // Mapping from token ID to owner address
    mapping(uint256 => address) private _owners;

    // Mapping owner address to token count
    mapping(address => uint256) private _balances;

    // Mapping from token ID to token URI
    mapping(uint256 => string) private _tokenURIs;

    constructor(string memory __name) {
        _name = __name;
        _owner = msg.sender;
    }

    modifier onlyOwner() {
        require(_owner == msg.sender, "Ownable: caller is not the owner");
        _;
    }

    function _exists(uint256 tokenId) internal view returns (bool) {
        return _owners[tokenId] != address(0);
    }

    function _setTokenURI(uint tokenId, string memory _tokenURI) internal {
        _tokenURIs[tokenId] = _tokenURI;
    }

    function _mint(address to, uint256 tokenId) internal {
        require(to != address(0), "ERC721: mint to the zero address");
        // Check that tokenId was not minted
        require(!_exists(tokenId), "ERC721: token already minted");

        _balances[to] += 1;
        _owners[tokenId] = to;

        emit Transfer(address(0), to, tokenId);
    }

    function _transfer(
        address from,
        address to,
        uint256 tokenId
    ) internal {
        require(
            ownerOf(tokenId) == from,
            "ERC721: transfer from incorrect owner"
        );
        require(to != address(0), "ERC721: transfer to the zero address");

        _balances[from] -= 1;
        _balances[to] += 1;
        _owners[tokenId] = to;

        emit Transfer(from, to, tokenId);
    }

    function _burn(uint256 tokenId) internal {
        address tokenOwner = ownerOf(tokenId);
        _balances[tokenOwner] -= 1;

        emit Transfer(tokenOwner, address(0), tokenId);
    }

    // Creates token
    function mint(address tokenHolder, string memory _tokenURI)
        public
        onlyOwner
    {
        uint256 tokenId = _tokenIds;
        _tokenIds += 1;
        _setTokenURI(tokenId, _tokenURI);
        _mint(tokenHolder, tokenId);
    }

    // Destroys token
    function burn(address tokenHolder, uint256 tokenId) public onlyOwner {
        _mint(tokenHolder, tokenId);
    }

    // Transfer the token back to the DAO
    function transfer(uint256 tokenId) public {
        _transfer(msg.sender, _owner, tokenId);
    }

    // Moves a token from one user to another
    function transferFrom(
        address tokenHolder,
        address to,
        uint256 tokenId
    ) public onlyOwner {
        _transfer(tokenHolder, to, tokenId);
    }

    // Returns how many tokens a user owns
    function balanceOf(address tokenOwner) public view returns (uint256) {
        require(
            tokenOwner != address(0),
            "ERC721: address zero is not a valid owner"
        );
        return _balances[tokenOwner];
    }

    // Returns how many tokens a user owns
    function tokensOf(address tokenOwner)
        public
        view
        returns (uint256[] memory)
    {
        require(
            tokenOwner != address(0),
            "ERC721: address zero is not a valid owner"
        );

        uint256 balance = balanceOf(tokenOwner);
        uint256[] memory tokens = new uint[](balance);
        uint256 index = 0;

        for (uint id = 0; id < _tokenIds; id++) {
            if (_owners[id] == tokenOwner) {
                tokens[index] = id;
                index += 1;
            }
        }

        return tokens;
    }

    // Returns the token URI of the token
    function tokenURI(uint256 tokenId) public view returns (string memory) {
        require(_exists(tokenId), "ERC721: token hasn't been minted");
        return _tokenURIs[_tokenIds];
    }

    // Returns the owner of the token
    function ownerOf(uint256 tokenId) public view returns (address) {
        address tokenOwner = _owners[tokenId];
        require(tokenOwner != address(0), "ERC721: invalid token ID");
        return tokenOwner;
    }

    // Transfers the ownership of the smart-contract
    function transferOwnership(address _newOwner) public {
        require(msg.sender == _owner, "Ownable: Caller is not owner");
        require(
            _newOwner == address(0),
            "Ownable: New owner can not be the zero address"
        );

        address olOwner = _owner;
        _owner = _newOwner;
        emit TransferOwnership(olOwner, _newOwner);
    }

    // Returns name of the collection
    function name() public view returns (string memory) {
        return _name;
    }

    // Returns owner of the smart-contract
    function owner() public view returns (address) {
        return _owner;
    }
}

This token allows us to track an asset securely and transparently.

This is only contract is just for demonstration purposes and is not optimized nor audited.

Asset Collection smart contract deployed on the Avalanche Testnet

Create an Automated Market Maker (AMM) with Vyper! 🐍

Rafael Abuawad — Wed, 11 Jan 2023 21:46:19 +0000

Introduction

Welcome, in this tutorial, we will learn how to build an AMM with features like adding liquidity, removing liquidity & swapping tokens with shares and fees. The first smart contract can take in any two ERC20 tokens and make a liquidity pool with those, and the second one is used to deploy liquidity pools. We are going to use vyper to write the entirety of the smart contacts.

Prerequisites

Basic programming and console/terminal use experience
A simple understanding of Solidity or Vyper

Requirements

NodeJS
Python and Brownie ETH, or any smart contract framework
VSCode, or another code editor

What is an AMM?

Setup

We are going to use Brownie in this tutorial, after you installed Brownie, create a new folder called avalanche-swap and inside it run the following command:

$ brownie init

Also, we are going to be using the Hardhat node to test our smart contracts, so inside your project folder, run the following command:

$ npm install --save-dev hardhat

Implementing the pair smart-contract

Let's start with the boilerplate code. We create a file named contracts/AvaSwapPair.vy, define the vyper version as >= 0.3.7, and import the ERC20 and ERC20 Detailed interfaces from vyper.

# @version ^0.3.7

from vyper.interfaces import ERC20
from vyper.interfaces import ERC20Detailed

implements: ERC20
implements: ERC20Detailed

This is our basic boilerplate, we need the ERC20 definition to allow our users to use their shares however they want.

# @version ^0.3.7

from vyper.interfaces import ERC20
from vyper.interfaces import ERC20Detailed

###### EVENTS ######

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

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

###### STATE ######

# Share's token name
name: public(String[32])

# Share's token symbol
symbol: public(String[32])

# Share's token decimals
decimals: public(uint8)

# By declaring `balanceOf` as public, vyper automatically generates a 'balanceOf()' getter
# method to allow access to account balances.
balanceOf: public(HashMap[address, uint256])

# By declaring `allowance` as public, vyper automatically generates the `allowance()` getter
allowance: public(HashMap[address, HashMap[address, uint256]])

# By declaring `totalSupply` as public, we automatically create the `totalSupply()` getter
totalSupply: public(uint256)

###### CONSTRUCTOR ######
@external
def __init__():
    self.name = "Avalanche Swap"
    self.symbol = "AVAS"
    self.decimals = 18


###### INTERNAL METHODS ######
@internal
def _mint(_to: address, _value: uint256):
    assert _to != empty(address), "ERC20: mint to the zero address"
    self.balanceOf[_to] += _value
    self.totalSupply += _value
    log Transfer(empty(address), _to, _value)


@internal
def _burn(_to: address, _value: uint256):
    assert _to != empty(address), "ERC20: burn to the zero address"
    self.balanceOf[_to] -= _value
    self.totalSupply -= _value
    log Transfer(_to, empty(address), _value)


###### EXTERNAL METHODS ######
@external
def transfer(_to : address, _value : uint256) -> bool:
    assert _to != empty(address), "ERC20: transfer to the zero address"

    self.balanceOf[msg.sender] -= _value
    self.balanceOf[_to] += _value
    log Transfer(msg.sender, _to, _value)
    return True


@external
def transferFrom(_from : address, _to : address, _value : uint256) -> bool:
    self.allowance[_from][msg.sender] -= _value
    self.balanceOf[_from] -= _value
    self.balanceOf[_to] += _value

    log Transfer(_from, _to, _value)
    return True


@external
def approve(_spender : address, _value : uint256) -> bool:
    self.allowance[msg.sender][_spender] = _value
    log Approval(msg.sender, _spender, _value)
    return True


@external
def burn(_value: uint256):
    self._burn(msg.sender, _value)

This is a basic ERC20 smart contract, we are going to need this basic functionality to implement a proper AMM. Our users will receive shares each time they deposit liquidity, each share is an ERC20 token. And can redeem these shares for the tokens that they deposited with an extra tip for doing so.

The smart contract is divided on:

EVENTS
STATE
INTERNAL METHODS
EXTERNAL METHODS

This part is important since we are going to jump between those. So take note so you don't get lost.

We would be set on the ERC20 functionality of our smart contract to manage the pool shares we are going to distribute to our liquidity providers, this part is really common so we are not going to go into detail. Check out this blog post that I made on how to create a wrapped token using a similar approach, here I explain how ERC20 tokens work, why they are important, and how we can create a custom one linked to a cryptocurrency.

After that is done we need to add a few state variables to our smart contract to add the AMM functionality. Let's start with the tokens and the reserves:

###### STATE ######
...

# Pair tokens
token0: public(address)
token1: public(address)

# Reserve records
reserve0: public(uint256)
reserve1: public(uint256)

...

The token variables will keep track of which tokens the pool handles and the reserves will keep track of the amount that we have for each token.

Now we also need an internal update method to update the reserves each time we add or remove liquidity.

###### INTERNAL METHODS ######
...

@internal
def _update(_reserve0: uint256, _reserve1: uint256):
    self.reserve0 = _reserve0
    self.reserve1 = _reserve1

...

Finally, we need to add a setup function and set up a state variable flag that is going to be called by that factory, this function will set the tokens and with the flag, it can only be called once.

###### STATE ######
...

# Setup flag
_setup: bool

...

Since the method will be called from the outside we need to define it in the external methods section.

###### EXTERNAL METHODS ######
...

@external
def setup(_token0: address, _token1: address):
    assert self._setup == False, "Avalanche Swap Pair: already initialized"
    self.token0 = _token0
    self.token1 = _token1
    self._setup = True

...

Add liquidity

Adding liquidity allows our AMM to work, without liquidity, there would not be any swapping of tokens. The addLiquidity method is really simple, the user deposits some tokens to our smart contract (the initial k=x*y is defined by the first deposit) in return the smart contract mints some share tokens to redeem these tokens later, with some collected fees as a result of other users swapping tokens with this liquidity.

We added a reentrancy guard to prevent bad actors from exploiting this functionality.

###### EXTERNAL METHODS ######
...

@external
@nonreentrant("add")
def addLiquidity(_amount0: uint256, _amount1: uint256) -> uint256:
    # add liquidity
    ERC20(self.token0).transferFrom(msg.sender, self, _amount0)
    ERC20(self.token1).transferFrom(msg.sender, self, _amount1)

    # keep the pool balanced (k=x*y)
    if self.reserve0 > 0 or self.reserve1 > 0:
        assert self.reserve0 * _amount1 == self.reserve1 * _amount0, "Avalanche Swap Pair: x / y != dx / dy" 

    shares: uint256 = 0
    if self.totalSupply == 0:
        shares = isqrt(_amount0 * _amount1)
    else:
        shares = min(
            (_amount0 * self.totalSupply) * self.reserve0,
            (_amount1 * self.totalSupply) * self.reserve1
        )

    assert shares > 0, "Avalanche Swap Pair: shares were zero"

    # mint shares to liquidity provider
    self._mint(msg.sender, shares)

    # update reserves
    self._update(ERC20(self.token0).balanceOf(self), ERC20(self.token1).balanceOf(self))

    return shares

...

Remove liquidity

Removing the liquidity is straightforward, we burn the shares that the user passes in and we transfer the corresponding tokens to that user.

We added a reentrancy guard to prevent bad actors from exploiting this functionality.

###### EXTERNAL METHODS ######
...

@external
@nonreentrant("remove")
def removeLiquidity(_shares: uint256) -> (uint256, uint256):
    _token0: ERC20 = ERC20(self.token0)
    _token1: ERC20 = ERC20(self.token1)

    bal0: uint256 = _token0.balanceOf(self)
    bal1: uint256 = _token1.balanceOf(self)

    amount0: uint256 = (_shares * bal0) / self.totalSupply
    amount1: uint256 = (_shares * bal1) / self.totalSupply

    # _burn checks if the user has enough shares
    self._burn(msg.sender, _shares)
    # update reserves
    self._update(bal0 - amount0, bal1 - amount1)

    # transfers the tokens back
    _token0.transfer(msg.sender, amount0)
    _token1.transfer(msg.sender, amount1)

    return (amount0, amount1)

...

Swap

The swap functionality is essential on any AMM, here a user passes a token and an amount, and with these two we return the opposite token of the pair with the corresponding amount, taking a small fee for our liquidity providers in the process.

We added a reentrancy guard to prevent bad actors from exploiting this functionality.

###### EXTERNAL METHODS ######
...

@external
@nonreentrant("swap")
def swap(_tokenIn: address, _amountIn: uint256) -> uint256:
    assert _tokenIn == self.token0 or _tokenIn == self.token1, "Avalanche Swap Pair: invalid token"
    assert _amountIn > 0, "Avalanche Swap Pair: amount in is zero"

    # variables to interact with the liquidity pool
    tokenIn: ERC20 = empty(ERC20)
    tokenOut: ERC20 = empty(ERC20)
    reserveIn: uint256 = 0
    reserveOut: uint256 = 0

    # determine which token is being swapped in
    # and assigning variables accordingly
    isToken0: bool = _tokenIn == self.token0
    if isToken0:
        tokenIn = ERC20(self.token0)
        tokenOut = ERC20(self.token1)
        reserveIn = self.reserve0
        reserveOut = self.reserve1
    else:
        tokenIn = ERC20(self.token1)
        tokenOut = ERC20(self.token0)
        reserveIn = self.reserve1
        reserveOut = self.reserve0

    # transfer in the tokens
    tokenIn.transferFrom(msg.sender, self, _amountIn)

    # 0.3% fee
    amountInWithFee: uint256 = (_amountIn * 997) / 1000

    # calculate tokens to transfer
    amountOut: uint256 = (reserveOut * amountInWithFee) / (reserveIn + amountInWithFee)
    tokenOut.transfer(msg.sender, amountOut)

    # update reserves
    self._update(ERC20(self.token0).balanceOf(self), ERC20(self.token1).balanceOf(self))

    # transfer in the tokens
    return amountOut

...

Implementing the factory smart-contract

Let's start with the boilerplate code. We create a file named contracts/AvaSwapFactory.vy, and define the vyper version as 0.3.7. This smart contract is responsible for creating liquidity pools, using two tokens that the user can pass in.

Your smart contract should be looking something like this:

# @version ^0.3.7

###### INTERFACES ######

###### STATE ######

###### CONSTRUCTOR ######

###### METHODS ######

This is empty for now.

First, we are going to define an interface of the pair smart contract that we built previously, the interface itself only needs one method declared, the setup method, since that is what we are going to use to define a pair.

...
###### INTERFACES ######

interface AvaSwapPair:
    def setup(_token0: address, _token1: address): nonpayable

...

After that we are going to declare the state of the smart contract, we need to map the token pairs that we have created, and we need to add an array to store each one of them, also a master pair contract address, this is going to be used as a blueprint by vyper to create and deploy new pair smart contracts.

###### STATE ######
...

# Pair Contract => Token <=> Token
getPair: public(HashMap[address, HashMap[address, address]])

# All pairs list
allPairs: public(DynArray[address, 30])

# AvaSwap Pair contract address used to create clones of it
pairContract: address

...

After that we are going to define the constructor, this part is really important since here is where we pass the address to an empty pair smart contract that we need to deploy before we deploy this one.

###### CONSTRUCTOR ######
...

@external
def __init__(_pairContract: address):
    self.pairContract = _pairContract

...

And that would be everything we need before defining the main createPair method, which will allow our users to create a token pair freely.

Create pair

The create pair method is simple, we pass in two tokens, token A and token B, with these two tokens we deploy a new pair smart contract (using the pairContract state variable we defined in the constructor) and we added to the pairs mapping and the pairs array, and that's it!

###### METHODS ######
...

@external
def createPair(_tokenA: address, _tokenB: address) -> address:
    assert _tokenA != _tokenB, "Avalanche Swap Factory: identical addresses"
    assert _tokenA != empty(address) and _tokenB != empty(address), "Avalanche Swap Factory: zero address"
    assert self.getPair[_tokenA][_tokenB] == empty(address),  "Avalanche Swap Factory: pair exists"

    # create pair smart contract
    pair: address = create_forwarder_to(self.pairContract)
    AvaSwapPair(pair).setup(_tokenA, _tokenB)

    # populate mapping in, and in the reverse direction
    self.getPair[_tokenA][_tokenB] = pair
    self.getPair[_tokenB][_tokenA] = pair

    # append pair to all pairs array
    self.allPairs.append(pair)

    return pair

...

Testing using Brownie

In this tutorial, we are going to use Brownie to test our smart contracts, you can use any other smart contract framework if you are familiar with it Hardhat or ApeWorx both have support for developing and deploying vyper smart contracts.

For this, we are going to create an extra mock ERC20 smart contract, that we are going to use to deploy mocks tokens to test our application.

Create a mock directory inside our contracts folder, and then create an ERC20.vy smart contract inside it.

The contents of that smart contract should look something like this:

# @version ^0.3.7
# @dev Implementation of ERC-20 token standard.

from vyper.interfaces import ERC20
from vyper.interfaces import ERC20Detailed

implements: ERC20
implements: ERC20Detailed

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

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

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


@external
def __init__(_name: String[32], _symbol: String[32], _decimals: uint8, _supply: uint256):
    init_supply: uint256 = _supply * 10 ** convert(_decimals, uint256)
    self.name = _name
    self.symbol = _symbol
    self.decimals = _decimals
    self.balanceOf[msg.sender] = init_supply
    self.totalSupply = init_supply
    self.minter = msg.sender
    log Transfer(empty(address), msg.sender, init_supply)


@external
def transfer(_to : address, _value : uint256) -> bool:
    self.balanceOf[msg.sender] -= _value
    self.balanceOf[_to] += _value
    log Transfer(msg.sender, _to, _value)
    return True


@external
def transferFrom(_from : address, _to : address, _value : uint256) -> bool:
    self.balanceOf[_from] -= _value
    self.balanceOf[_to] += _value

    self.allowance[_from][msg.sender] -= _value
    log Transfer(_from, _to, _value)
    return True


@external
def approve(_spender : address, _value : uint256) -> bool:
    self.allowance[msg.sender][_spender] = _value
    log Approval(msg.sender, _spender, _value)
    return True


@external
def mint(_to: address, _value: uint256):
    assert msg.sender == self.minter
    assert _to != empty(address)
    self.totalSupply += _value
    self.balanceOf[_to] += _value
    log Transfer(empty(address), _to, _value)


@internal
def _burn(_to: address, _value: uint256):
    assert _to != empty(address)
    self.totalSupply -= _value
    self.balanceOf[_to] -= _value
    log Transfer(_to, empty(address), _value)


@external
def burn(_value: uint256):
    self._burn(msg.sender, _value)


@external
def burnFrom(_to: address, _value: uint256):
    self.allowance[_to][msg.sender] -= _value
    self._burn(_to, _value)

After that go to our tests folder and create a conftest.py here we will define all of our fixtures (fixtures act like functions that return a new deployment each time) to test our application. We only need 2 demo tokens to test our AMM.

#!/usr/bin/python3

import pytest


# Demo token for testing purposes only
@pytest.fixture(scope="function")
def test_token(ERC20, accounts):
    return ERC20.deploy("Test Token", "TST", 18, 1e21, {'from': accounts[0]})


# Demo token for testing purposes only
@pytest.fixture(scope="function")
def demo_token(ERC20, accounts):
    return ERC20.deploy("Demo Token", "DEMO", 18, 1e21, {'from': accounts[0]})


@pytest.fixture(scope="function")
def ava_swap_pair(AvaSwapPair, accounts):
    return AvaSwapPair.deploy({'from': accounts[0]})


@pytest.fixture(scope="function")
def ava_swap_factory(AvaSwapFactory, accounts, ava_swap_pair):
    return AvaSwapFactory.deploy(ava_swap_factory.address, {'from': accounts[0]})

After that is setup we can test the main functionality of our AMM, mainly:

Create a liquidity pool (pair)
Add liquidity
Remove liquidity
Swap and collect fees using shares

Now create a file inside our tests folder, called test_amm.py, this will test all the functionality that we defined earlier.

import brownie 
from brownie import AvaSwapPair, Wei

Your file should be looking like that before we begin writing tests. Here we import the AvaSwapPair contract container to interact with the pairs that we create and Wei to manipulate token amounts easily.

Create a liquidity pool

def test_create_pair(accounts, test_token, demo_token, ava_swap_factory):
    # create pair
    tx_create_pair = ava_swap_factory.createPair(test_token.address, demo_token.address, {"from": accounts[0]}) 
    # we access the created pair address
    pair_address = tx_create_pair.return_value
    # we access the pair smart-contract
    pair = AvaSwapPair.at(pair_address)

    # test default pair values
    assert pair.token0() == test_token.address
    assert pair.token1() == demo_token.address
    assert pair.totalSupply() == 0
    assert pair.reserve0() == 0
    assert pair.reserve1() == 0

Add liquidity

def test_add_liquidity(accounts, test_token, demo_token, ava_swap_factory):
    # create pair
    tx_create_pair = ava_swap_factory.createPair(test_token.address, demo_token.address, {"from": accounts[0]}) 
    pair_address = tx_create_pair.return_value
    pair = AvaSwapPair.at(pair_address)

    amount = Wei("1000 ether")

    # approve pair to use our tokens
    test_token.approve(pair_address, amount, {"from": accounts[0]})
    demo_token.approve(pair_address, amount, {"from": accounts[0]})

    # add liquidity
    pair.addLiquidity(amount, amount, {"from": accounts[0]})

    assert pair.balanceOf(accounts[0]) == amount # minted shares
    assert pair.reserve0() == amount
    assert pair.reserve1() == amount
    assert test_token.balanceOf(pair) == amount
    assert demo_token.balanceOf(pair) == amount

Remove liquidity

def test_remove_liquidity(accounts, test_token, demo_token, ava_swap_factory):
    # create pair
    tx_create_pair = ava_swap_factory.createPair(test_token.address, demo_token.address, {"from": accounts[0]}) 
    pair_address = tx_create_pair.return_value
    pair = AvaSwapPair.at(pair_address)

    amount = Wei("1000 ether")

    # approve pair to use our tokens
    test_token.approve(pair_address, amount, {"from": accounts[0]})
    demo_token.approve(pair_address, amount, {"from": accounts[0]})

    # add liquidity
    pair.addLiquidity(amount, amount, {"from": accounts[0]})

    assert pair.balanceOf(accounts[0]) == amount # minted shares
    assert pair.reserve0() == amount
    assert pair.reserve1() == amount
    assert test_token.balanceOf(pair) == amount
    assert demo_token.balanceOf(pair) == amount

    # get shares
    shares = pair.balanceOf(accounts[0])

    # remove liquidity
    pair.removeLiquidity(shares, {"from": accounts[0]})

    assert pair.balanceOf(accounts[0]) == 0 # minted shares
    assert pair.reserve0() == 0
    assert pair.reserve1() == 0
    assert test_token.balanceOf(pair) == 0
    assert demo_token.balanceOf(pair) == 0

Swap and collect fees using shares

def test_remove_liquidity(accounts, test_token, demo_token, ava_swap_factory):
    # create pair
    tx_create_pair = ava_swap_factory.createPair(test_token.address, demo_token.address, {"from": accounts[0]}) 
    pair_address = tx_create_pair.return_value
    pair = AvaSwapPair.at(pair_address)

    amount = Wei("1000 ether")
    swap_amount = Wei("100 ether")

    # approve pair to use our tokens
    test_token.approve(pair_address, amount, {"from": accounts[0]})
    demo_token.approve(pair_address, amount, {"from": accounts[0]})

    # add liquidity
    pair.addLiquidity(amount, amount, {"from": accounts[0]})

    # initial balance before swap
    initial_balances = {
        "test_token": test_token.balanceOf(accounts[0]),
        "demo_token": demo_token.balanceOf(accounts[0])
    }

    # approve token in
    test_token.approve(pair_address, swap_amount, {"from": accounts[0]})
    # swap
    pair.swap(test_token.address, swap_amount, {"from": accounts[0]})

    balances = {
        "test_token": test_token.balanceOf(accounts[0]),
        "demo_token": demo_token.balanceOf(accounts[0])
    }

    # test that we swapped tokens correctly
    assert initial_balances["demo_token"] < balances["demo_token"]
    assert initial_balances["test_token"] > balances["test_token"]

    # get shares
    shares = pair.balanceOf(accounts[0])

    # remove liquidity
    pair.removeLiquidity(shares, {"from": accounts[0]})

    assert pair.balanceOf(accounts[0]) == 0 # minted shares
    assert pair.reserve0() == 0
    assert pair.reserve1() == 0
    assert test_token.balanceOf(pair) == 0
    assert demo_token.balanceOf(pair) == 0

    balances = {
        "test_token": test_token.balanceOf(accounts[0]),
        "demo_token": demo_token.balanceOf(accounts[0])
    }

    # test that we swapped tokens correctly
    assert initial_balances["demo_token"] < balances["demo_token"]
    assert initial_balances["test_token"] < balances["test_token"]

To run our tests, on your terminal run the following command:

$ brownie test --network hardhat

This will test our smart contracts on the hardhat local node.

That would be it, we can extend our testing to include every possible scenario, but we will not cover that in this tutorial.

Deploy using Brownie

In this tutorial, we are going to use Brownie to deploy our smart contracts, you can use any other smart contract framework if you are familiar with it Hardhat or ApeWorx both have support for developing and deploying vyper smart contracts.

Since we are deploying to Avalanche, we need to add the Avalanche mainnet and the Avalanche Fuji testnet to our supported networks. In our terminal type the following:

$ brownie networks add Avalanche avax-testnet host=https://api.avax-test.network/ext/bc/C/rpc chainid=43113 explorer=https://testnet.snowtrace.io/ name=Fuji

$ brownie networks add Avalanche avax-mainnet host=https://api.avax.network/ext/bc/C/rpc chainid=43114 explorer=https://snowtrace.io/ name=Mainnet

After we run these two commands brownie will add Avalanche to Brownie.

Avalanche
  ├─Mainnet: avax-mainnet
  └─Fuji: avax-testnet

After that is complete, you can write our deploy script.

Our script is really simple we are going to take our two smart contracts, and deploy them both, first, we need to deploy the pair smart contract since the factory smart contract needs a reference to that one.

Our script will first check if we are on any of the Avalanche networks, and if so will deploy the smart contracts using a real wallet (with some AVAX in it), if not we will assume that we are on our local network and deploy them there.

To deploy to a live blockchain (Fuji or Mainnet) we need to have a wallet with some AVAX on it, you can get some testnet AVAX tokens on this faucet. Also, we need to define our brownie-config.yaml file to let Brownie know where to find our private key, and some important configurations as well.

Create a brownie-config.yaml on the root of your project. It should look something like this.

dotenv: .env

networks:
  default: hardhat

wallets:
  from_key: ${PRIVATE_KEY}

compiler:
  vyper:
    version: "0.3.7"

The configuration file is expecting a .env file to work properly, create one on the root of your project and populate it with this.

PRIVATE_KEY="YOUR_PRIVATE_KEY_HERE"

After we have our configuration setup, we need to write our deploy script. On the scripts folder create a new file called deploy.py this python program will be responsible for deploying our smart contracts.

The deploy.py file should look something like this:

from brownie import accounts, network, config, AvaSwapFactory, AvaSwapPair


def main():
    supported_networks = ["avax-mainnet", "avax-testnet"]
    active_network = network.show_active()

    if active_network in supported_networks:
        deployer = accounts.add(config["wallets"]["from_key"])
    else:
        deployer = accounts[0]

    ava_swap_pair = AvaSwapPair.deploy({"from": deployer}) 
    ava_swap_factory = AvaSwapFactory.deploy(ava_swap_pair.address, {"from": deployer})

To run this script write the following command on your terminal, this will deploy the contract to your hardhat local node.

$ brownie run deploy

To deploy it to a testnet write the following one.

$ brownie run deploy --network avax-testnet

And to deploy them to the Avalanche mainnet run the following command:

$ brownie run deploy --network avax-mainnet

And that would be it on the smart contract side, we created, tested, and deployed our AMM smart contracts.

Conclusion

Constant Product Market Maker (CAMM): The standard in Decentralized Finance

Rafael Abuawad — Wed, 11 Jan 2023 21:41:48 +0000

Decentralized finance (DeFi) has been gaining a lot of momentum in recent years, and Automated Market Maker (AMM) has been a key technology driving this trend. AMMs are decentralized exchanges (DEXs) that allow users to trade cryptocurrencies without the need for an intermediary. However, a breed of AMM called Constant Product Market Maker (CPMM) is the dominant implementation DeFi space.

How CPMMs are useful

CPMMs are useful for several reasons:

Efficient liquidity provision: CPMMs are designed to provide liquidity more efficiently than traditional AMMs. They do this by using a constant product formula which ensures that the liquidity pool is always in a balanced state, no matter how much the prices fluctuate. This results in lower slippage for users and more predictable pricing for traders.

Lower impermanent loss: Traditional AMMs can have a problem called impermanent loss (IL) where liquidity providers can experience a loss if the price of the asset changes. CPMMs, on the other hand, have a lower IL, as the constant product formula helps to minimize the impact of price fluctuations on liquidity providers.

Better token price stability: CPMMs are better suited for stablecoin markets as they are less sensitive to price fluctuations, ensuring a more stable token price.

A Code Sample

Here is an example of a simple CPMM smart contract, written in the Vyper programming language:

# @version >=0.3.3
from vyper.interfaces import ERC20

token0: public(address)
token1: public(address)

reserve0: public(uint256)
reserve1: public(uint256)

totalSupply: public(uint256)
balanceOf: HashMap[address, uint256]


@external
def __init__(_token0: address, _token1: address):
    self.token0 = _token0
    self.token1 = _token1


@internal
def _mint(_to: address, _amount: uint256):
    self.balanceOf[_to] += _amount
    self.totalSupply += _amount


@internal
def _burn(_from: address, _amount: uint256):
    self.balanceOf[_from] -= _amount
    self.totalSupply -= _amount


@internal
def _update(_reserve0: uint256, _reserve1: uint256):
    self.reserve0 = _reserve0
    self.reserve1 = _reserve1


@external
def swap(_tokenIn: address, _amountIn: uint256) -> uint256:
    assert _tokenIn == self.token0 or _tokenIn == self.token1, "invalid token" 
    assert _amountIn > 0, "amount in is zero"

    tokenIn: ERC20 = empty(ERC20)
    tokenOut: ERC20 = empty(ERC20)
    reserveIn: uint256 = 0
    reserveOut: uint256 = 0

    if _tokenIn == self.token0:
        tokenIn = ERC20(self.token0)
        tokenOut = ERC20(self.token1)
        reserveIn = self.reserve0
        reserveOut = self.reserve1
    else:
        tokenIn = ERC20(self.token1)
        tokenOut = ERC20(self.token0)
        reserveIn = self.reserve1
        reserveOut = self.reserve0

    tokenIn.transferFrom(msg.sender, self, _amountIn)

    amountInWithFee: uint256 = (_amountIn * 997) / 1000
    amountOut: uint256 = (reserveOut * amountInWithFee) / (reserveIn + amountInWithFee)

    tokenOut.transfer(msg.sender, amountOut)
    self._update(ERC20(self.token0).balanceOf(self), ERC20(self.token1).balanceOf(self))

    return amountOut


@external
def addLiquidity(_amount0: uint256, _amount1: uint256) -> uint256:
    ERC20(self.token0).transferFrom(msg.sender, self, _amount0)
    ERC20(self.token1).transferFrom(msg.sender, self, _amount1)

    if self.reserve0 > 0 or self.reserve1 > 0:
        assert self.reserve0 * _amount1 == self.reserve1 * _amount0, "x / y != dx / dy"

    shares: uint256 = 0
    if self.totalSupply == 0:
        shares = isqrt(_amount0 * _amount1)
    else:
        shares = min(
            (_amount0 * self.totalSupply) / self.reserve0,
            (_amount0 * self.totalSupply) / self.reserve0,
        )

    assert shares > 0, "shares are zero"
    self._mint(msg.sender, shares)

    return shares


@external
def removeLiquidity(_shares: uint256) -> (uint256, uint256):
    bal0: uint256 = ERC20(self.token0).balanceOf(self)
    bal1: uint256 = ERC20(self.token1).balanceOf(self)

    amount0: uint256 = (_shares * bal0) / self.totalSupply
    amount1: uint256 = (_shares * bal1) / self.totalSupply
    assert amount0 > 0 and amount1 > 0, "amount0 or amount is zero"

    self._burn(msg.sender, _shares)
    self._update(bal0 - amount0, bal1 - amount1)

    ERC20(self.token0).transfer(msg.sender, amount0)
    ERC20(self.token1).transfer(msg.sender, amount1)

    return (amount0, amount1)

This example is quite basic, most real-world AMM smart contracts use more complex mechanisms to calculate prices and determine the amounts of assets that are exchanged in a trade.

In the code above the contract provide the functionality to deposit, withdraw and trade assets on a pool, the trading functionality uses the current state of the pool to determine the amounts of assets that are exchanged, you could use a different mechanism to price the assets like a constant product or a bonding curve.

Please keep in mind that, this is just a sample code, it should not be used in production as is, it lacks many important aspects such

Create a Wrapped ERC20 token on Avalanche with Vyper! 🐍🪙

Rafael Abuawad — Thu, 01 Dec 2022 03:14:24 +0000

Introduction

In this article, we will describe the use cases of an ERC20 token and explain how to create one from scratch using Vyper, and we will deploy it to the Avalanche Fuji test network.

Prerequisites

Basic programming and console/terminal use experience
A simple understanding of Solidity or Vyper

Requirements

NodeJS
Python and Brownie ETH, or any smart contract framework
VSCode, or another code editor

What is an ERC20?

An ERC20 smart contract keeps track of fungible tokens, and the contract itself allows us to transfer, burn, and do much interesting stuff with that particular token.

The interface itself is really simple and doesn't include a lot of information about the token itself.

# Functions
totalSupply()
balanceOf(account)
transfer(to, amount)
allowance(owner, spender)
approve(spender, amount)
transferFrom(from, to, amount)

These six functions are the original function defined on the EIP20, we can extend a lot of functionality by adding more functions (more features) to our smart contract.

In this article we are going to create an ERC20 smart contract, that takes in AVAX and returns WAVAX, our wrapped implementation of the cryptocurrency.

We are going to allow the users to mint tokens by depositing AVAX and burn tokens and get AVAX in return.

Why they are important?

Tokens are a fundamental part of the web3 space, they can be used in a lot of creative and unique ways, like shares in a community, transactional value, currency in a protocol, and much more. In this tutorial, we are going to create a token that wraps a cryptocurrency (AVAX in this case) and that token can be used in defi protocols, web3 protocols, and more.

Setup

We are going to use Brownie in this tutorial, after you installed Brownie, create a new folder called avalanche-swap and inside it run the following command:

$ brownie init

Also, we are going to be using the Hardhat node to test our smart contracts, so inside your project folder, run the following command:

$ npm install --save-dev hardhat

Smart contract

Let's start with the boilerplate code. We create a file named contracts/WAVAX.vy, define the vyper version as >= 0.3.7, and import the ERC20 and ERC20 Detailed interfaces from vyper.

# @version >=0.3.7

from vyper.interfaces import ERC20
from vyper.interfaces import ERC20Detailed

implements: ERC20
implements: ERC20Detailed

Events

We need to define our events, these are messages that the smart contract emits when called and the ones that we're defining at what the EIP20 proposed.

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

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

State

Our smart contract needs state, or variables that will persist across the entire life of the smart contract. These variables contain information that is going to be useful to our users and to the methods that we will define below, like balanceOf, totalSupply, and allowance

# @dev name of the token ("Wrapped AVAX")
name: public(String[32])

# @dev symbol or ticker of the token ("WAVAX")
symbol: public(String[32])

# @dev the amount of decimals the token contains
decimals: public(uint8)

# @dev the balance of a particular address
balanceOf: public(HashMap[address, uint256])

# @dev addresses can allow other's addresses to spend their tokens
allowance: public(HashMap[address, HashMap[address, uint256]])

# @dev the number of tokens in circulation
totalSupply: public(uint256)

As you can see we define a variable to store how many decimals our token will have, this is because Solidity, the main programming langue used on EVM blockchains, has no support for using decimals, and we define decimals like integers, for example, we want to use 2 decimals, to express the number 100.99, we would put it like this 10099, being the last to digits the actual decimal part.

Constructor

After that is complete we now define the constructor. Here we specify the name of the token, the symbol, and the number of decimals this token will have.

@external
def __init__():
    self.name = "Wrapped AVAX"
    self.symbol = "WAVAX"
    self.decimals = 18

Internal methods

The internal methods are really simple we need a method to mint our Wrapped AVAX tokens if the user sends the amount that they want and on to burn them to retrieve their tokens.

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

@internal
def _burn(_to: address, _value: uint256):
    assert _to != empty(address)
    self.totalSupply -= _value
    self.balanceOf[_to] -= _value
    send(_to, _value)
    log Transfer(_to, empty(address), _value)

These two methods are standard on ERC20 implementations, since we need a way to mint the tokens, and (if we choose so) burn them as well.

External methods

We now need to define the main methods of an ERC20 token, transfer, transferFrom, and approve. These three methods allow our token holders to use the tokens however they want.

The transfer method is self-explanatory and allows the token holder to transfer tokens to another user or a smart contract.

@external
def transfer(_to : address, _value : uint256) -> bool:
    self.balanceOf[msg.sender] -= _value
    self.balanceOf[_to] += _value
    log Transfer(msg.sender, _to, _value)
    return True

The token standard needs a approve method, to enable the transferFrom method that we define next. The approve method gives the token holder a way to allow another account to manage a defined amount of tokens for them.

@external
def approve(_spender : address, _value : uint256) -> bool:
    self.allowance[msg.sender][_spender] = _value
    log Approval(msg.sender, _spender, _value)
    return True

And the transferFrom method gives the user the ability to another account to transfer tokens on behalf of the token holder or to manage a set amount of tokens for them.

@external
def transferFrom(_from : address, _to : address, _value : uint256) -> bool:
    self.balanceOf[_from] -= _value
    self.balanceOf[_to] += _value

    self.allowance[_from][msg.sender] -= _value
    log Transfer(_from, _to, _value)
    return True

Since this is a wrapped token, we need a way to receive the cryptocurrency that we are trying to wrap and mint an equivalent amount of tokens, and also a way to do this in reverse, burn several tokens and receive the equivalent cryptocurrency back.

For the mint method, the user sends some cryptocurrency with the method call and gets the same amount back in tokens.

@external
@payable
def mint():
    self._mint(msg.sender, msg.value)

And for the burn method, the user passes the number of tokens they want to burn, to receive the equivalent in cryptocurrency.

@external
def burn(_value: uint256):
    self._burn(msg.sender, _value)

We will also define a default method, this method will be triggered if a user sends some AVAX to the contract directly, without calling the mint function. And in turn, the contract will mint that user the equivalent in tokens.

@external
@payable
def __default__():
    self._mint(msg.sender, msg.value)

And that would be it. Now we have a token smart contract, that mints wrapped tokens. Yours should look something like this:

# @version >=0.3.7

from vyper.interfaces import ERC20
from vyper.interfaces import ERC20Detailed

implements: ERC20
implements: ERC20Detailed

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

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

# @dev name of the token ("Wrapped AVAX")
name: public(String[32])

# @dev symbol or ticker of the token ("WAVAX")
symbol: public(String[32])

# @dev the amount of decimals the token contains
decimals: public(uint8)

# @dev the balance of a particular address
balanceOf: public(HashMap[address, uint256])

# @dev addresses can allow other's addresses to spend their tokens
allowance: public(HashMap[address, HashMap[address, uint256]])

# @dev the number of tokens in circulation
totalSupply: public(uint256)


@external
def __init__():
    self.name = "Wrapped AVAX"
    self.symbol = "WAVAX"
    self.decimals = 18


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


@internal
def _burn(_to: address, _value: uint256):
    assert _to != empty(address)
    self.totalSupply -= _value
    self.balanceOf[_to] -= _value
    send(_to, _value)
    log Transfer(_to, empty(address), _value)


@external
def transfer(_to : address, _value : uint256) -> bool:
    self.balanceOf[msg.sender] -= _value
    self.balanceOf[_to] += _value
    log Transfer(msg.sender, _to, _value)
    return True


@external
def approve(_spender : address, _value : uint256) -> bool:
    self.allowance[msg.sender][_spender] = _value
    log Approval(msg.sender, _spender, _value)
    return True


@external
def transferFrom(_from : address, _to : address, _value : uint256) -> bool:
    self.balanceOf[_from] -= _value
    self.balanceOf[_to] += _value

    self.allowance[_from][msg.sender] -= _value
    log Transfer(_from, _to, _value)
    return True


@external
@payable
def mint():
    self._mint(msg.sender, msg.value)


@external
def burn(_value: uint256):
    self._burn(msg.sender, _value)


@external
@payable
def __default__():
    self._mint(msg.sender, msg.value)

Deploy using Brownie

Since we are deploying to Avalanche, we need to add the Avalanche mainnet and the Avalanche Fuji testnet to our supported networks. In our terminal type the following:

$ brownie networks add Avalanche avax-testnet host=https://api.avax-test.network/ext/bc/C/rpc chainid=43113 explorer=https://testnet.snowtrace.io/ name=Fuji

$ brownie networks add Avalanche avax-mainnet host=https://api.avax.network/ext/bc/C/rpc chainid=43114 explorer=https://snowtrace.io/ name=Mainnet

After we run these two commands brownie will add Avalanche to Brownie.

Avalanche
  ├─Mainnet: avax-mainnet
  └─Fuji: avax-testnet

After that is complete, you can write our deploy script.

Our script is really simple we are going to take our smart contract, and deploy it.

Create a brownie-config.yaml on the root of your project. It should look something like this.

dotenv: .env

networks:
  default: hardhat

wallets:
  from_key: ${PRIVATE_KEY}

compiler:
  vyper:
    version: "0.3.7"

The configuration file is expecting a .env file to work properly, create one on the root of your project and populate it with this.

PRIVATE_KEY="YOUR_PRIVATE_KEY_HERE"

The deploy.py file should look something like this:

from brownie import accounts, network, config, WAVAX


def main():
    supported_networks = ["avax-mainnet", "avax-testnet"]
    active_network = network.show_active()

    deployer = accounts[0]
    if active_network in supported_networks:
        deployer = accounts.add(config["wallets"]["from_key"])

    WAVAX.deploy({"from": deployer})

To run this script write the following command on your terminal, this will deploy the contract to your hardhat local node.

$ brownie run deploy

To deploy it to a testnet write the following one.

$ brownie run deploy --network avax-testnet

And to deploy them to the Avalanche mainnet run the following command:

$ brownie run deploy --network avax-mainnet

And that would be it on the smart contract side, we created, tested, and deployed our wrapped token smart contract.

Testnet smart contract (Fuji)

WAVAX

DEV Community: Rafael Abuawad

Staking rewards are just an accumulator (Vyper 🐍)

The naive way

Lazy accounting

Setup

Installing Moccasin

Project setup

Staking Rewards

The index

Pool interactions

Extra views

Final notes

Create your own Uniswap DeFi Application🦄! From scratch using Vyper & Python🐍

Introduction

What is an AMM?

Setup project

Smart contract development

UviswapPair

Add liquidity

Remove liquidity

Swap

UviswapFactory

Create pair

Testing

🧪 Creating a Liquidity Pool

🧪 Adding liquidity to the Pool

🧪 Removing liquidity from the Pool

🧪 Swapping assets

🧪 Collecting fees

Scripts

Accounts

Conclusion

Uviswap GitHub Repository

Challenge #2: 🪙 Multi Token Vendor | Speedrun Ethereum With Vyper

Table of contents

🪙 Introductionn

📦 Setup

Brownie

ApeWorx

📑 Code

Token (ERC-1155)

🔬 Conclusion

Challenge #1: 🥩 Decentralized Staking App | Speedrun Ethereum With Vyper 🐍

Table of contents

🥩 Introductionn

📦 Setup

Brownie

ApeWorx

📑 Code

Token (ERC-20)

🔬 Conclusion

Challenge #0: 🖼️ Simple NFT Example | Speedrun Ethereum With Vyper 🐍

Table of contents

🎟 Introduction

📦 Setup

Brownie

ApeWorx

📑 Code

Non-Fungible Token (ERC-721)

🔬 Conclusion

Understanding Chainlink VRF: A Tool for Random Number Generation on the Blockchain

What is Chainlink VRF?

Conclusion

Understanding Polygon: The L2 Scaling Solution for Ethereum

Svelte for Beginners: A Beginner's Guide to Building Web Applications

Setting up Svelte

Working with Reactive State

Working with forms

Working with Stores

Create a blockchain asset tracking system using an ERC-721-inspired smart contract!

Introduction

Solving this problem

Smart-contracts

Interfaces

Smart-contract

Create an Automated Market Maker (AMM) with Vyper! 🐍

Introduction

Prerequisites

Requirements

What is an AMM?