Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
---
title: Introduction
description: chapter outline and learning goals
updated: 2025-08-21
authors: [nicolasarnedo]
icon: Book
---

## What You Will Learn

This foundational section covers the essential concepts of blockchain tokens:

- **Token Fundamentals**: How tokens represent ownership and value
- **Token Design**: Technical parameters that shape token behavior
- **Native Tokens**: Primary blockchain currencies and their roles
- **ERC-20 Tokens**: Standardized smart contract tokens for DeFi
- **Practical Skills**: Deploy and transfer ERC-20 tokens

## Learning Goals

By the end of this section, you will understand:
- What native and ERC-20 tokens are and how they work
- How to design tokens with appropriate technical parameters
- How to deploy and transfer ERC-20 tokens

The next section will cover the key differences between native and ERC-20 tokens, including wrapped tokens.

Let's get started!

This file was deleted.

Original file line number Diff line number Diff line change
@@ -1,9 +1,9 @@
---
title: Native vs ERC20 Tokens
title: Key Differences
description: Learn the key differences between native tokens and ERC20 tokens on Avalanche L1s
updated: 2025-01-15
authors: [nicolasarnedo]
icon: BookOpen
icon: Book
---

Before moving forward, and now that we have seen both, it's crucial to understand the fundamental differences between native tokens and ERC20 tokens. Each has distinct characteristics that affect how they function within your blockchain ecosystem.
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
---
title: Introduction
description: Chapter overview and core blockchain concepts review
updated: 2025-01-15
authors: [nicolasarnedo]
icon: Book
---

In this section we are going to quickly address what Precompiles are, why we need them and how they are implemented. The reason we cover this in the L1 Native Tokenomics course is because in the next two sections we will be working with 2 precompiles that heavily influence the tokenomics of a chain, the [Native Minter](/l1-native-tokenomics/04-native-minter) and [Fee Config](/l1-native-tokenomics/05-fee-config) Precompiles.

Specifically we are going to look into **Stateful Precompiles**, but if you wish to learn more in detail about Precompiles and how you can use them to configure your L1 please check out the [Customizing the VM](/customizing-evm) course!

## Core Concepts Review (Optional)

Before we look more closely into precompiles, it is important we re-visit and fully understand some core concepts about how blockchains and virtual machines work.

### Deterministic State Transitions

Blockchains rely on a **deterministic machine (the EVM)** to calculate transitions from one state to the next. Every transaction modifies the blockchain state in a predictable, reproducible way—ensuring all nodes reach consensus on the new state.

![State Transitions](https://qizat5l3bwvomkny.public.blob.vercel-storage.com/Precompiles_State.png)

### EVM as a Configurable Specification

Think of the EVM like a class in Object-Oriented Programming: it's a specification that defines behavior. Each blockchain—Ethereum, Avalanche C-Chain, or your custom L1—is an **instance** of this EVM class, with its own configuration.

![EVM Instances](https://qizat5l3bwvomkny.public.blob.vercel-storage.com/Precompiles_OOP.png)

**Through Avalanche, you can configure your EVM instance with precompiles that live at the execution level** (will dive deeper into this later), giving you control over core blockchain functionality like native token minting and transaction fee configuration.
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
---
title: Stateful Precompiles
description: Understanding Stateful Precompiles and their role in blockchain optimization
updated: 2025-01-15
authors: [nicolasarnedo]
icon: BookOpen
---

First of all we will start by saying the notion of precompiles contracts, or "*Precompiles*" as we are calling them, is something inherited from the Ethereum community. The EVM, while very robust and efficient for handling thousands of simple transactions like token minting, swapping or so, has a series of limitations:

### Lack of Libraries

Solidity is a relatively new language, hence it doesn't have as many powerful and battle-tested libraries as other languages like *Go*, *Typescript* or *Rust*

### Expensive Computation

Solidity code is compiled into EVM opcodes—low-level instructions designed for simple operations like addition, storage reads, and basic logic.

When performing complex mathematical operations (like elliptic curve cryptography or modular exponentiation), these simple opcodes must be chained together, requiring many steps and frequent use of expensive operations like `SSTORE` (storage writes) which cost 20,000 gas or more. This makes advanced cryptography impractically expensive in pure Solidity

## Basic Precompiles

Given these limitations - many developer teams/communities have proposed creating programs written in more efficient languages (Go/Rust) for well-known or frequently used operations that may temporarily by-pass the limitations of the smart contract language of that blockchain. These "programs" are then wrapped in a interface (solidity/move) and deployed to a pre-defined address so they can be called from other smart contracts in the application layer.

<img src="https://qizat5l3bwvomkny.public.blob.vercel-storage.com/precompile_strucutre.png" alt="Precompiles Structure" style={{ maxWidth: '60%', height: 'auto', margin: '0 auto', display: 'block' }} />

Instances of these Precompiles exists across most major blockchain platforms:
- Ethereum has standard precompiles at fixed addresses
- Solana uses "Native Programs" written in Rust
- Aptos and Sui have "Native Functions" exposed through Move modules

For Avalanche, these precompiles are especially important because you are the **owner** of your L1. Rather than having to go through several community approvals (the case for single-chain environments like Ethereum and Solana) and executing a network upgrade to implement them, you can directly define them in the genesis block! (*or add them as well through a network upgrade*)

### Common Precompiles

Here are some of the most widely used precompiles across EVM-compatible blockchains:

**Cryptographic Operations:**
- `ecRecover` (0x01): Recover Ethereum address from ECDSA signature
- `SHA256` (0x02): SHA-256 hash function

## Stateful Precompiles

The basic precompiles we've discussed so far (like ecRecover and SHA256) are **stateless**—they perform computations and return results without modifying the blockchain state. However, Avalanche introduces a more powerful concept: **Stateful Precompiles**.

Stateful precompiles go a step further by **injecting state access** through the `PrecompileAccessibleState` interface. This gives them the ability to:
- Read and modify account balances
- Read and write to contract storage
- Access the full EVM state during execution

This state access makes stateful precompiles far more powerful than their stateless counterparts. Instead of just performing calculations, they can directly manipulate blockchain state at the protocol level—enabling use cases like native token minting, fee configuration, and transaction/contract deployer permissioning.

Through stateful precompiles, Avalanche provides a level of EVM customization that goes beyond what's possible with the original precompile interface, making it ideal for building highly customized L1 blockchains.
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
---
title: Protocol Integration
description: How precompiles integrate with the VM stack and optimize execution
updated: 2025-01-15
authors: [nicolasarnedo]
icon: BookOpen
---

Blockchains are organized into three distinct layers, each with specific responsibilities:

![Blockchain Layers](https://qizat5l3bwvomkny.public.blob.vercel-storage.com/Precompiles_Layers1.png)

1. **Application Layer**: Where smart contracts and user applications run
2. **Execution Layer**: Where the EVM processes transactions and executes code
3. **Consensus Layer**: Where validators agree on the blockchain state

Precompiles live in the **Execution Layer**, directly integrated into the EVM itself:

![Precompiles in Execution Layer](https://qizat5l3bwvomkny.public.blob.vercel-storage.com/Precompiles_Layers2.png)

## Why Aren't Precompiles in the Application Layer?

You might wonder: if precompiles can be called like smart contracts, why aren't they stored with other smart contracts in the application layer?

The answer comes down to **performance and access**:

**1. Direct State Access**
Smart contracts in the application layer must go through the EVM interpreter to access blockchain state. Precompiles, living in the execution layer, have **direct access** to the EVM state—they can read and modify balances, storage, and consensus data without the overhead of bytecode interpretation.

**2. Native Code Execution**
Application layer contracts are compiled to EVM bytecode and executed opcode-by-opcode. Precompiles are written in Go (Avalanche's client language) and execute as **native code**, making them orders of magnitude faster for complex operations.

**3. Protocol-Level Operations**
Precompiles need to perform operations that regular smart contracts cannot or should not do—like minting native tokens, configuring transaction fees, or managing validator permissions. These are **protocol-level concerns** that require execution layer access.

**4. Security Boundaries**
By keeping precompiles in the execution layer, we maintain a clear security boundary. User-deployed contracts can't interfere with protocol operations, and protocol operations benefit from the stability and security of the client software itself.

This architectural separation is what makes stateful precompiles so powerful: they bridge the gap between user applications and the blockchain protocol, enabling customizations that would be impossible in the application layer alone.

This file was deleted.

6 changes: 5 additions & 1 deletion content/academy/l1-native-tokenomics/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -24,4 +24,8 @@ By the end of this course, you will:
- **Design Token Distribution**: Create effective vesting schedules, bonding curves, and airdrop strategies for your native tokens.
- **Implement Governance**: Develop governance structures including DAOs and quadratic voting models for decentralized decision-making.

But before getting into all of this, let's take a moment to think about whether you actually need to create an L1 with it's own native token for you use-case.
But before diving into the technical implementation, we've included two essential think pieces to help you make informed decisions:

**Essential Reading**: [Dapp vs L1](/academy/l1-native-tokenomics/dapp-vs-l1) - A critical analysis to determine whether your use case actually requires its own L1 with native tokenomics, or if deploying on an existing chain would be more appropriate.

**Highly Recommended**: [Token Ownership](/academy/l1-native-tokenomics/token-ownership) - Not strictly necessary for implementation, this deep dive into the philosophical and practical aspects of token ownership will give you a much richer understanding of the underlying concepts at play in tokenomics design.
15 changes: 10 additions & 5 deletions content/academy/l1-native-tokenomics/meta.json
Original file line number Diff line number Diff line change
Expand Up @@ -5,14 +5,19 @@
"pages": [
"index",
"dappVsL1",
"---Token 101---",
"...01-tokens101",
"token-ownership",
"---Token Fundamentals---",
"...01-tokens-fundamentals",
"---Native vs ERC20 Tokens---",
"...01b-native-vs-erc20",
"---Custom Native Tokens---",
"...02-custom-tokens",
"---Precompiles---",
"...03-precompiles",
"---Distribution---",
"...09-token-distribution",
"...07-token-distribution",
"---Governance---",
"...10-governance",
"More coming soon..."
"...08-governance",
"Certificate Coming Soon..."
]
}
Original file line number Diff line number Diff line change
@@ -1,9 +1,9 @@
---
title: Tokens Ownership
title: Token Ownership
description: Everything you need to know about token ownership on blockchains
updated: 2025-08-21
authors: [nicolasarnedo]
icon: BookOpen
icon: Key
---

## A Short History and Why It Matters
Expand Down
Loading