diff --git a/app/backup.ico b/app/backup.ico new file mode 100644 index 00000000..f5a500ed Binary files /dev/null and b/app/backup.ico differ diff --git a/app/favicon.ico b/app/favicon.ico index f5a500ed..ecde3034 100644 Binary files a/app/favicon.ico and b/app/favicon.ico differ diff --git a/app/layout.client.tsx b/app/layout.client.tsx index f47c547c..590dee68 100644 --- a/app/layout.client.tsx +++ b/app/layout.client.tsx @@ -3,8 +3,62 @@ import type { ReactNode } from 'react'; export function Title(): React.ReactElement { - const svgCode = '' - + const svgCode = ` + + + +` return ( <> logo diff --git a/components/quizzes/courses/l1-tokenomics.json b/components/quizzes/courses/l1-tokenomics.json new file mode 100644 index 00000000..35626a4d --- /dev/null +++ b/components/quizzes/courses/l1-tokenomics.json @@ -0,0 +1,137 @@ +{ + "201": { + "question": "Which function is used to allow another account to transfer tokens on your behalf?", + "options": [ + "transfer()", + "approve()", + "transferFrom()", + "allowance()" + ], + "correctAnswers": [ + 1 + ], + "hint": "This function sets an approval limit for token transfers by a third party.", + "explanation": "The approve() function allows another account to spend tokens on your behalf up to a specified amount.", + "chapter": "ERC-20 Tokens" + }, + "202": { + "question": "What is the primary purpose of wrapping a native token into an ERC-20 token?", + "options": [ + "To increase its supply", + "To burn the native token", + "To make the native token compatible with the ERC-20 standard", + "To mint more native tokens" + ], + "correctAnswers": [ + 2 + ], + "hint": "Wrapping allows the native token to be used in decentralized applications that require ERC-20 tokens.", + "explanation": "The wrapping process makes native tokens (like ETH, AVAX) compatible with the ERC-20 standard, enabling their use in dApps and DeFi protocols.", + "chapter": "Wrapped Native Tokens" + }, + "203": { + "question": "What is the primary advantage of using a custom native token in a blockchain?", + "options": [ + "It automatically increases in value over time", + "It can only be used for test environments", + "It eliminates the need for validators", + "It allows for more control over transaction fees and tokenomics" + ], + "correctAnswers": [ + 3 + ], + "hint": "Custom native tokens give developers flexibility in managing blockchain economics.", + "explanation": "A custom native token allows developers to control transaction fees, design tokenomics, and tailor the blockchain’s fee structure to meet specific needs.", + "chapter": "Custom Native Tokens" + }, + "204": { + "question": "What is the AllowList used for when configuring the Native Minter Precompile?", + "options": [ + "To set transaction fees for using the native token", + "To control which addresses are allowed to mint native tokens", + "To limit the total number of native tokens that can be minted", + "To freeze minting of native tokens" + ], + "correctAnswers": [ + 1 + ], + "hint": "The allow list determines which addresses have permission to interact with the precompiled contract.", + "explanation": "The AllowList is used to specify which addresses have the permission to mint native tokens or manage the minting process.", + "chapter": "Activating Native Minter Precompile" + }, + "205": { + "question": "What is the main advantage of a multi-chain ecosystem?", + "options": [ + "It reduces the security of the blockchain.", + "It increases the gas fees.", + "It enables tokens and assets to be transferred across multiple blockchains.", + "It restricts interoperability between different blockchains." + ], + "correctAnswers": [ + 2 + ], + "hint": "Think about the ability of assets and tokens to move freely across multiple chains.", + "explanation": "The key benefit of a multi-chain ecosystem is that it allows tokens, assets, and data to be transferred between different blockchains, promoting interoperability.", + "chapter": "Cross-Chain Ecosystems" + }, + "206": { + "question": "What role does Avalanche play in enabling multi-chain ecosystems?", + "options": [ + "It provides a single-chain environment for transactions.", + "It limits token usage to the native chain.", + "It supports seamless cross-chain communication with tools like L1s and ICTT.", + "It prevents interoperability between its L1s and other chains." + ], + "correctAnswers": [ + 2 + ], + "hint": "Avalanche is known for its ability to support cross-chain communication and interoperability through its architecture.", + "explanation": "Avalanche's architecture, including its L1s and Interchain Token Transfers (ICTT), is designed to support seamless cross-chain communication and interoperability between different blockchain networks.", + "chapter": "Cross-Chain Ecosystems" + }, + "207": { + "question": "Which contract must be granted minting rights for the ERC-20 token to be used as a native token on a new L1 chain?", + "options": [ + "NativeTokenRemote contract", + "ERC-20 Home contract", + "ERC-712 contract", + "L1 governance contract" + ], + "correctAnswers": [ + 0 + ], + "hint": "This contract mints native tokens on the destination chain after ERC-20 tokens are transferred.", + "explanation": "The NativeTokenRemote contract must be granted minting rights to allow the native token to be minted on the new L1 after ERC-20 tokens are transferred from the source chain.", + "chapter": "Use ERC-20 as Native Token" + }, + "208": { + "question": "Why is collateralization important in transferring native tokens between L1 chains?", + "options": [ + "It increases the supply of tokens on the C-Chain.", + "It ensures the total supply of tokens remains balanced across both chains.", + "It burns the tokens on the remote chain.", + "It locks the token permanently on the C-Chain." + ], + "correctAnswers": [ + 1 + ], + "hint": "Collateralization ensures balance across chains during token transfers.", + "explanation": "Collateralization locks the transferred tokens on the source chain, ensuring that the minted tokens on the destination chain have an equivalent backing.", + "chapter": "Use ERC-20 as Native Token" + }, + "209": { + "question": "What is the purpose of wrapping a native token on the C-Chain before transferring it to a new L1?", + "options": [ + "To convert it into an ERC-721 token.", + "To prepare it for cross-chain transfer as an ERC-20 token.", + "To lock it in a smart contract and mint its representation on the new L1.", + "To burn the token and reduce its total supply." + ], + "correctAnswers": [ + 2 + ], + "hint": "Wrapping a token creates a compatible version of it for cross-chain transfers.", + "explanation": "Wrapping the native token locks it on the C-Chain, allowing a compatible version of the token to be minted on the new L1, ensuring the cross-chain token transfer process.", + "chapter": "Use ERC-20 as Native Token" + } +} \ No newline at end of file diff --git a/components/quizzes/quiz.tsx b/components/quizzes/quiz.tsx index a958e544..a3e1f84c 100644 --- a/components/quizzes/quiz.tsx +++ b/components/quizzes/quiz.tsx @@ -6,6 +6,7 @@ import Image from 'next/image'; import { cn } from '@/utils/cn'; import { buttonVariants } from '@/components/ui/button'; import quizData from './quizData.json'; +import l1TokenomicsQuestions from './courses/l1-tokenomics.json'; interface QuizProps { quizId: string; @@ -28,7 +29,11 @@ const Quiz: React.FC = ({ quizId }) => { useEffect(() => { setIsClient(true); - const fetchedQuizInfo = quizData.quizzes[quizId as keyof typeof quizData.quizzes]; + const all = { + ...quizData.quizzes, + ...l1TokenomicsQuestions + }; + const fetchedQuizInfo = all[quizId as keyof typeof quizData.quizzes]; if (fetchedQuizInfo) { setQuizInfo(fetchedQuizInfo); } diff --git a/components/quizzes/quizData.json b/components/quizzes/quizData.json index 3bdd93a1..428bad45 100644 --- a/components/quizzes/quizData.json +++ b/components/quizzes/quizData.json @@ -3,6 +3,10 @@ "avalanche-fundamentals": { "title": "Avalanche Fundamentals", "quizzes": ["101", "102", "103", "104", "105", "106", "107", "108", "109", "110", "111", "112", "113", "114", "115", "116", "117"] + }, + "l1-tokenomics": { + "title": "L1 Tokenomics", + "quizzes": ["201", "202", "203", "204", "205", "206", "207", "208", "209"] } }, "quizzes": { diff --git a/content/common/intro/instructors.tsx b/content/common/intro/instructors.tsx index 2158574a..34b19756 100644 --- a/content/common/intro/instructors.tsx +++ b/content/common/intro/instructors.tsx @@ -39,6 +39,14 @@ const instructors: Instructor[] = [ twitter: "https://x.com/owenwahlgren", linkedin: "https://www.linkedin.com/in/owenwahlgren/", github: "https://github.com/owenwahlgren", + }, + { + name: "Sarp", + title: "Sr. Developer Relations Engineer", + + twitter: "https://x.com/satatocom", + linkedin: "https://www.linkedin.com/in/sarptaylan/", + github: "https://github.com/0xstt", } ]; diff --git a/content/course/l1-tokenomics/01-basics/01-native-tokens.mdx b/content/course/l1-tokenomics/01-basics/01-native-tokens.mdx new file mode 100644 index 00000000..6515454a --- /dev/null +++ b/content/course/l1-tokenomics/01-basics/01-native-tokens.mdx @@ -0,0 +1,29 @@ +--- +title: Native Tokens +description: Learn about native tokens and their role in blockchain ecosystems. +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +A **native token** in a blockchain running the Ethereum Virtual Machine (EVM) refers to the primary digital currency or cryptocurrency native to that blockchain. Native tokens act as the foundation for value transfer and network operation within their respective ecosystems. + +- **Ethereum**: ETH +- **Avalanche C-Chain**: AVAX +- **Dexalot**: ALOT +- many more... + +--- + +### The Role of Native Tokens + +Native tokens serve multiple key roles within EVM-based blockchain networks, such as: + +- **Value Transfer**: Native tokens act as the primary currency for peer-to-peer transactions within the network, enabling value exchange between participants. +- **Gas Fees**: Native tokens are used as **gas** to pay for transaction fees, contract deployments, and other network operations. This ensures that resources are allocated efficiently within the network. +- **Security**: In Proof-of-Stake (PoS) networks, native tokens are often used for staking to secure the network and validate transactions. +- **Governance**: In some cases, native tokens grant holders governance rights, allowing them to participate in decision-making processes that shape the blockchain’s future. + +--- + +Native tokens are the backbone of blockchain ecosystems, serving multiple roles that maintain the network's stability, security, and functionality. \ No newline at end of file diff --git a/content/course/l1-tokenomics/01-basics/02-erc-20-tokens.mdx b/content/course/l1-tokenomics/01-basics/02-erc-20-tokens.mdx new file mode 100644 index 00000000..a769db3d --- /dev/null +++ b/content/course/l1-tokenomics/01-basics/02-erc-20-tokens.mdx @@ -0,0 +1,98 @@ +--- +title: ERC-20 Tokens +description: Learn about ERC-20 tokens and their role in blockchain ecosystems. +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +While a blockchain has a single **native token**, the **ERC-20** token standard was developed to allow for the representation of a wide range of assets on EVM-compatible chains. + +**ERC** stands for **Ethereum Request for Comment**, and **20** is the identifier for the specific proposal that defines the standard. + +ERC-20 tokens are **fungible**, meaning each token is identical to another and can be exchanged on a one-to-one basis. These tokens are created and managed through smart contracts that adhere to the ERC-20 standard, ensuring interoperability between different tokens and decentralized applications (DApps). + +--- + +### ERC-20 Token Architecture + +At the core of every ERC-20 token is a simple **mapping** of addresses to balances, representing the number of tokens an address holds. + +```solidity +abstract contract ERC20 is Context, IERC20, IERC20Metadata, IERC20Errors { + + mapping(address account => uint256) private _balances; + + //... +} +``` + +Addresses holding ERC-20 tokens can belong to either **Externally Owned Accounts (EOAs)** or **smart contracts**. Both types of accounts can store and transfer ERC-20 tokens, making ERC-20 tokens versatile in decentralized finance (DeFi) and decentralized applications. + +--- + +### Role of ERC-20 Tokens in Blockchain Ecosystems + +ERC-20 tokens play an essential role in enabling the creation of decentralized applications with various functionalities: + +- **Tokenized Assets**: ERC-20 tokens can represent anything from digital currencies to tokenized real-world assets. +- **DeFi Protocols**: Many DeFi protocols use ERC-20 tokens for lending, staking, and liquidity pools. +- **Token Sales**: ICOs (Initial Coin Offerings) and other fundraising models rely heavily on ERC-20 tokens. + +--- + +### The ERC-20 Interface + +All ERC-20 tokens follow a standard interface to ensure compatibility with decentralized applications (DApps). This allows tokens to be easily transferred, approved for spending, and managed by any DApp that follows the same rules. + +```solidity +interface IERC20 { + function name() external view returns (string memory); + + function symbol() external view returns (string memory); + + function decimals() external view returns (uint8); + + function totalSupply() external view returns (uint256); + + function balanceOf(address _owner) external view returns (uint256 balance); + + function transfer(address _to, uint256 _value) external returns (bool success); + + function transferFrom(address _from, address _to, uint256 _value) external returns (bool success); + + function approve(address _spender, uint256 _value) external returns (bool success); + + function allowance(address _owner, address _spender) external view returns (uint256 remaining); +} +``` + +You can review the full **ERC-20 standard** [here](https://eips.ethereum.org/EIPS/eip-20). + +--- + +### Transferring ERC-20 Tokens + +To transfer ERC-20 tokens between accounts, you use the `transfer()` function, where the sender specifies the recipient’s address and the amount to be transferred. + +For more complex interactions, such as allowing a smart contract to transfer tokens on behalf of someone else, the ERC-20 standard includes the `approve()` and `transferFrom()` functions. + + + + +Transfers tokens from the sender’s account to another account, decreasing the sender's balance and increasing the recipient’s. + + +This function allows the owner of a token balance to approve another account (the **spender**) to withdraw up to a specified amount of tokens. The spender can withdraw from the owner's balance multiple times, as long as the total amount doesn’t exceed the approved limit. + + +The `allowance()` function returns the amount that a spender is still allowed to withdraw from an owner's balance. + + +This function facilitates the transfer of tokens from one account to another on behalf of the account owner. It is typically used in scenarios where smart contracts need to execute token transfers according to the contract's logic. + + + +--- + +ERC-20 tokens revolutionized the blockchain space by enabling the tokenization of assets and simplifying the creation of decentralized applications. Their standardization ensures compatibility across platforms and DApps, making them an integral part of the broader crypto ecosystem. \ No newline at end of file diff --git a/content/course/l1-tokenomics/01-basics/03-deploy-and-transfer-erc-20-tokens.mdx b/content/course/l1-tokenomics/01-basics/03-deploy-and-transfer-erc-20-tokens.mdx new file mode 100644 index 00000000..5131ac6a --- /dev/null +++ b/content/course/l1-tokenomics/01-basics/03-deploy-and-transfer-erc-20-tokens.mdx @@ -0,0 +1,17 @@ +--- +title: Deploy and Transfer an ERC-20 Token +description: Learn how to deploy an ERC-20 token and transfer it between accounts. +updated: 2024-09-03 +authors: [0xstt] +icon: Terminal +--- + +In this section, you will follow a step-by-step guide to deploy an ERC-20 token on a blockchain network and transfer it between accounts. This will provide practical experience with token creation, deployment, and handling transactions. + +### Objectives: +- Deploy an ERC-20 token smart contract. +- Interact with your token by transferring it between different accounts. + +To learn how to deploy an ERC-20 token and interact with your token on a blockchain, follow [this guide](/course/interchain-token-transfer/03-tokens/08-transfer-an-erc-20-token) to explore the deployment process using the CLI on our Avalanche L1. + + diff --git a/content/course/l1-tokenomics/01-basics/04-wrapped-tokens.mdx b/content/course/l1-tokenomics/01-basics/04-wrapped-tokens.mdx new file mode 100644 index 00000000..de523184 --- /dev/null +++ b/content/course/l1-tokenomics/01-basics/04-wrapped-tokens.mdx @@ -0,0 +1,56 @@ +--- +title: Wrapped Native Tokens +description: Learn about wrapped tokens and their role in blockchain ecosystems. +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +**Wrapped tokens** are blockchain assets that represent a native cryptocurrency (e.g., AVAX, ALOT, ETH) in a tokenized form, typically conforming to the **ERC-20 token standard**. Wrapping a native token allows it to be used in decentralized applications (dApps) and protocols that require ERC-20 tokens. + +--- + +### What Are Wrapped Tokens? + +Wrapped tokens are created through a process where the native cryptocurrency is locked in a smart contract, and an equivalent amount of the wrapped token is minted. These wrapped tokens are backed 1:1 by the underlying native asset, ensuring that the value of the wrapped token mirrors that of the original native cryptocurrency. + +This **ERC-20 compatibility** is crucial for enabling the native asset to interact with dApps, decentralized exchanges (DEXs), and smart contracts within the EVM ecosystem, where ERC-20 tokens are the standard. + +--- + +### Why Are Wrapped Tokens Important? + +Wrapped tokens play an essential role in **interoperability** within the EVM ecosystem, facilitating seamless use across decentralized applications and protocols. Some key benefits include: + +- **Liquidity**: Wrapped tokens increase liquidity in DeFi by enabling users to participate in protocols that require ERC-20 tokens, even when their original asset is a native token. +- **Cross-Chain Compatibility**: Wrapped tokens allow assets from one blockchain (e.g., Bitcoin) to be used on another chain, enhancing cross-chain functionality. +- **DeFi Integration**: Wrapped tokens are vital in DeFi protocols such as lending, borrowing, staking, and liquidity pools, where ERC-20 tokens are the standard. + +--- + +### Wrapped Token Contract Interface + +A **wrapped token contract** is typically an implementation of the ERC-20 token standard, with added functions for minting and burning tokens to facilitate the wrapping and unwrapping process. Here's a basic contract interface for a wrapped token: + +```solidity +interface IWrappedToken { + function deposit() external payable; + function withdraw(uint256 amount) external; + + function totalSupply() external view returns (uint256); + function balanceOf(address account) external view returns (uint256); + function transfer(address recipient, uint256 amount) external returns (bool); + function allowance(address owner, address spender) external view returns (uint256); + function approve(address spender, uint256 amount) external returns (bool); + function transferFrom(address sender, address recipient, uint256 amount) external returns (bool); +} +``` + + + +This function is used to wrap native tokens. When a user calls deposit(), they send the native cryptocurrency (e.g., AVAX, ETH) to the contract, which then mints an equivalent amount of the wrapped token. + + +This function is used to unwrap the tokens. It burns the specified amount of wrapped tokens and returns the equivalent amount of native cryptocurrency to the user. + + \ No newline at end of file diff --git a/content/course/l1-tokenomics/01-basics/05-deploy-and-interact-wrapped-tokens.mdx b/content/course/l1-tokenomics/01-basics/05-deploy-and-interact-wrapped-tokens.mdx new file mode 100644 index 00000000..67815b79 --- /dev/null +++ b/content/course/l1-tokenomics/01-basics/05-deploy-and-interact-wrapped-tokens.mdx @@ -0,0 +1,103 @@ +--- +title: Deploy and Interact with Wrapped Token +description: Learn how to deploy and interact with wrapped tokens +updated: 2024-09-03 +authors: [0xstt] +icon: Terminal +--- +import { Step, Steps } from 'fumadocs-ui/components/steps'; + +In this section, we will deploy and interact with a wrapped token using **Forge** and **cast** commands. Forge simplifies smart contract deployment, and cast allows you to interact with deployed contracts. + +--- + + + + +#### 1. Write the Wrapped Token Contract +Here is a basic implementation of a wrapped token contract in Solidity: + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.0; + +import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; + +contract WrappedToken is ERC20 { + address public nativeTokenHolder; + + constructor() ERC20("Wrapped Token", "WTKN") {} + + function deposit() external payable { + _mint(msg.sender, msg.value); + nativeTokenHolder = msg.sender; + } + + function withdraw(uint256 amount) external { + _burn(msg.sender, amount); + payable(msg.sender).transfer(amount); + } +} +``` + + + + +### Deploy ERC20 Receiver +Deploy the Contract Using Forge's `create` Command + +```bash +forge create --rpc-url myblockchain --private-key $PK WrappedToken.sol:WrappedToken +``` + + + + + +### Save the Wrapped Token Address + +Save the `Deployed to` address in an environment variable. + +```bash +export WRAPPED_TOKEN=
+``` + + + + + +### Interacting with the Deployed Contract + +Once the contract is deployed, you can interact with it using **cast** commands. + + + + + +To deposit native tokens and mint wrapped tokens, use the following `cast send` command: + +```bash +cast send $WRAPPED_TOKEN "deposit()" --value --rpc-url myblockchain --private-key $PK +``` + +- ``: The amount of native tokens you want to wrap (in wei). + + + +To burn the wrapped tokens and retrieve the equivalent amount of native tokens: + +```bash +cast send $WRAPPED_TOKEN "withdraw(uint256)" --rpc-url myblockchain --private-key $PK +``` + +- ``: The number of wrapped tokens to burn and convert back to native tokens. + + + +You can use the following page for [**wei conversions**](https://snowtrace.io/unitconverter). + + + + + + \ No newline at end of file diff --git a/content/course/l1-tokenomics/01-basics/06-token-decimals.mdx b/content/course/l1-tokenomics/01-basics/06-token-decimals.mdx new file mode 100644 index 00000000..cd57da9b --- /dev/null +++ b/content/course/l1-tokenomics/01-basics/06-token-decimals.mdx @@ -0,0 +1,26 @@ +--- +title: Token Decimals +description: Learn about token decimals and their impact on blockchain applications. +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +**Token decimals** refer to the level of precision used to define a token’s smallest unit. When a token contract is created, the number of decimals is specified to determine how divisible the token will be. This can have significant implications for user experience, application development, and overall token functionality. + +For example: +- **6 decimals**: A token with 6 decimals means the smallest unit is 0.000001. +- **18 decimals**: A token with 18 decimals means the smallest unit is 0.000000000000000001. + +--- + +### Why Are Token Decimals Important? + +Token decimals are critical because they determine how small a fraction of the token can be used in transactions. The choice of decimals directly affects how the token is used in various applications, including decentralized finance (DeFi), payments, and staking. + +- **Greater Precision**: More decimals allow for finer divisions of the token, which is useful in systems where very small amounts of a token need to be handled (e.g., high-frequency trading, micro-payments, or rewards distribution). +- **User Perception**: The number of decimals can also influence how users perceive the value of the token. A token with fewer decimals might appear more “whole,” making it seem like larger amounts are being used in transactions. + +--- + +**Conclusion**: Token decimals are a fundamental aspect of token design. Choosing the right number of decimals depends on the token's use case, balancing the need for precision with user experience and technical requirements. \ No newline at end of file diff --git a/content/course/l1-tokenomics/02-native-tokens/01-custom-native-tokens.mdx b/content/course/l1-tokenomics/02-native-tokens/01-custom-native-tokens.mdx new file mode 100644 index 00000000..d56e1f67 --- /dev/null +++ b/content/course/l1-tokenomics/02-native-tokens/01-custom-native-tokens.mdx @@ -0,0 +1,42 @@ +--- +title: Custom Native Tokens +description: Learn how custom native tokens can be used in the Avalanche network. +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +In the Avalanche network, each Layer 1 (L1) blockchain has its own **native token**, which is used to pay for transaction fees (gas). This design isolates the gas fees on one blockchain from others in the ecosystem. For example, high transaction volume on the Avalanche C-Chain will not affect the transaction fees on a custom Avalanche L1 chain, giving developers greater flexibility in managing costs. + +--- + +### Custom Native Tokens: Unlocking Flexibility + +Custom native tokens allow developers to design and control transaction costs and economic models within their blockchain. By managing gas fees and tokenomics, they can create a tailored system that fits the specific needs of their blockchain application. + +- **Isolated Fees**: Custom native tokens ensure that each blockchain maintains its own fee structure, preventing external factors from impacting transaction costs. +- **Tokenomics Control**: Developers can design custom economic models that support their application's needs, from low-fee environments to systems that incentivize specific user behaviors. + +--- + +### Creating a Seamless User Experience with Native Tokens + +Developers may want to provide a more streamlined, **cost-free experience** for users who are unfamiliar with the concept of paying for transactions. One approach to achieve this is to eliminate the burden of transaction fees for users by covering these costs through the native token itself. This can make interacting with blockchain applications feel more like traditional platforms, enhancing accessibility and ease of use. + +#### Simplifying Blockchain Interaction +- **Transaction Fee Subsidization**: Developers can cover or significantly reduce transaction fees, ensuring that users can perform actions without directly incurring gas costs. This helps reduce friction for users and promotes engagement. +- **Lowering Entry Barriers**: By minimizing the complexity of gas payments, developers can attract a wider audience, especially users not familiar with blockchain technology. + +--- + +### Stabilizing Native Token Value + +Some developers may want to ensure **price stability** for their native tokens, particularly if they need to maintain consistent transaction fees over time. Instead of issuing a token subject to market volatility, they can **peg the value of the native token to an existing stable asset**. This provides the dual benefits of isolated transaction fees with the predictability of stable pricing. + +#### Maintaining Fee Consistency +- **Stable Value Tokens**: Tying the native token’s value to a stable asset (such as a stablecoin) ensures that transaction fees remain predictable, regardless of fluctuations in token supply or market demand. +- **Predictable Costs**: This model allows developers to maintain consistent, low-cost transactions, helping to avoid disruptions caused by price volatility in the broader crypto market. + +--- + +**Conclusion**: Custom native tokens on the Avalanche network give developers the freedom to design blockchain economies that suit their project’s needs. Whether by managing gas fees for seamless user experiences or ensuring stable pricing through value-pegged tokens, custom tokens provide the flexibility required to build innovative and accessible blockchain applications. \ No newline at end of file diff --git a/content/course/l1-tokenomics/02-native-tokens/02-configure-custom-native-token.mdx b/content/course/l1-tokenomics/02-native-tokens/02-configure-custom-native-token.mdx new file mode 100644 index 00000000..7d4d8771 --- /dev/null +++ b/content/course/l1-tokenomics/02-native-tokens/02-configure-custom-native-token.mdx @@ -0,0 +1,87 @@ +--- +title: Configure Custom Native Tokens +description: Learn how to configure a custom native token in an Avalanche L1 blockchain. +updated: 2024-09-04 +authors: [0xstt] +icon: Terminal +--- +import { Step, Steps } from 'fumadocs-ui/components/steps'; + +When creating a custom Avalanche L1 blockchain, you can configure the native token according to your specific requirements. In this section, we'll explore the steps to configure a custom native token using the Subnet-EVM, allowing you to tailor it to your blockchain's needs. + + + + + +### Creating the Blockchain +Start by creating a new blockchain using the `avalanche` CLI tool: +```bash +avalanche blockchain create myblockchain +``` + + +### Select VM +You will be prompted to select the Subnet-EVM as the virtual machine for your blockchain: + +```bash +? Which Virtual Machine would you like to use?: + ▸ Subnet-EVM + Custom VM + Explain the difference +``` + +Select Subnet-EVM to proceed. + + +### Customizing Blockchain Configuration +After selecting Subnet-EVM, you’ll have the option to use default values or customize your blockchain settings: + +```bash +? Do you want to use default values for the Blockchain configuration?: + I want to use defaults for a test environment + I want to use defaults for a production environment + ▸ I don't want to use default values + Explain the difference +``` + +Select **I don’t want to use default values** to manually configure your blockchain. + + +### Setting the Version, ChainID, and Token Symbol +Next, you will be asked to choose the version of Subnet-EVM and configure the ChainID and token symbol: + +```bash +✔ Subnet-EVM +✔ I don't want to use default values +? Version: + ▸ Use latest release version + Specify custom version +``` + +Choose Use latest release version for the Subnet-EVM. After that, you will configure the following: + +```bash +✔ Chain ID: 123456 +✔ Token Symbol: CNT +``` + +- **ChainID**: Choose a unique Chain ID that hasn’t been used on another blockchain. You can reference available Chain IDs by visiting [ChainList](https://chainlist.org/), which lists in-use Chain IDs. + + +When configuring your custom Avalanche blockchain, it’s crucial to select a unique Chain ID to avoid replication. Replicating a Chain ID that is already in use can lead to several problems, the most critical being replay attacks. + +**Replay Attacks** + +A replay attack occurs when a valid transaction on one blockchain can be maliciously replayed on another chain that shares the same Chain ID. For example, if two blockchains have the same Chain ID, a transaction on one chain could be copied and executed on the other, leading to unintended consequences, such as unauthorized token transfers. + + +- **Token Symbol**: Set a token symbol for your custom native token (e.g., CNT). This symbol will represent your blockchain’s native token in transactions and applications. + + + + + +--- + +What’s Next? +After configuring the custom native token, the next step is to define the initial token allocation, where you’ll decide how the tokens will be distributed across validators, participants, and other stakeholders in your blockchain. \ No newline at end of file diff --git a/content/course/l1-tokenomics/02-native-tokens/03-native-token-allocation.mdx b/content/course/l1-tokenomics/02-native-tokens/03-native-token-allocation.mdx new file mode 100644 index 00000000..ee5a6bd7 --- /dev/null +++ b/content/course/l1-tokenomics/02-native-tokens/03-native-token-allocation.mdx @@ -0,0 +1,54 @@ +--- +title: Native Token Allocation +description: Learn how to configure a custom native token in an Avalanche L1 blockchain. +updated: 2024-09-04 +authors: [0xstt] +icon: Book +--- +import { Step, Steps } from 'fumadocs-ui/components/steps'; + +After configuring your custom native token, the next step is to define how the token supply will be distributed. **Initial token allocation** is crucial as it determines the distribution of tokens among validators, developers, early participants, and other stakeholders in your blockchain ecosystem. + +--- + +### Why Initial Token Allocation Matters + +The way you allocate tokens at the start of your blockchain’s lifecycle sets the foundation for how your network will operate. Proper allocation ensures that incentives align with network security, participation, and governance. + +- **Validators**: Allocating tokens to validators ensures that they have the necessary stake to secure the network and participate in consensus. +- **Developers & Ecosystem**: Distributing tokens to developers and contributors incentivizes growth and innovation within your ecosystem. +- **Early Participants**: Rewarding early participants helps build a strong, engaged community. + +--- + +### Structuring Initial Token Allocation + +When prompted, you’ll be given several options to structure the initial token allocation: + +```bash +? How should the initial token allocation be structured?: + ▸ Allocate 1m tokens to a new account + Allocate 1m to the ewoq account 0x8db...2FC (Only recommended for testing, not recommended for production) + Define a custom allocation (Recommended for production) +``` + +--- + +### Minting New Native Tokens + +You will also be asked whether you want to allow minting of new tokens beyond the initial supply: + +```bash +? Allow minting of new native tokens?: + ▸ No, I want the supply of the native tokens to be hard-capped + Yes, I want to be able to mint additional native tokens (Native Minter Precompile ON) +``` + +- **Hard-capped Supply**: Selecting `No` creates a finite supply of tokens, which cannot be increased. This is similar to the design of assets like Bitcoin, where the total supply is fixed. +- **Mintable Tokens**: Selecting `Yes` enables the Native Minter Precompile, allowing the minting of new native tokens over time. This option gives you flexibility to issue more tokens as needed. We will discuss the Native Minter Precompile in detail in upcoming chapters. + +--- + +What’s Next? If you enabled minting, explore how to configure and interact with the **Native Minter Precompile** to mint new tokens and manage supply over time. + + \ No newline at end of file diff --git a/content/course/l1-tokenomics/02-native-tokens/04-activating-native-minter-precompile.mdx b/content/course/l1-tokenomics/02-native-tokens/04-activating-native-minter-precompile.mdx new file mode 100644 index 00000000..9a2bf811 --- /dev/null +++ b/content/course/l1-tokenomics/02-native-tokens/04-activating-native-minter-precompile.mdx @@ -0,0 +1,121 @@ +--- +title: Activating Native Minter Precompile +description: Learn how to activate the native minter precompile. +updated: 2024-09-04 +authors: [0xstt] +icon: Terminal +--- +import { Step, Steps } from 'fumadocs-ui/components/steps'; + +The **Native Minter Precompile** allows you to mint additional native tokens beyond the initial supply on your Avalanche L1 blockchain. By enabling this feature, you can define who has permission to mint new tokens and how minting is managed over time. This section walks you through activating the Native Minter Precompile and configuring the necessary **allow list**. + +--- + +### What is the AllowList? + +The **AllowList** is a security feature used by precompiles to manage which addresses have permission to interact with certain contract functionalities. In the case of the **Native Minter Precompile**, the allow list is used to control who can mint new native tokens. + +The AllowList consists of three roles: +- **Admin**: Full control over the allow list, including the ability to add or remove Admins, Managers, and Enabled addresses. +- **Manager**: Can add or remove **Enabled** addresses but cannot modify Admins or Managers. +- **Enabled**: These addresses can use the precompiled contract (e.g., mint native tokens) but cannot modify the allow list. + +The allow list provides a granular way to assign permissions, ensuring that only authorized addresses can mint native tokens or manage the minting process. + + + +The AllowList Interface manages which addresses have permissions to interact with the precompiled contract. Here is the Solidity interface used for the allow list: + +```solidity +//SPDX-License-Identifier: MIT +pragma solidity ^0.8.24; + +interface IAllowList { + event RoleSet(uint256 indexed role, address indexed account, address indexed sender, uint256 oldRole); + + function setAdmin(address addr) external; + function setEnabled(address addr) external; + function setManager(address addr) external; + function setNone(address addr) external; + function readAllowList(address addr) external view returns (uint256 role); +} +``` + +This interface provides the ability to: + +- **Set Admin, Manager, and Enabled roles** for specific addresses. +- **Read the role** of an address to check its permissions. +- **Remove roles** from addresses when needed. + + + + +--- + + + +### Activating the Native Minter Precompile + +During the configuration process, you’ll be prompted to choose whether you want the native token supply to be hard-capped or if you want the ability to mint new tokens: + +```bash +? Allow minting of new native tokens?: + ▸ Yes, I want to be able to mint additional native tokens (Native Minter Precompile ON) + No, I want the supply of the native tokens to be hard-capped +``` + +Select **Yes, I want to be able to mint additional native tokens** to enable the Native Minter Precompile. This will allow your blockchain to mint new tokens as needed. + + +### Configuring the Allow List + +After enabling minting, you will need to configure the **allow list**, which determines who has permission to mint tokens and manage the precompile contract. Initially, the allow list will be empty, so you will need to manually add addresses for each role. + +```bash +? Configure the addresses that are allowed to mint native tokens: + ▸ Add an address for a role to the allow list + Preview Allow List + Confirm Allow List + Cancel +``` + + +### Adding Addresses to the Allow List + +To add addresses to the allow list, choose **Add an address for a role to the allow list** and assign a role to each address: + +```bash +? What role should the address have?: + ▸ Admin + Manager + Enabled +``` + + +### Example Allow List Setup + +After adding an address for each role, you can preview the current allow list: + +```bash +✔ Preview Allow List ++---------+--------------------------------------------+ +| Admins | 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC | ++---------+--------------------------------------------+ +| Manager | | ++---------+--------------------------------------------+ +| Enabled | | ++---------+--------------------------------------------+ +``` + +After verifying the allow list, confirm the configuration: + +```bash +? Configure the addresses that are allowed to mint native tokens: + ▸ Confirm Allow List + Add an address for a role to the allow list + Remove an address from the allow list + Preview Allow List + Cancel +``` + + \ No newline at end of file diff --git a/content/course/l1-tokenomics/02-native-tokens/05-native-minter-precompile.mdx b/content/course/l1-tokenomics/02-native-tokens/05-native-minter-precompile.mdx new file mode 100644 index 00000000..cc966d7b --- /dev/null +++ b/content/course/l1-tokenomics/02-native-tokens/05-native-minter-precompile.mdx @@ -0,0 +1,33 @@ +--- +title: Native Minter Precompile +description: Learn how to enable minting of new native tokens and configure the allow list in an Avalanche L1 blockchain. +updated: 2024-09-04 +authors: [0xstt] +icon: Book +--- +import { Step, Steps } from 'fumadocs-ui/components/steps'; + +### Minting Native Tokens + +Once the allow list is configured, addresses with the Enabled role can mint new native tokens using the following interface: + +```solidity +//SPDX-License-Identifier: MIT +pragma solidity ^0.8.24; + +interface INativeMinter { + event NativeCoinMinted(address indexed sender, address indexed recipient, uint256 amount); + + function mintNativeCoin(address addr, uint256 amount) external; +} +``` + + + +This function mints a specified amount of native tokens and sends them to the designated address. Only addresses with the Enabled role can call this function. + + + +**Conclusion**: By enabling the Native Minter Precompile and setting up an allow list with proper roles, you can effectively manage who has permission to mint new native tokens and adjust the token supply as needed. By doing so at the **smart contract level**, Avalanche provides flexibility and security, allowing developers to control minting directly within their blockchain applications. + + \ No newline at end of file diff --git a/content/course/l1-tokenomics/02-native-tokens/06-use-erc20-as-native-token.mdx b/content/course/l1-tokenomics/02-native-tokens/06-use-erc20-as-native-token.mdx new file mode 100644 index 00000000..e86a9fbc --- /dev/null +++ b/content/course/l1-tokenomics/02-native-tokens/06-use-erc20-as-native-token.mdx @@ -0,0 +1,41 @@ +--- +title: Use ERC-20 as Native Token +description: Learn how an ERC-20 token can be used as a native token in a custom Avalanche L1 blockchain. +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +In a custom Avalanche L1 blockchain, you can opt to use an **ERC-20 token** as the native token. Typically, ERC-20 tokens serve as fungible assets within decentralized applications (dApps), but in this setup, the ERC-20 token is transferred to the new L1 via the **Interchain Token Transfer (ICTT)** mechanism. Once transferred, the ERC-20 token no longer behaves as a standard ERC-20 token but is instead **converted into the native token** of the new L1 blockchain. + +--- + +### Features Unlocked by Using ERC-20 as Native Token + +By using an ERC-20 token as the native token on a new Avalanche L1 blockchain, several unique features and benefits become available: + +- **Leverage Existing Ecosystem Liquidity** + +Bringing an ERC-20 token into the new L1 as a native token allows you to tap into the existing liquidity and user base of that ERC-20 token. For example, a stablecoin like USDC, transferred as an ERC-20 token, can be used as the native token to provide price stability while facilitating cross-chain transactions. + +- **Interoperability with Existing dApps** + +An ERC-20 token as a native token allows the new L1 to **interoperate with existing decentralized applications** (dApps) and DeFi protocols that are built around that token. This can increase user adoption by maintaining familiar token functionality across different chains. + +- **Cross-Chain Compatibility** + +Transferring an ERC-20 token via ICTT unlocks **cross-chain compatibility**, meaning that assets and value from one blockchain ecosystem can seamlessly move and function on another blockchain. This helps promote greater liquidity across blockchains and removes barriers to token usage. + +- **Gas Fee Flexibility** + +Using an ERC-20 token as a native token offers flexibility in how gas fees are handled. Rather than relying on a brand-new native token, you can use the transferred ERC-20 token to **pay for gas fees**, making it easier for users already familiar with that token to interact with the new chain. + +- **Governance and Staking** + +Once an ERC-20 token becomes the native token on the new L1, it can be used for staking and **governance functions**, such as voting on proposals or participating in consensus mechanisms. This expands the token's utility beyond simple transactions, enabling it to play a critical role in securing and managing the new L1. + +--- + +### Next Steps + +In the next section, **Multi-chain Ecosystems**, we’ll explore how the transfer of assets between different chains works and how using tokens like ERC-20 as native tokens enhances cross-chain liquidity and interoperability. We’ll also look into the technical challenges and solutions involved in building robust, multi-chain ecosystems that support the seamless movement of assets like these. \ No newline at end of file diff --git a/content/course/l1-tokenomics/03-multi-chain-ecosystems/01-introduction.mdx b/content/course/l1-tokenomics/03-multi-chain-ecosystems/01-introduction.mdx new file mode 100644 index 00000000..9000a560 --- /dev/null +++ b/content/course/l1-tokenomics/03-multi-chain-ecosystems/01-introduction.mdx @@ -0,0 +1,71 @@ +--- +title: Introduction +description: Learn how multi-chain ecosystems influence tokenomics and unlock new possibilities for token utility and interoperability. +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +A **multi-chain ecosystem** refers to the integration of multiple blockchain networks that operate together to enable the seamless transfer of assets, data, and functionality across chains. As blockchain adoption grows, multi-chain ecosystems are becoming a crucial part of tokenomics, unlocking new opportunities for how tokens are used, transferred, and governed across different blockchain environments. + +--- + +### Impact on Tokens and Tokenomics + +In a single-chain environment, tokens are confined to the limitations of their original network, restricting their usability and liquidity. However, in a **multi-chain ecosystem**, tokens can move freely between blockchains, enhancing their utility and making them more adaptable to various use cases. This has profound implications for **tokenomics**: + +- **Expanded Token Utility** + +In a multi-chain ecosystem, tokens are not limited to their native chain. They can be used across various platforms and blockchains, unlocking new use cases. For example, a token can be used for governance on one chain and staking or liquidity provision on another, maximizing its functionality. + +- **Increased Liquidity** + +The ability to transfer tokens between chains increases liquidity by allowing assets to flow freely across decentralized exchanges (DEXs) and lending platforms on multiple chains. + +- **Enhanced Security and Governance** + +Multi-chain ecosystems can offer more robust security mechanisms by distributing consensus and governance across several chains. This makes networks less vulnerable to attacks and enables cross-chain governance models, where token holders from multiple chains can vote on protocol upgrades or community decisions. + +- **Tokenomics Flexibility** + +Tokenomics models can be more flexible and adaptive in multi-chain ecosystems. For instance, the same token might have different roles on different chains, such as paying for gas fees on one chain while being used for collateral in DeFi protocols on another. This adaptability makes it easier to create sustainable and efficient token economies. + +--- + +### Challenges of Multi-Chain Ecosystems + +While multi-chain ecosystems unlock significant benefits, they also come with **challenges** that developers and projects must address: + +- **Fragmented Liquidity** + +One of the key challenges in multi-chain ecosystems is **liquidity fragmentation**. When tokens are spread across multiple chains, liquidity can become diluted, making it harder to pool sufficient liquidity on any single platform. This can reduce efficiency for decentralized finance (DeFi) platforms, increasing slippage and reducing market depth. + +- **Complexity of Cross-Chain Communication** + +Managing assets across multiple chains requires complex **cross-chain communication** protocols. + +- **Security Risks** + +While multi-chain ecosystems offer greater flexibility, they also introduce potential **security risks**, such as the vulnerability of bridges. If a bridge or cross-chain protocol is compromised, tokens or assets on the receiving chain can be at risk. + +- **Difficulty in Managing Governance** + +Cross-chain governance can be difficult to coordinate, especially when token holders are spread across multiple chains with different governance models. Aligning voting mechanisms and decision-making processes can create friction and delays. + +--- + +### How Avalanche Helps Power Multi-Chain Ecosystems + +Avalanche plays a critical role in the development and support of multi-chain ecosystems. As a platform built with scalability, interoperability, and customizability in mind, Avalanche enables the seamless transfer of tokens and data across its L1s and beyond. Some of the key features that make Avalanche ideal for multi-chain ecosystems include: + +- **Interchain Token Transfer (ICTT)**: + +ICTT enables the **seamless movement of assets** between Avalanche L1s and other blockchain networks. This ensures that tokens can move freely between chains without compromising security or usability. + +- **Cross-Chain Messaging**: + +Avalanche’s cross-chain communication protocols enable the exchange of messages and transactions between chains, ensuring smooth interaction and data sharing between networks. + +--- + +What's next? In the following sections, we will explore the technical aspects of **interchain token transfers** and how Avalanche’s architecture supports the movement of assets and tokens across various chains. You’ll also learn how to leverage Avalanche’s tools to build multi-chain applications and unlock the full potential of your tokenomics. diff --git a/content/course/l1-tokenomics/03-multi-chain-ecosystems/02-interchain-token-transfers.mdx b/content/course/l1-tokenomics/03-multi-chain-ecosystems/02-interchain-token-transfers.mdx new file mode 100644 index 00000000..27ce3fc0 --- /dev/null +++ b/content/course/l1-tokenomics/03-multi-chain-ecosystems/02-interchain-token-transfers.mdx @@ -0,0 +1,53 @@ +--- +title: Interchain Token Transfers +description: Learn how to transfer assets across Avalanche L1 blockchains using Interchain Token Transfers. +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +**Interchain Token Transfers (ICTT)** allow assets, such as ERC-20 or native tokens, to move seamlessly between different Avalanche L1 blockchains. The system consists of a **TokenHome** contract, which lives on the source blockchain, and **TokenRemote** contracts, which reside on other Avalanche L1s that want to receive the asset. + +--- +![](/course-images/ictt/ictt.png) + +--- +### Overview of How It Works + +- **Home and Remote Contracts**: + +The `TokenHome` contract manages the transfer of assets from the source Avalanche L1 blockchain. It locks the original asset as collateral and tracks token balances sent to `TokenRemote` contracts on other L1s. + +The `TokenRemote` contracts, on the receiving chains, mint a representation of the original token, allowing users to interact with it as if it were the native token of that chain. + +- **Transfer Process**: + +When a user transfers an asset from the `source chain` to a `remote chain`, the asset is **locked** on the `home chain`, and a corresponding representation of the token is **minted** on the `remote chain`. + +This setup allows for different configurations, where the token can be represented as either an **ERC-20 token** or a **native token** on both the home and remote chains, giving flexibility to developers. + +- **Cross-Chain Flexibility**: + +Assets can be transferred in multiple configurations: +- `ERC-20` -> `ERC-20` +- `ERC-20` -> `Native` +- `Native` -> `ERC-20` +- `Native` -> `Native` + +This flexibility allows developers to choose how assets are represented and used across multiple Avalanche L1s. + +Configurations of the `TokenHome` and `TokenRemote` contracts can be found [here](https://github.com/ava-labs/avalanche-interchain-token-transfer/tree/main/contracts/src) + +- **Permissionless Registration**: + +ICTT is designed to be permissionless. Anyone can register a compatible `TokenRemote` instance to a `TokenHome` contract, expanding the network of chains that can receive transferred tokens. + +- **Customizable Logic**: + +Developers can extend the default `ERC20TokenRemote` contract to implement custom minting, burning, or transfer logic, giving them flexibility to add functionality specific to their use cases. + +--- + +### Learn More + +For more detailed information on setting up and managing Interchain Token Transfers, please refer to the [related guide](/course/interchain-token-transfer) on how to configure these contracts and customize their behavior for your multi-chain applications. \ No newline at end of file diff --git a/content/course/l1-tokenomics/03-multi-chain-ecosystems/03-use-erc20-as-native-token.mdx b/content/course/l1-tokenomics/03-multi-chain-ecosystems/03-use-erc20-as-native-token.mdx new file mode 100644 index 00000000..c7556855 --- /dev/null +++ b/content/course/l1-tokenomics/03-multi-chain-ecosystems/03-use-erc20-as-native-token.mdx @@ -0,0 +1,118 @@ +--- +title: Use ERC-20 as Native Token (DIY) +description: Learn how to transfer an ERC-20 token to a new Avalanche L1 and use it as a native token via ICTT. +updated: 2024-09-03 +authors: [0xstt] +icon: Terminal +--- +import { Step, Steps } from 'fumadocs-ui/components/steps'; + +In this section, you will learn how to transfer an ERC-20 token from Avalanche’s C-Chain to a new Avalanche L1 using Interchain Token Transfers (ICTT) and set it up to act as the **native token** on the new L1. This guide will take you through the steps of configuring a local network environment, deploying the necessary contracts, and transferring tokens. + + + + +### Create a new blockchain and Deploy on Local Network + +Use the **Avalanche CLI** to create a new blockchain where you will deploy the ERC-20 as the native token. + + +```bash +avalanche blockchain create myblockchain +``` +```bash +avalanche blockchain deploy myblockchain +``` + + +### Deploy an ERC-20 Contract on C-Chain + +Use the **Avalanche CLI** to create a new blockchain where you will deploy the ERC-20 as the native token. + +You will deploy an ERC-20 token on the Avalanche C-Chain, which will later be transferred and used as the native token on the new L1. + +```bash +forge create --rpc-url local-c --private-key $PK lib/avalanche-interchain-token-transfer/contracts/mocks/ExampleERC20Decimals.sol:ExampleERC20Decimals +``` + + +### Deploy Interchain Token Transfer Contracts +Set up the home and remote transferer contracts for transferring tokens between the C-Chain and the newly created L1. + +- `ERC20TokenHome` Contract on C-Chain +```bash +forge create --rpc-url local-c --private-key $PK lib/avalanche-interchain-token-transfer/contracts/src/TokenHome/ERC20TokenHome.sol:ERC20TokenHome --constructor-args $TELEPORTER_REGISTRY_C_CHAIN $FUNDED_ADDRESS $ERC20_HOME_C_CHAIN 18 +``` + +- `NativeTokenRemote` Contract on `myblockchain` +```bash +forge create --rpc-url myblockchain --private-key $PK lib/avalanche-interchain-token-transfer/contracts/src/TokenRemote/NativeTokenRemote.sol:NativeTokenRemote --constructor-args "($TELEPORTER_REGISTRY_L1, $FUNDED_ADDRESS, $C_CHAIN_BLOCKCHAIN_ID_HEX, $ERC20_HOME_TRANSFERER_C_CHAIN)" "EXMP.b" 100000000000000000000 0 false 0 +``` + +_Note: When deploying the `NativeTokenRemote` contract on the L1, ensure that the **initial amount** matches the native token amount that was minted when the blockchain was created. This ensures consistency between the native token supply and the remote token counterpart._ + + + +### Granting Native Minting Rights to NativeTokenRemote Contract +To ensure that the `NativeTokenRemote` contract can mint native tokens on the L1 when ERC-20 tokens are transferred from the `C-Chain`, the contract must be granted **minting rights**. This is done by adding the `NativeTokenRemote contract` address to the `Native Minter Precompile`. + +1. You will need to interact with the `Native Minter Precompile`, which resides at a fixed address on all Avalanche L1s: +**Native Minter Precompile Address**: `0x0200000000000000000000000000000000000001` + +2. Use the following command to grant the `NativeTokenRemote` contract minting rights by setting it as an **enabled** address on the Native Minter Precompile: + +```bash +cast send --rpc-url myblockchain --private-key $PK 0x0200000000000000000000000000000000000001 "setEnabled(address)" $NATIVE_TOKEN_REMOTE_L1 +``` + +- `$NATIVE_TOKEN_REMOTE_L1`: The deployed address of the `NativeTokenRemote` contract on your L1. + +Once this step is completed, the `NativeTokenRemote` contract will have the necessary permissions to mint native tokens when ERC-20 tokens are transferred from the C-Chain. + + +### Register Remote Token with Home Transferer +Register the remote token on the home chain so that it recognizes the transferer contracts. + +```bash +cast send --rpc-url myblockchain --private-key $PK $NATIVE_TOKEN_REMOTE_L1 "registerWithHome((address, uint256))" "(0x0000000000000000000000000000000000000000, 0)" +``` + + +### Collateralize and Transfer Tokens +Add collateral to the transferer contract on the home chain, and then send the ERC-20 tokens across chains. + + + +Collateral in this context refers to the amount of the token that is locked in the `Home Transferer contract` on the source chain (`C-Chain`) to back the value of the token on the destination chain (`myblockchain`). This ensures that for every token minted on the remote chain, there’s an equivalent token locked as collateral on the home chain. + + +Collateralization ensures that the total supply of the token remains consistent across both chains. When tokens are sent from the `home chain`, they are locked as collateral, and a corresponding number of tokens is minted on the remote chain. If tokens are sent back to the home chain, the collateral is unlocked, and the minted tokens on the remote chain are burned. + + + +- **Approve Tokens for Transfer** +Approve a certain number of tokens to be used by the Home Transferer. + +```bash +cast send --rpc-url local-c --private-key $PK $ERC20_HOME_C_CHAIN "approve(address, uint256)" $ERC20_HOME_TRANSFERER_C_CHAIN 2000000000000000000000 +``` + +- **Add Collateral and Send Tokens** +Add collateral to the transferer contract. +```bash +cast send --rpc-url local-c --private-key $PK $ERC20_HOME_TRANSFERER_C_CHAIN "addCollateral(bytes32, address, uint256)" $L1_BLOCKCHAIN_ID_HEX $NATIVE_TOKEN_REMOTE_L1 100000000000000000000 +``` +Send tokens to the L1 +```bash +cast send --rpc-url local-c --private-key $PK $ERC20_HOME_TRANSFERER_C_CHAIN "send((bytes32, address, address, address, uint256, uint256, uint256, address), uint256)" "(${L1_BLOCKCHAIN_ID_HEX}, ${NATIVE_TOKEN_REMOTE_L1}, ${FUNDED_ADDRESS}, ${ERC20_HOME_C_CHAIN}, 0, 0, 250000, 0x0000000000000000000000000000000000000000)" 1000000000000000000000 +``` + + + +--- + +### Conclusion + +Follow the steps above to transfer an ERC-20 token from the C-Chain to your custom Avalanche L1 and use it as the native token. This exercise will demonstrate how Avalanche’s **Interchain Token Transfer (ICTT)** system works, ensuring that tokens are properly locked, transferred, and minted across multiple chains. + +For more detailed information, refer to the [official Avalanche ICTT documentation](/course/interchain-token-transfer). diff --git a/content/course/l1-tokenomics/03-multi-chain-ecosystems/04-use-any-native-as-native-token.mdx b/content/course/l1-tokenomics/03-multi-chain-ecosystems/04-use-any-native-as-native-token.mdx new file mode 100644 index 00000000..30c0bfaf --- /dev/null +++ b/content/course/l1-tokenomics/03-multi-chain-ecosystems/04-use-any-native-as-native-token.mdx @@ -0,0 +1,148 @@ +--- +title: Use any Native as Native Token (DIY) +description: Learn how to transfer a native token to a new Avalanche L1 and use it as the native token via ICTT. +updated: 2024-09-03 +authors: [0xstt] +icon: Terminal +--- +import { Step, Steps } from 'fumadocs-ui/components/steps'; + +In this section, you will learn how to transfer a native token from Avalanche’s C-Chain to a new Avalanche L1 using Interchain Token Transfers (ICTT) and set it up to act as the **native token** on the new L1. This guide will walk you through each step, from creating a L1 to transferring and using the native token. + + + +### Create a new blockchain and Deploy on Local Network + +Use the `avalanche` CLI to create a new blockchain where you will deploy the ERC-20 as the native token. + + +```bash +avalanche blockchain create myblockchain +``` +```bash +avalanche blockchain deploy myblockchain +``` + +Take note of the important addresses (e.g., `Teleporter Registry`, `Funded Address`) from the deployment output as they will be needed in the following steps. + + +### Wrap the Native Token on C-Chain + +You'll need to deploy a wrapped token contract for your native token on the C-Chain. The wrapped token will serve as the transferable asset between the chains. + +```bash +forge create --rpc-url local-c --private-key $PK lib/avalanche-interchain-token-transfer/contracts/src/WrappedNativeToken.sol:WrappedNativeToken +``` + +After deployment, save the `Deployed to` address in an environment variable for future use. + +```bash +export WRAPPED_NATIVE_C_CHAIN=
+``` + + +### Deploy Interchain Token Transfer Contracts + +Now, deploy the Interchain Token Transfer contracts on both the `C-Chain` and the `myblockchain` to enable cross-chain token transfers. + +- `NativeTokenHome` Contract on C-Chain + +```bash +forge create --rpc-url local-c --private-key $PK lib/avalanche-interchain-token-transfer/contracts/src/TokenHome/NativeTokenHome.sol:NativeTokenHome --constructor-args $TELEPORTER_REGISTRY_C_CHAIN $FUNDED_ADDRESS $WRAPPED_NATIVE_C_CHAIN +``` + +- `NativeTokenRemote` Contract on `myblockchain` + +```bash +forge create --rpc-url myblockchain --private-key $PK lib/avalanche-interchain-token-transfer/contracts/src/TokenRemote/NativeTokenRemote.sol:NativeTokenRemote --constructor-args "(${TELEPORTER_REGISTRY_L1}, ${FUNDED_ADDRESS}, ${C_CHAIN_BLOCKCHAIN_ID_HEX}, ${NATIVE_HOME_TRANSFERER_C_CHAIN})" "NATV" 700000000000000000000 0 false 0 +``` + +_Note: Ensure that the initial amount matches the native token amount minted on the C-Chain during the wrapped token deployment._ + +Export the deployed addresses as environment variables: + +``` +export NATIVE_HOME_TRANSFERER_C_CHAIN=<"Deployed to" address> +export NATIVE_TOKEN_REMOTE_L1=<"Deployed to" address> +``` + + +### Grant Native Minting Rights to NativeTokenRemote + +To ensure that the `NativeTokenRemote` contract can mint native tokens on the L1 when ERC-20 tokens are transferred from the `C-Chain`, the contract must be granted **minting rights**. This is done by adding the `NativeTokenRemote` contract address to the `Native Minter Precompile`. + +1. You will need to interact with the `Native Minter Precompile`, which resides at a fixed address on all Avalanche L1s: +**Native Minter Precompile Address**: `0x0200000000000000000000000000000000000001` + +2. Use the following command to grant the `NativeTokenRemote` contract minting rights by setting it as an **enabled** address on the Native Minter Precompile: + +```bash +cast send --rpc-url myblockchain --private-key $PK 0x0200000000000000000000000000000000000001 "setEnabled(address)" $NATIVE_TOKEN_REMOTE_L1 +``` + +- `$NATIVE_TOKEN_REMOTE_L1`: The deployed address of the `NativeTokenRemote` contract on your L1. + +Once this step is completed, the `NativeTokenRemote` contract will have the necessary permissions to mint native tokens when ERC-20 tokens are transferred from the C-Chain. + + +### Register Remote Token with Home Transferer +Register the remote token on the home chain so that it recognizes the transferer contracts. + +```bash +cast send --rpc-url myblockchain --private-key $PK $NATIVE_TOKEN_REMOTE_L1 "registerWithHome((address, uint256))" "(0x0000000000000000000000000000000000000000, 0)" +``` + + +### Collateralize and Transfer Tokens +Collateralize the home contract by locking native tokens. The amount of collateral should match the initial token reserve set on the `myblockchain`. + + + +Collateral in this context refers to the amount of the token that is locked in the `Home Transferer contract` on the source chain (`C-Chain`) to back the value of the token on the destination chain (`myblockchain`). This ensures that for every token minted on the remote chain, there’s an equivalent token locked as collateral on the home chain. + + +Collateralization ensures that the total supply of the token remains consistent across both chains. When tokens are sent from the `home chain`, they are locked as collateral, and a corresponding number of tokens is minted on the remote chain. If tokens are sent back to the home chain, the collateral is unlocked, and the minted tokens on the remote chain are burned. + + + +- **Approve Tokens for Transfer** +Approve a certain number of tokens to be used by the Home Transferer. + +```bash +cast send --rpc-url local-c --private-key $PK $ERC20_HOME_C_CHAIN "approve(address, uint256)" $ERC20_HOME_TRANSFERER_C_CHAIN 2000000000000000000000 +``` + +- **Add Collateral and Send Tokens** +Add collateral to the transferer contract. +```bash +cast send --rpc-url local-c --private-key $PK $ERC20_HOME_TRANSFERER_C_CHAIN "addCollateral(bytes32, address, uint256)" $L1_BLOCKCHAIN_ID_HEX $NATIVE_TOKEN_REMOTE_L1 100000000000000000000 +``` +Send tokens to the L1. +```bash +cast send --rpc-url local-c --private-key $PK $ERC20_HOME_TRANSFERER_C_CHAIN "send((bytes32, address, address, address, uint256, uint256, uint256, address), uint256)" "(${L1_BLOCKCHAIN_ID_HEX}, ${NATIVE_TOKEN_REMOTE_L1}, ${FUNDED_ADDRESS}, ${ERC20_HOME_C_CHAIN}, 0, 0, 250000, 0x0000000000000000000000000000000000000000)" 1000000000000000000000 +``` + + +### Check Balances + +Finally, check the balance on the L1 to confirm that the tokens were successfully transferred and minted. + +```bash +cast balance --rpc-url myblockchain $FUNDED_ADDRESS +``` + +You can also verify that the token is collateralized: + +```bash +cast call --rpc-url myblockchain $NATIVE_TOKEN_REMOTE_L1 "isCollateralized()(bool)" +``` + + + +--- + +### Conclusion + +By following these steps, you’ll successfully transfer a native token from the C-Chain to a L1 and use it as the native token via Avalanche’s Interchain Token Transfer system. + +For more detailed information, refer to the refer to the [official Avalanche ICTT documentation](/course/interchain-token-transfer). \ No newline at end of file diff --git a/content/course/l1-tokenomics/03-multi-chain-ecosystems/05-cross-chain-liquidity-pools.mdx b/content/course/l1-tokenomics/03-multi-chain-ecosystems/05-cross-chain-liquidity-pools.mdx new file mode 100644 index 00000000..3ee59d1a --- /dev/null +++ b/content/course/l1-tokenomics/03-multi-chain-ecosystems/05-cross-chain-liquidity-pools.mdx @@ -0,0 +1,11 @@ +--- +title: Cross-Chain Liquidity Pools +description: Enter description +updated: 2024-09-03 +authors: [0xstt] +icon: Microscope +--- + +TBD +WIP: Implementation + diff --git a/content/course/l1-tokenomics/03-multi-chain-ecosystems/06-quiz-time.mdx b/content/course/l1-tokenomics/03-multi-chain-ecosystems/06-quiz-time.mdx new file mode 100644 index 00000000..570bd9b0 --- /dev/null +++ b/content/course/l1-tokenomics/03-multi-chain-ecosystems/06-quiz-time.mdx @@ -0,0 +1,21 @@ +--- +title: Quiz Time +description: Check your Progress! +updated: 2024-09-03 +authors: [0xstt] +icon: Terminal +--- + +You've made it to the end of the section. Let's check your progress. + +--- + + +--- + +--- + +--- + +--- + diff --git a/content/course/l1-tokenomics/04-staking/01-staking-tokens.mdx b/content/course/l1-tokenomics/04-staking/01-staking-tokens.mdx new file mode 100644 index 00000000..643ba488 --- /dev/null +++ b/content/course/l1-tokenomics/04-staking/01-staking-tokens.mdx @@ -0,0 +1,9 @@ +--- +title: Introduction +description: Enter description +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +TBD diff --git a/content/course/l1-tokenomics/04-staking/02-liquid-staking.mdx b/content/course/l1-tokenomics/04-staking/02-liquid-staking.mdx new file mode 100644 index 00000000..ac870a1d --- /dev/null +++ b/content/course/l1-tokenomics/04-staking/02-liquid-staking.mdx @@ -0,0 +1,9 @@ +--- +title: Liquid Staking +description: Enter description +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +TBD diff --git a/content/course/l1-tokenomics/04-staking/03-staking-contract-post-etna.mdx b/content/course/l1-tokenomics/04-staking/03-staking-contract-post-etna.mdx new file mode 100644 index 00000000..d2de04c6 --- /dev/null +++ b/content/course/l1-tokenomics/04-staking/03-staking-contract-post-etna.mdx @@ -0,0 +1,9 @@ +--- +title: Staking Contract (post Etna Upgrade) +description: Enter description +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +TBD diff --git a/content/course/l1-tokenomics/05-transaction-fees/01-introduction.mdx b/content/course/l1-tokenomics/05-transaction-fees/01-introduction.mdx new file mode 100644 index 00000000..643ba488 --- /dev/null +++ b/content/course/l1-tokenomics/05-transaction-fees/01-introduction.mdx @@ -0,0 +1,9 @@ +--- +title: Introduction +description: Enter description +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +TBD diff --git a/content/course/l1-tokenomics/05-transaction-fees/02-transaction-fee-configuration.mdx b/content/course/l1-tokenomics/05-transaction-fees/02-transaction-fee-configuration.mdx new file mode 100644 index 00000000..c87e2202 --- /dev/null +++ b/content/course/l1-tokenomics/05-transaction-fees/02-transaction-fee-configuration.mdx @@ -0,0 +1,9 @@ +--- +title: Transaction Fee Configuration +description: Enter description +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +TBD diff --git a/content/course/l1-tokenomics/05-transaction-fees/03-dynamic-fee-configuration.mdx b/content/course/l1-tokenomics/05-transaction-fees/03-dynamic-fee-configuration.mdx new file mode 100644 index 00000000..712f12da --- /dev/null +++ b/content/course/l1-tokenomics/05-transaction-fees/03-dynamic-fee-configuration.mdx @@ -0,0 +1,9 @@ +--- +title: Dynamic Fee Configuration +description: Enter description +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +TBD diff --git a/content/course/l1-tokenomics/05-transaction-fees/04-fee-distribution.mdx b/content/course/l1-tokenomics/05-transaction-fees/04-fee-distribution.mdx new file mode 100644 index 00000000..627911bb --- /dev/null +++ b/content/course/l1-tokenomics/05-transaction-fees/04-fee-distribution.mdx @@ -0,0 +1,9 @@ +--- +title: Fee Distribution +description: Enter description +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +TBD diff --git a/content/course/l1-tokenomics/06-distribution/01-initial-allocation.mdx b/content/course/l1-tokenomics/06-distribution/01-initial-allocation.mdx new file mode 100644 index 00000000..3ec012e0 --- /dev/null +++ b/content/course/l1-tokenomics/06-distribution/01-initial-allocation.mdx @@ -0,0 +1,9 @@ +--- +title: Initial Allocation +description: Enter description +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +TBD diff --git a/content/course/l1-tokenomics/06-distribution/02-vesting-schedules.mdx b/content/course/l1-tokenomics/06-distribution/02-vesting-schedules.mdx new file mode 100644 index 00000000..a23315de --- /dev/null +++ b/content/course/l1-tokenomics/06-distribution/02-vesting-schedules.mdx @@ -0,0 +1,9 @@ +--- +title: Vesting Schedules +description: Enter description +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +TBD diff --git a/content/course/l1-tokenomics/06-distribution/03-bonding-curves.mdx b/content/course/l1-tokenomics/06-distribution/03-bonding-curves.mdx new file mode 100644 index 00000000..c8a4c12b --- /dev/null +++ b/content/course/l1-tokenomics/06-distribution/03-bonding-curves.mdx @@ -0,0 +1,9 @@ +--- +title: Bonding Curves +description: Enter description +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +TBD diff --git a/content/course/l1-tokenomics/06-distribution/04-airdrop.mdx b/content/course/l1-tokenomics/06-distribution/04-airdrop.mdx new file mode 100644 index 00000000..05ac7b22 --- /dev/null +++ b/content/course/l1-tokenomics/06-distribution/04-airdrop.mdx @@ -0,0 +1,9 @@ +--- +title: Airdrop +description: Enter description +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +TBD diff --git a/content/course/l1-tokenomics/07-governance/01-introduction.mdx b/content/course/l1-tokenomics/07-governance/01-introduction.mdx new file mode 100644 index 00000000..643ba488 --- /dev/null +++ b/content/course/l1-tokenomics/07-governance/01-introduction.mdx @@ -0,0 +1,9 @@ +--- +title: Introduction +description: Enter description +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +TBD diff --git a/content/course/l1-tokenomics/07-governance/02-governance-models.mdx b/content/course/l1-tokenomics/07-governance/02-governance-models.mdx new file mode 100644 index 00000000..0350b934 --- /dev/null +++ b/content/course/l1-tokenomics/07-governance/02-governance-models.mdx @@ -0,0 +1,9 @@ +--- +title: Governance Models +description: Enter description +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +TBD diff --git a/content/course/l1-tokenomics/07-governance/03-daos.mdx b/content/course/l1-tokenomics/07-governance/03-daos.mdx new file mode 100644 index 00000000..7357c6b2 --- /dev/null +++ b/content/course/l1-tokenomics/07-governance/03-daos.mdx @@ -0,0 +1,9 @@ +--- +title: DAOs +description: Enter description +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +TBD diff --git a/content/course/l1-tokenomics/07-governance/04-quadratic-voting.mdx b/content/course/l1-tokenomics/07-governance/04-quadratic-voting.mdx new file mode 100644 index 00000000..e4ef1809 --- /dev/null +++ b/content/course/l1-tokenomics/07-governance/04-quadratic-voting.mdx @@ -0,0 +1,9 @@ +--- +title: Quadratic Voting +description: Enter description +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +TBD diff --git a/content/course/l1-tokenomics/07-governance/05-governance-20.mdx b/content/course/l1-tokenomics/07-governance/05-governance-20.mdx new file mode 100644 index 00000000..09820239 --- /dev/null +++ b/content/course/l1-tokenomics/07-governance/05-governance-20.mdx @@ -0,0 +1,9 @@ +--- +title: Governance 2.0 +description: Enter description +updated: 2024-09-03 +authors: [0xstt] +icon: Book +--- + +TBD diff --git a/content/course/l1-tokenomics/index.mdx b/content/course/l1-tokenomics/index.mdx new file mode 100644 index 00000000..9614a832 --- /dev/null +++ b/content/course/l1-tokenomics/index.mdx @@ -0,0 +1,82 @@ +--- +title: Welcome to the Course +description: Learn about the L1 Tokenomics. +updated: 2024-09-04 +authors: [0xstt] +icon: Smile +--- + +Welcome to the **L1 Tokenomics** course! This course is designed to give you a deep understanding of tokenomics, including the creation, distribution, utility, and governance of tokens within blockchain ecosystems. By the end of this course, you will have practical skills in managing tokens across multi-chain ecosystems, configuring transaction fees, and designing staking and governance models. + +## Course Content + +### Basics + +Learn the fundamentals of tokenomics, including native tokens, ERC-20 tokens, wrapped tokens, and how token decimals affect transactions and supply. + +### Native Tokens + +Explore how to create custom native tokens, use Avalanche’s native token minter, and integrate ERC-20 tokens as native tokens in cross-chain environments. + +### Multi-Chain Ecosystems + +Delve into interchain token transfers and cross-chain functionality, using both ERC-20 and native tokens across multiple blockchains. + +### Staking + +Understand staking tokens, liquid staking, and how to deploy staking contracts, with a focus on post-Etna upgrade features. + +### Transaction Fees + +Master transaction fee configuration, dynamic fee models, and learn how to distribute fees effectively within decentralized ecosystems. + +### Token Distribution + +Learn about initial token allocation, advanced vesting schedules, bonding curves for token pricing, and how to implement airdrops. + +### Governance + +Study governance models, DAOs, quadratic voting, and the latest innovations in governance (Governance 2.0) for decentralized decision-making. + +--- + +## Prerequisites + +Before starting this course, you should have: + +### Basic Understanding of Blockchain + +This course is for people with some blockchain knowledge. Check out this [guide](/guide/what-is-a-blockchain) to review what a blockchain is. + +### Avalanche + +This course is intended for people with knowledge about Cross-Chain communication protocols, and a solid understanding of the basic concepts of Avalanche. You should be familiar with these concepts: + +1. Avalanche Architecture: Be familiar with Avalanche blockchains. +2. Cross-Chain Messages: Know how to communicate between two Avalanche blockchains with Teleporter. + +If some of this is not clear, we strongly recommend taking the Avalanche Fundamentals, Multi-Chain Architecture, and Interchain Messaging courses first. + +### Software Development + +You will need a general understanding of Software Development. You won't have to write a lot of code, but you will have to be able to understand some. Therefore, we recommend: + +1. Solidity: Basic Knowledge, familiarity with types and interfaces. +2. Foundry: Familiarity with Foundry will help to deploy and interact with contracts. + +--- + +## Learning Outcomes + +By the end of this course, you will: + +- Gain a solid grasp of token fundamentals, tokenomics models, and how to create sustainable token economies. +- Learn how to create custom native tokens and integrate ERC-20 tokens as native tokens in multi-chain environments. +- Understand the challenges and opportunities in cross-chain token transfers, and liquidity management. +- Master the technical aspects of configuring transaction fees, setting up staking contracts, and designing dynamic fee models. +- Create initial allocation plans, implement advanced vesting schedules, and manage bonding curves and airdrops. +- Develop governance structures, including DAOs and quadratic voting models, to manage decentralized decision-making effectively. + +--- + +Start exploring the course content now to dive deep into the exciting world of tokenomics! diff --git a/content/course/l1-tokenomics/meta.json b/content/course/l1-tokenomics/meta.json new file mode 100644 index 00000000..932108a1 --- /dev/null +++ b/content/course/l1-tokenomics/meta.json @@ -0,0 +1,22 @@ +{ + "title": "l1-tokenomics", + "root": true, + "pages": [ + "index", + "---Basics---", + "...01-basics", + "---Advanced---", + "---Native Tokens---", + "...02-native-tokens", + "---Multi-Chain Ecosystems---", + "...03-multi-chain-ecosystems", + "---Staking---", + "...04-staking", + "---Transaction Fees---", + "...05-transaction-fees", + "---Token Distribution---", + "...06-distribution", + "---Governance---", + "...07-governance" + ] +} diff --git a/content/courses.tsx b/content/courses.tsx index bd538c55..dd14fee8 100644 --- a/content/courses.tsx +++ b/content/courses.tsx @@ -1,5 +1,5 @@ -import { ArrowLeftRight, MailIcon, SquareCode, SquareIcon, SquareStackIcon, Triangle } from 'lucide-react'; +import { ArrowLeftRight, Coins, MailIcon, SquareCode, SquareIcon, SquareStackIcon, Triangle } from 'lucide-react'; export type Course = { name: string; @@ -65,9 +65,9 @@ const officialCourses: Course[] = [ icon: , featured: true, duration: "2.5 hours", - tools: ["Telepoter", "Foundry"], + tools: ["ICM", "Foundry"], languages: ["Solidity"], - instructors: ["Martin Eckardt", "Andrea Vargas", "Ash", "Owen Wahlgren"] + instructors: ["Martin Eckardt", "Andrea Vargas", "Ash", "Owen Wahlgren", "Sarp"] }, /*{ name:"Chainlink VRF with Interchain Messaging ", @@ -99,7 +99,18 @@ const officialCourses: Course[] = [ languages: ["Go"], instructors: ["Martin Eckardt", "Ash"] // + Usman }, - { + { + name:"Layer 1 Tokenomics", + description:"Learn how to design and deploy tokenomics for your Avalanche L1", + slug:"l1-tokenomics", + icon: , + duration: "2 hours", + featured: true, + tools: ["Avalanche-CLI", "ICM"], + languages: ["Solidity"], + instructors: ["Sarp"] + }, + { name:"AvaCloud APIs", description:"Learn how to leverage AvaCloud APIs to build web apps on Avalanche", slug:"avacloudapis", diff --git a/public/backup.png b/public/backup.png new file mode 100644 index 00000000..f8ac9956 Binary files /dev/null and b/public/backup.png differ diff --git a/public/common-images/intro/instructors/sarp.jpeg b/public/common-images/intro/instructors/sarp.jpeg new file mode 100644 index 00000000..fbcff86e Binary files /dev/null and b/public/common-images/intro/instructors/sarp.jpeg differ diff --git a/public/course-banner/l1-tokenomics.jpg b/public/course-banner/l1-tokenomics.jpg new file mode 100644 index 00000000..73cb2cae Binary files /dev/null and b/public/course-banner/l1-tokenomics.jpg differ diff --git a/public/course-images/ictt/ictt.png b/public/course-images/ictt/ictt.png new file mode 100644 index 00000000..f9e4c0e8 Binary files /dev/null and b/public/course-images/ictt/ictt.png differ diff --git a/public/logo.png b/public/logo.png index f8ac9956..0662dbb2 100644 Binary files a/public/logo.png and b/public/logo.png differ