From d9aedad7bfa541ccf7fd76193a24191d67d99031 Mon Sep 17 00:00:00 2001 From: Owen Date: Wed, 19 Nov 2025 15:44:04 -0500 Subject: [PATCH 01/19] nuke it --- app/(home)/docs/page.tsx | 2 +- app/(home)/page.tsx | 15 +- app/(home)/university/page.tsx | 2 + app/docs/[...slug]/page.tsx | 2 + app/docs/docs-layout-wrapper.tsx | 19 +- app/layout.config.tsx | 10 +- components/client/AddNetworkButtonInline.tsx | 101 ++++++ components/landing/academy-splash.tsx | 265 +++++++------- components/landing/development.tsx | 2 +- components/landing/hero.tsx | 6 +- components/landing/paths.tsx | 33 +- components/landing/quicklinks.tsx | 40 +-- .../navigation/active-nav-highlighter.tsx | 4 +- components/navigation/docs-subnav.tsx | 5 +- components/navigation/footer.tsx | 19 +- components/navigation/navbar-dropdown.tsx | 4 +- .../background-requirements.mdx | 0 .../custom-precompiles/create-precompile.mdx | 0 .../defining-precompile.mdx | 0 .../defining-test-cases.mdx | 0 .../executing-test-cases.mdx | 0 .../custom-precompiles/index.mdx | 0 .../precompile-deployment.mdx | 0 .../golang-vms/complex-golang-vm.mdx | 0 .../golang-vms/simple-golang-vm.mdx | 0 content/docs/avalanche-l1s/index.mdx | 73 ++-- .../manage-vm-binaries.mdx | 0 content/docs/avalanche-l1s/meta.json | 14 + .../rust-vms/installing-vm.mdx | 0 .../rust-vms/intro-avalanche-rs.mdx | 0 .../rust-vms/setting-up-environment.mdx | 0 .../simple-vm-any-language.mdx | 0 .../timestamp-vm/apis.mdx | 0 .../timestamp-vm/blocks.mdx | 0 .../timestamp-vm/defining-vm-itself.mdx | 0 .../timestamp-vm/introduction.mdx | 0 .../timestamp-vm/meta.json | 0 .../timestamp-vm/state.mdx | 0 .../validator-manager.mdx | 0 .../virtual-machines-index.mdx} | 0 .../add-network-programmatically.mdx | 134 ------- .../advanced-tutorials/dynamic-gas-fees.mdx | 216 ------------ .../manually-adjust-gas-price.mdx | 99 ------ .../docs/dapps/c-chain-or-avalanche-l1.mdx | 28 -- .../deploy-nft-collection/deploy-erc-721.mdx | 174 --------- .../dapps/deploy-nft-collection/index.mdx | 5 - .../deploy-nft-collection/prep-nft-files.mdx | 90 ----- .../docs/dapps/end-to-end/fuji-workflow.mdx | 332 ------------------ .../dapps/end-to-end/launch-ethereum-dapp.mdx | 322 ----------------- content/docs/dapps/index.mdx | 163 +++++++-- content/docs/dapps/meta.json | 8 +- .../dapps/smart-contract-dev/erc-20-token.mdx | 132 ------- .../smart-contract-dev/get-test-funds.mdx | 31 -- .../interact-golang-app.mdx | 173 --------- content/docs/nodes/meta.json | 4 - .../avalanche-consensus.mdx | 36 +- .../avax-token.mdx | 0 content/docs/primary-network/index.mdx | 93 +++++ content/docs/primary-network/meta.json | 18 + .../validate/how-to-stake.mdx | 0 .../validate/node-validator.mdx | 0 .../validate}/rewards-formula.mdx | 0 .../validate/validate-vs-delegate.mdx | 0 .../validate/what-is-staking.mdx | 0 .../virtual-machines.mdx | 0 .../avalanche-community-proposals.mdx | 103 ------ content/docs/quick-start/avalanche-l1s.mdx | 69 ---- content/docs/quick-start/disclaimer.mdx | 17 - content/docs/quick-start/index.mdx | 29 -- content/docs/quick-start/meta.json | 23 -- .../quick-start/networks/fuji-testnet.mdx | 31 -- content/docs/quick-start/networks/mainnet.mdx | 21 -- content/docs/quick-start/primary-network.mdx | 44 --- .../virtual-machines/evm-l1-customization.mdx | 42 --- content/docs/virtual-machines/meta.json | 24 -- content/integrations-contributing.md | 150 -------- 76 files changed, 632 insertions(+), 2595 deletions(-) create mode 100644 components/client/AddNetworkButtonInline.tsx rename content/docs/{virtual-machines => avalanche-l1s}/custom-precompiles/background-requirements.mdx (100%) rename content/docs/{virtual-machines => avalanche-l1s}/custom-precompiles/create-precompile.mdx (100%) rename content/docs/{virtual-machines => avalanche-l1s}/custom-precompiles/defining-precompile.mdx (100%) rename content/docs/{virtual-machines => avalanche-l1s}/custom-precompiles/defining-test-cases.mdx (100%) rename content/docs/{virtual-machines => avalanche-l1s}/custom-precompiles/executing-test-cases.mdx (100%) rename content/docs/{virtual-machines => avalanche-l1s}/custom-precompiles/index.mdx (100%) rename content/docs/{virtual-machines => avalanche-l1s}/custom-precompiles/precompile-deployment.mdx (100%) rename content/docs/{virtual-machines => avalanche-l1s}/golang-vms/complex-golang-vm.mdx (100%) rename content/docs/{virtual-machines => avalanche-l1s}/golang-vms/simple-golang-vm.mdx (100%) rename content/docs/{virtual-machines => avalanche-l1s}/manage-vm-binaries.mdx (100%) rename content/docs/{virtual-machines => avalanche-l1s}/rust-vms/installing-vm.mdx (100%) rename content/docs/{virtual-machines => avalanche-l1s}/rust-vms/intro-avalanche-rs.mdx (100%) rename content/docs/{virtual-machines => avalanche-l1s}/rust-vms/setting-up-environment.mdx (100%) rename content/docs/{virtual-machines => avalanche-l1s}/simple-vm-any-language.mdx (100%) rename content/docs/{virtual-machines => avalanche-l1s}/timestamp-vm/apis.mdx (100%) rename content/docs/{virtual-machines => avalanche-l1s}/timestamp-vm/blocks.mdx (100%) rename content/docs/{virtual-machines => avalanche-l1s}/timestamp-vm/defining-vm-itself.mdx (100%) rename content/docs/{virtual-machines => avalanche-l1s}/timestamp-vm/introduction.mdx (100%) rename content/docs/{virtual-machines => avalanche-l1s}/timestamp-vm/meta.json (100%) rename content/docs/{virtual-machines => avalanche-l1s}/timestamp-vm/state.mdx (100%) rename content/docs/{quick-start => avalanche-l1s}/validator-manager.mdx (100%) rename content/docs/{virtual-machines/index.mdx => avalanche-l1s/virtual-machines-index.mdx} (100%) delete mode 100644 content/docs/dapps/advanced-tutorials/add-network-programmatically.mdx delete mode 100644 content/docs/dapps/advanced-tutorials/dynamic-gas-fees.mdx delete mode 100644 content/docs/dapps/advanced-tutorials/manually-adjust-gas-price.mdx delete mode 100644 content/docs/dapps/c-chain-or-avalanche-l1.mdx delete mode 100644 content/docs/dapps/deploy-nft-collection/deploy-erc-721.mdx delete mode 100644 content/docs/dapps/deploy-nft-collection/index.mdx delete mode 100644 content/docs/dapps/deploy-nft-collection/prep-nft-files.mdx delete mode 100644 content/docs/dapps/end-to-end/fuji-workflow.mdx delete mode 100644 content/docs/dapps/end-to-end/launch-ethereum-dapp.mdx delete mode 100644 content/docs/dapps/smart-contract-dev/erc-20-token.mdx delete mode 100644 content/docs/dapps/smart-contract-dev/get-test-funds.mdx delete mode 100644 content/docs/dapps/smart-contract-dev/interact-golang-app.mdx rename content/docs/{quick-start => primary-network}/avalanche-consensus.mdx (80%) rename content/docs/{quick-start => primary-network}/avax-token.mdx (100%) create mode 100644 content/docs/primary-network/index.mdx create mode 100644 content/docs/primary-network/meta.json rename content/docs/{nodes => primary-network}/validate/how-to-stake.mdx (100%) rename content/docs/{nodes => primary-network}/validate/node-validator.mdx (100%) rename content/docs/{quick-start => primary-network/validate}/rewards-formula.mdx (100%) rename content/docs/{nodes => primary-network}/validate/validate-vs-delegate.mdx (100%) rename content/docs/{nodes => primary-network}/validate/what-is-staking.mdx (100%) rename content/docs/{quick-start => primary-network}/virtual-machines.mdx (100%) delete mode 100644 content/docs/quick-start/avalanche-community-proposals.mdx delete mode 100644 content/docs/quick-start/avalanche-l1s.mdx delete mode 100644 content/docs/quick-start/disclaimer.mdx delete mode 100644 content/docs/quick-start/index.mdx delete mode 100644 content/docs/quick-start/meta.json delete mode 100644 content/docs/quick-start/networks/fuji-testnet.mdx delete mode 100644 content/docs/quick-start/networks/mainnet.mdx delete mode 100644 content/docs/quick-start/primary-network.mdx delete mode 100644 content/docs/virtual-machines/evm-l1-customization.mdx delete mode 100644 content/docs/virtual-machines/meta.json delete mode 100644 content/integrations-contributing.md diff --git a/app/(home)/docs/page.tsx b/app/(home)/docs/page.tsx index aaaec2c5cd4..e8c3b218cc0 100644 --- a/app/(home)/docs/page.tsx +++ b/app/(home)/docs/page.tsx @@ -1,5 +1,5 @@ import { redirect } from 'next/navigation'; export default function DocsPage() { - redirect('/docs/quick-start'); + redirect('/docs/dapps'); } diff --git a/app/(home)/page.tsx b/app/(home)/page.tsx index f98e0c9e958..9cefba2afa7 100644 --- a/app/(home)/page.tsx +++ b/app/(home)/page.tsx @@ -1,23 +1,16 @@ import Hero, { HeroBackground } from '@/components/landing/hero'; import Paths from '@/components/landing/paths'; import QuickLinks from '@/components/landing/quicklinks'; -import AcademySplash from '@/components/landing/academy-splash'; -import StudentCallout from '@/components/landing/student-callout'; export default function HomePage(): React.ReactElement { return ( <> -
- {/* */} - - - - - {/* */} - {/* */} -
+
+ + {/* */} +
); } \ No newline at end of file diff --git a/app/(home)/university/page.tsx b/app/(home)/university/page.tsx index 24b999aa32a..5d122913ad2 100644 --- a/app/(home)/university/page.tsx +++ b/app/(home)/university/page.tsx @@ -21,6 +21,7 @@ import { import Link from "next/link"; import { HeroBackground } from "@/components/landing/hero"; import UniversitySlideshow from "@/components/university/UniversitySlideshow"; +import StudentCallout from '@/components/landing/student-callout'; interface ProgramCardProps { title: string; @@ -299,6 +300,7 @@ export default function Page() { + {/* CTA Section */}
diff --git a/app/docs/[...slug]/page.tsx b/app/docs/[...slug]/page.tsx index 91697dc10f5..edd926a5a28 100644 --- a/app/docs/[...slug]/page.tsx +++ b/app/docs/[...slug]/page.tsx @@ -5,6 +5,7 @@ import { BackToTop } from "@/components/ui/back-to-top"; import { Feedback } from "@/components/ui/feedback"; import { SidebarActions } from "@/components/ui/sidebar-actions"; import { CChainAPIPage, DataAPIPage, MetricsAPIPage, PChainAPIPage, XChainAPIPage } from "@/components/api/api-pages"; +import AddNetworkButtonInline from "@/components/client/AddNetworkButtonInline"; import { documentation } from "@/lib/source"; import { createMetadata } from "@/utils/metadata"; import { Popup, PopupContent, PopupTrigger } from "fumadocs-twoslash/ui"; @@ -112,6 +113,7 @@ export default async function Page(props: { Steps, YouTube, Mermaid, + AddNetworkButtonInline, TypeTable, AutoTypeTable, Accordion, diff --git a/app/docs/docs-layout-wrapper.tsx b/app/docs/docs-layout-wrapper.tsx index 96157dd2790..d89d20b99f6 100644 --- a/app/docs/docs-layout-wrapper.tsx +++ b/app/docs/docs-layout-wrapper.tsx @@ -13,7 +13,6 @@ import { Code, Layers, Cable, - Cpu, Server, Database, Activity, @@ -112,18 +111,18 @@ export function DocsLayoutWrapper({ // Documentation hamburger menu options const documentationOptions = [ - { - title: 'Quick-start', - description: 'Get started with Avalanche', - icon: , - url: '/docs/quick-start', - }, { title: 'Build Apps', description: 'Build dApps on Avalanche', icon: , url: '/docs/dapps', }, + { + title: 'Primary Network', + description: 'Core platform infrastructure', + icon: , + url: '/docs/primary-network', + }, { title: 'Avalanche L1s', description: 'Build your own blockchain', @@ -136,12 +135,6 @@ export function DocsLayoutWrapper({ icon: , url: '/docs/cross-chain', }, - { - title: 'Custom VMs', - description: 'Build custom virtual machines', - icon: , - url: '/docs/virtual-machines', - }, { title: 'Nodes and Validators', description: 'Run network infrastructure', diff --git a/app/layout.config.tsx b/app/layout.config.tsx index a18569bfd7a..af6aa99d475 100644 --- a/app/layout.config.tsx +++ b/app/layout.config.tsx @@ -141,7 +141,7 @@ export const stats: LinkItemType = { export const docsMenu: LinkItemType = { type: 'menu', text: 'Documentation', - url: '/docs/quick-start', + url: '/docs/dapps', items: [ { menu: { @@ -162,9 +162,9 @@ export const docsMenu: LinkItemType = { className: 'md:row-span-2', }, icon: , - text: 'Avalanche Protocol', - description: 'Learn about the Avalanche Protocol', - url: '/docs/quick-start', + text: 'Build Apps', + description: 'Build dApps on Avalanche', + url: '/docs/dapps', }, { icon: , @@ -201,7 +201,7 @@ export const docsMenu: LinkItemType = { text: 'Browse All Docs', description: 'Explore our in-depth documentation, guides, and resources to bring your ideas to life.', - url: '/docs/quick-start', + url: '/docs/dapps', menu: { className: 'lg:col-start-3', }, diff --git a/components/client/AddNetworkButtonInline.tsx b/components/client/AddNetworkButtonInline.tsx new file mode 100644 index 00000000000..8a95c7f3a65 --- /dev/null +++ b/components/client/AddNetworkButtonInline.tsx @@ -0,0 +1,101 @@ +'use client'; + +import { useState } from 'react'; +import { Wallet, Check, AlertCircle } from 'lucide-react'; + +interface NetworkConfig { + chainId: string; + chainName: string; + nativeCurrency: { + name: string; + symbol: string; + decimals: number; + }; + rpcUrls: string[]; + blockExplorerUrls: string[]; +} + +const AVALANCHE_MAINNET: NetworkConfig = { + chainId: '0xA86A', + chainName: 'Avalanche C-Chain', + nativeCurrency: { + name: 'Avalanche', + symbol: 'AVAX', + decimals: 18, + }, + rpcUrls: ['https://api.avax.network/ext/bc/C/rpc'], + blockExplorerUrls: ['https://subnets.avax.network/c-chain'], +}; + +const AVALANCHE_FUJI: NetworkConfig = { + chainId: '0xA869', + chainName: 'Avalanche Fuji Testnet', + nativeCurrency: { + name: 'Avalanche', + symbol: 'AVAX', + decimals: 18, + }, + rpcUrls: ['https://api.avax-test.network/ext/bc/C/rpc'], + blockExplorerUrls: ['https://subnets-test.avax.network/c-chain'], +}; + +interface AddNetworkButtonInlineProps { + network: 'mainnet' | 'fuji'; +} + +export default function AddNetworkButtonInline({ network }: AddNetworkButtonInlineProps) { + const [status, setStatus] = useState<'idle' | 'adding' | 'success' | 'error'>('idle'); + + const addNetwork = async () => { + if (typeof window === 'undefined' || !window.ethereum) { + setStatus('error'); + setTimeout(() => setStatus('idle'), 3000); + return; + } + + setStatus('adding'); + + const config = network === 'mainnet' ? AVALANCHE_MAINNET : AVALANCHE_FUJI; + + try { + await window.ethereum.request({ + method: 'wallet_addEthereumChain', + params: [config], + }); + setStatus('success'); + setTimeout(() => setStatus('idle'), 3000); + } catch (err: any) { + setStatus('error'); + setTimeout(() => setStatus('idle'), 3000); + } + }; + + return ( + + ); +} + diff --git a/components/landing/academy-splash.tsx b/components/landing/academy-splash.tsx index bff9356fe71..73661f906c6 100644 --- a/components/landing/academy-splash.tsx +++ b/components/landing/academy-splash.tsx @@ -1,174 +1,163 @@ "use client"; import React from "react"; -import { GraduationCap, ChevronRight, Code2, Sparkles, TrendingUp, Trophy, Flame, ArrowRight, BookOpen } from "lucide-react"; +import { Trophy, ArrowRight, BookOpen, Award, Zap } from "lucide-react"; import { cn } from "@/utils/cn"; import Link from "next/link"; import Image from "next/image"; +const features = [ + { + id: 1, + title: "Interactive Courses", + description: "Hands-on blockchain courses", + icon: BookOpen, + href: "/academy" + }, + { + id: 2, + title: "Hackathons", + description: "Compete for prizes", + icon: Trophy, + href: "/hackathons" + }, + { + id: 3, + title: "Bounties", + description: "Earn by contributing", + icon: Zap, + href: "/grants" + }, + { + id: 4, + title: "Certificates", + description: "Showcase your skills", + icon: Award, + href: "/login" + } +]; + export default function AcademySplash() { return ( -
-
-
- {/* Left side - Academy Info */} -
-
-
- - - Learn & Build - -
- -

- - Avalanche - - - Academy - -

- -

- Join thousands of developers learning blockchain through hands-on courses, - hackathons, and real bounties. Track your progress and earn rewards. -

-
- -
+
+
+

+ Avalanche Academy +

+
+ +
+
+ {/* Left - Description */} +
+

+ Learn. Build. Earn. +

+

+ Join thousands of developers learning blockchain through hands-on courses, + hackathons, and real bounties. Track your progress and earn rewards. +

+
Start Learning - + - - Join Hackathons + Create Account
- - {/* Right side - Wolfie Profile Card */} -
- {/* Main Profile Card */} + + {/* Right - Stats */} +
+
+
12+
+
Courses
+
+
+
5K+
+
Students
+
- {/* Header with Wolfie */} -
-
-
- Intern Wolfie -
-
- - 42 -
+
$50K+
+
In Prizes
+
+
+
100%
+
Free
+
+
+
+ + {/* Features Grid */} +
+ {features.map((feature) => ( + +
+
+
-

- Wolfie Hacks +

+ {feature.title}

-

- Level 15 • Master Builder +

+ {feature.description}

-
- - {/* Progress */} -
-
-
- - Academy Progress - - 78% -
-
-
-
+
+
- - {/* Stats */} -
-
-
12
-
Certificates
-
-
-
7
-
Bounties
-
-
-
3
-
Hackathons
-
-
- - {/* Current Focus */} - -
-
- -
-
-

- Currently Learning -

-

- Chainlink VRF with Avalanche ICM -

-
- -
- - - {/* CTA */} - - Create Account - - -
-
+ + ))}
diff --git a/components/landing/development.tsx b/components/landing/development.tsx index 9388716073f..a12d230c0a6 100644 --- a/components/landing/development.tsx +++ b/components/landing/development.tsx @@ -13,7 +13,7 @@ const development = [ description: "Find references for all Avalanche SDKs, APIs, and tools.", icon: Book, - href: "/docs/quick-start", + href: "/docs/dapps", }, { id: 5, diff --git a/components/landing/hero.tsx b/components/landing/hero.tsx index 70a99f60cf8..2838bdc5fd6 100644 --- a/components/landing/hero.tsx +++ b/components/landing/hero.tsx @@ -232,9 +232,9 @@ export default function Hero() { -

+ {/*

Everything you need to go from idea to impact. -

+

*/}
{/* CTA Buttons */} @@ -248,7 +248,7 @@ export default function Hero() { Build diff --git a/components/landing/paths.tsx b/components/landing/paths.tsx index af368f66c3c..fce02a11a7c 100644 --- a/components/landing/paths.tsx +++ b/components/landing/paths.tsx @@ -53,49 +53,46 @@ const paths = [ export default function Paths() { return (
-
-

+
+

Choose your path

-
+
{paths.map((path, index) => ( -
+
{/* Icon */} -
-
- -
+
+
{/* Content */}
-

+

{path.title}

-

+

{path.description}

{/* Arrow */} -
- +
+
diff --git a/components/landing/quicklinks.tsx b/components/landing/quicklinks.tsx index 405f4459627..61573d8f31e 100644 --- a/components/landing/quicklinks.tsx +++ b/components/landing/quicklinks.tsx @@ -1,6 +1,5 @@ "use client"; -import React from "react"; import { Droplet, Wrench, @@ -23,21 +22,21 @@ const quickLinks = [ { id: 2, title: "Bridge", - description: "Bridge assets to and from the C-Chain", + description: "Bridge assets to and from Avalanche", icon: ArrowLeftRight, href: "https://core.app/en/bridge/" }, { id: 3, title: "Create New L1", - description: "Use our Builder Console to create a new L1", + description: "Create a blockchain with the Builder Console", icon: Wrench, href: "/console/layer-1/create" }, { id: 4, title: "Explorer", - description: "Learn from zero to hero", + description: "Explore activity on the network", icon: Search, href: "https://subnets.avax.network" }, @@ -53,49 +52,46 @@ const quickLinks = [ export default function QuickLinks() { return (
-
-

+
+

Quick Links

-
+
{quickLinks.map((link, index) => ( -
+
{/* Icon */} -
-
- -
+
+
{/* Content */}
-

+

{link.title}

-

+

{link.description}

{/* Arrow */} -
- +
+
diff --git a/components/navigation/active-nav-highlighter.tsx b/components/navigation/active-nav-highlighter.tsx index d0ad3190ee3..f12fe48b8dc 100644 --- a/components/navigation/active-nav-highlighter.tsx +++ b/components/navigation/active-nav-highlighter.tsx @@ -47,8 +47,8 @@ export function ActiveNavHighlighter() { if (href) { // Check if this link's href matches or starts with the active section if (href === activeSection || href.startsWith(activeSection + '/')) { - // Special handling for docs (which might have url '/docs/quick-start') - if (activeSection === '/docs' && (href === '/docs/quick-start' || href.startsWith('/docs/'))) { + // Special handling for docs (which might have url '/docs/dapps') + if (activeSection === '/docs' && (href === '/docs/dapps' || href.startsWith('/docs/'))) { link.setAttribute('data-active', 'true'); link.setAttribute('aria-current', 'page'); } diff --git a/components/navigation/docs-subnav.tsx b/components/navigation/docs-subnav.tsx index 931f47c8cfb..7ab06f7d5e3 100644 --- a/components/navigation/docs-subnav.tsx +++ b/components/navigation/docs-subnav.tsx @@ -7,9 +7,10 @@ import { cn } from "@/lib/cn"; const tabs = [ { label: "Overview", - href: "/docs/quick-start", + href: "/docs/dapps", pathMatch: (path: string) => - path === "/docs/quick-start" || + path === "/docs/dapps" || + path === "/docs" || (path.startsWith("/docs/") && !path.startsWith("/docs/api-reference") && !path.startsWith("/docs/rpcs") && diff --git a/components/navigation/footer.tsx b/components/navigation/footer.tsx index 0a50fe74933..5edd33262ed 100644 --- a/components/navigation/footer.tsx +++ b/components/navigation/footer.tsx @@ -44,37 +44,32 @@ export function Footer() {
+ Audits Explorer - Get Started GitHub + Network Status Whitepapers - Statistics
+ Blog + Discord Facebook Forum - Discord - Support + LinkedIn Medium - Youtube Telegram X - Blog - LinkedIn + Youtube
- Enterprise Solutions - Audits - Core Wallet Legal - Network Status - LLMs + LLMs
diff --git a/components/navigation/navbar-dropdown.tsx b/components/navigation/navbar-dropdown.tsx index 907651343b1..0d54b29dcea 100644 --- a/components/navigation/navbar-dropdown.tsx +++ b/components/navigation/navbar-dropdown.tsx @@ -48,9 +48,9 @@ export function NavbarDropdown() { }, { title: 'Documentation', - href: '/docs/quick-start', + href: '/docs/dapps', items: [ - { text: 'Avalanche Protocol', href: '/docs/quick-start' }, + { text: 'Build Apps', href: '/docs/dapps' }, { text: 'Avalanche L1s', href: '/docs/avalanche-l1s' }, { text: 'Nodes & Validators', href: '/docs/nodes' }, { text: 'Interoperability', href: '/docs/cross-chain' }, diff --git a/content/docs/virtual-machines/custom-precompiles/background-requirements.mdx b/content/docs/avalanche-l1s/custom-precompiles/background-requirements.mdx similarity index 100% rename from content/docs/virtual-machines/custom-precompiles/background-requirements.mdx rename to content/docs/avalanche-l1s/custom-precompiles/background-requirements.mdx diff --git a/content/docs/virtual-machines/custom-precompiles/create-precompile.mdx b/content/docs/avalanche-l1s/custom-precompiles/create-precompile.mdx similarity index 100% rename from content/docs/virtual-machines/custom-precompiles/create-precompile.mdx rename to content/docs/avalanche-l1s/custom-precompiles/create-precompile.mdx diff --git a/content/docs/virtual-machines/custom-precompiles/defining-precompile.mdx b/content/docs/avalanche-l1s/custom-precompiles/defining-precompile.mdx similarity index 100% rename from content/docs/virtual-machines/custom-precompiles/defining-precompile.mdx rename to content/docs/avalanche-l1s/custom-precompiles/defining-precompile.mdx diff --git a/content/docs/virtual-machines/custom-precompiles/defining-test-cases.mdx b/content/docs/avalanche-l1s/custom-precompiles/defining-test-cases.mdx similarity index 100% rename from content/docs/virtual-machines/custom-precompiles/defining-test-cases.mdx rename to content/docs/avalanche-l1s/custom-precompiles/defining-test-cases.mdx diff --git a/content/docs/virtual-machines/custom-precompiles/executing-test-cases.mdx b/content/docs/avalanche-l1s/custom-precompiles/executing-test-cases.mdx similarity index 100% rename from content/docs/virtual-machines/custom-precompiles/executing-test-cases.mdx rename to content/docs/avalanche-l1s/custom-precompiles/executing-test-cases.mdx diff --git a/content/docs/virtual-machines/custom-precompiles/index.mdx b/content/docs/avalanche-l1s/custom-precompiles/index.mdx similarity index 100% rename from content/docs/virtual-machines/custom-precompiles/index.mdx rename to content/docs/avalanche-l1s/custom-precompiles/index.mdx diff --git a/content/docs/virtual-machines/custom-precompiles/precompile-deployment.mdx b/content/docs/avalanche-l1s/custom-precompiles/precompile-deployment.mdx similarity index 100% rename from content/docs/virtual-machines/custom-precompiles/precompile-deployment.mdx rename to content/docs/avalanche-l1s/custom-precompiles/precompile-deployment.mdx diff --git a/content/docs/virtual-machines/golang-vms/complex-golang-vm.mdx b/content/docs/avalanche-l1s/golang-vms/complex-golang-vm.mdx similarity index 100% rename from content/docs/virtual-machines/golang-vms/complex-golang-vm.mdx rename to content/docs/avalanche-l1s/golang-vms/complex-golang-vm.mdx diff --git a/content/docs/virtual-machines/golang-vms/simple-golang-vm.mdx b/content/docs/avalanche-l1s/golang-vms/simple-golang-vm.mdx similarity index 100% rename from content/docs/virtual-machines/golang-vms/simple-golang-vm.mdx rename to content/docs/avalanche-l1s/golang-vms/simple-golang-vm.mdx diff --git a/content/docs/avalanche-l1s/index.mdx b/content/docs/avalanche-l1s/index.mdx index e38514ecd5f..d5d2891056a 100644 --- a/content/docs/avalanche-l1s/index.mdx +++ b/content/docs/avalanche-l1s/index.mdx @@ -1,42 +1,69 @@ --- -title: Getting Started -description: As you begin your Avalanche L1 journey, it's useful to look at the lifecycle of taking an Avalanche L1 from idea to production. +title: Avalanche L1s +description: Explore the multi-chain architecture of Avalanche ecosystem. --- -## Figure Out Your Needs +An Avalanche L1 is a sovereign network which defines its own rules regarding its membership and token economics. It is composed of a dynamic subset of Avalanche validators working together to achieve consensus on the state of one or more blockchains. Each blockchain is validated by exactly one Avalanche L1, while an Avalanche L1 can validate many blockchains. -The first step of planning your Avalanche L1 is determining your application's needs. What features do you need that the Avalanche C-Chain doesn't provide? +Avalanche's [Primary Network](/docs/quick-start/primary-network) is a special Avalanche L1 running three blockchains: -### When to Choose an Avalanche L1 +- The Platform Chain [(P-Chain)](/docs/quick-start/primary-network#p-chain) +- The Contract Chain [(C-Chain)](/docs/quick-start/primary-network#c-chain) +- The Exchange Chain [(X-Chain)](/docs/quick-start/primary-network#x-chain) -Building your own Avalanche L1 is a great choice when your project demands capabilities beyond those offered by the C-Chain. For instance, if you need the flexibility to use a custom gas token, require strict access control (for example, by only permitting users who are KYC-verified), or wish to implement a unique transaction fee model, then an Avalanche L1 can provide the necessary options. In addition, if having a completely sovereign network with its own governance and consensus mechanisms is central to your vision, an Avalanche L1 is likely the best path forward. +![image](/images/subnet1.png) -### Decide What Type of Avalanche L1 You Want + +Every validator of an Avalanche L1 **must** sync the P-Chain of the Primary Network for interoperability. + -After confirming that an Avalanche L1 suits your project's requirements, the next step is to select the type of virtual machine (VM) that will power your blockchain. Broadly, you can choose among three options. +Node operators that validate an Avalanche L1 with multiple chains do not need to run multiple machines for validation. For example, the Primary Network is an Avalanche L1 with three coexisting chains, all of which can be validated by a single node, or a single machine. -#### EVM-Based Avalanche L1s +## Advantages -The majority of Avalanche L1s are utilizing the Ethereum Virtual Machine. They support Solidity smart contracts and standard [Ethereum APIs](/docs/api-reference/c-chain/api#ethereum-apis). Ava Labs' implementation, [Subnet-EVM](https://github.com/ava-labs/subnet-evm), is the most mature option available. It is recognized for its robust developer tooling and regular updates, making it the safest and most popular choice for building your blockchain. +### Independent Networks -#### Custom Avalanche L1s +- Avalanche L1s use virtual machines to specify their own execution logic, determine their own fee regime, maintain their own state, facilitate their own networking, and provide their own security. +- Each Avalanche L1's performance is isolated from other Avalanche L1s in the ecosystem, so increased usage on one Avalanche L1 won't affect another. +- Avalanche L1s can have their own token economics with their own native tokens, fee markets, and incentives determined by the Avalanche L1 deployer. +- One Avalanche L1 can host multiple blockchains with customized [virtual machines](/docs/quick-start/virtual-machines). -Custom Avalanche L1s offer an open-ended interface that enables you to build any virtual machine you envision. Whether you fork an existing VM such as Subnet-EVM, integrate a non-Avalanche-native VM like Solana's, or build a completely new VM using any programming language you prefer, the choice is yours. For guidance on how to get started with VM development, see [Introduction to VMs](/docs/virtual-machines). +### Native Interoperability -### Determine Tokenomics +Avalanche Warp Messaging enables native cross-Avalanche L1 communication and allows Virtual Machine (VM) developers to implement arbitrary communication protocols between any two Avalanche L1s. -Avalanche L1s are powered by gas tokens, and building your own blockchain gives you the flexibility to determine which token to use and how to distribute it. Whether you decide to leverage AVAX, adapt an existing C-Chain token, or launch a new token entirely, you'll need to plan the allocation of tokens for validator rewards, establish an emission schedule, and decide whether transaction fees should be burned or redistributed as block rewards. +### Accommodate App-Specific Requirements -### Decide how to Customize Your Avalanche L1 +Different blockchain-based applications may require validators to have certain properties such as large amounts of RAM or CPU power. -Once you have selected your virtual machine, further customization may be necessary to align the blockchain with your specific needs. This might involve configuring the token allocation in the genesis block, setting gas fee rates, or making changes to the VM's behavior through precompiles. Such customizations often require careful iterative testing to perfect. For detailed instructions, refer to [Customize Your EVM-Powered Avalanche L1](/docs/avalanche-l1s/upgrade/customize-avalanche-l1). +an Avalanche L1 could require that validators meet certain [hardware requirements](/docs/nodes/system-requirements#hardware-and-operating-systems) so that the application doesn't suffer from low performance due to slow validators. -### Available Subnet-EVM Precompiles +### Launch Networks Designed With Compliance -The Subnet-EVM provides several precompiled contracts that you can use in your Avalanche L1 blockchain: +Avalanche's L1 architecture makes regulatory compliance manageable. As mentioned above, an Avalanche L1 may require validators to meet a set of requirements. -- [AllowList Interface](/docs/avalanche-l1s/evm-configuration/allowlist) - A reusable interface for permission management -- [Permissions](/docs/avalanche-l1s/evm-configuration/permissions) - Control contract deployment and transaction submission -- [Tokenomics](/docs/avalanche-l1s/evm-configuration/tokenomics) - Manage native token supply and minting -- [Transaction Fees & Validator Rewards](/docs/avalanche-l1s/evm-configuration/transaction-fees) - Configure fee parameters and reward mechanisms -- [Warp Messenger](/docs/avalanche-l1s/evm-configuration/warpmessenger) - Perform cross-chain operations \ No newline at end of file +Some examples of requirements the creators of an Avalanche L1 may choose include: + +- Validators must be located in a given country. +- Validators must pass KYC/AML checks. +- Validators must hold a certain license. + +### Control Privacy of On-Chain Data + +Avalanche L1s are ideal for organizations interested in keeping their information private. + +Institutions conscious of their stakeholders' privacy can create a private Avalanche L1 where the contents of the blockchains would be visible only to a set of pre-approved validators. + +Define this at creation with a [single parameter](/docs/nodes/configure/avalanche-l1-configs#private-avalanche-l1). + +### Validator Sovereignty + +In a heterogeneous network of blockchains, some validators will not want to validate certain blockchains because they simply have no interest in those blockchains. + +The Avalanche L1 model enables validators to concern themselves only with blockchain networks they choose to participate in. This greatly reduces the computational burden on validators. + +## Develop Your Own Avalanche L1 + +Avalanche L1s on Avalanche are deployed by default with [Subnet-EVM](https://github.com/ava-labs/subnet-evm#subnet-evm), a fork of go-ethereum. It implements the Ethereum Virtual Machine and supports Solidity smart contracts as well as most other Ethereum client functionality. + +To get started, check out our [L1 Toolbox](/tools/l1-toolbox) or the tutorials in the [Avalanche CLI](/docs/tooling/create-avalanche-l1) section. diff --git a/content/docs/virtual-machines/manage-vm-binaries.mdx b/content/docs/avalanche-l1s/manage-vm-binaries.mdx similarity index 100% rename from content/docs/virtual-machines/manage-vm-binaries.mdx rename to content/docs/avalanche-l1s/manage-vm-binaries.mdx diff --git a/content/docs/avalanche-l1s/meta.json b/content/docs/avalanche-l1s/meta.json index 7c50ba16ad8..ea18798e380 100644 --- a/content/docs/avalanche-l1s/meta.json +++ b/content/docs/avalanche-l1s/meta.json @@ -26,6 +26,20 @@ "evm-configuration/transaction-fees", "evm-configuration/warpmessenger", "evm-configuration/precompile-upgrades", + "---Custom Virtual Machines---", + "virtual-machines-index", + "simple-vm-any-language", + "manage-vm-binaries", + "---Custom Precompiles---", + "custom-precompiles", + "---Golang VMs---", + "golang-vms/simple-golang-vm", + "golang-vms/complex-golang-vm", + "---Rust VMs---", + "rust-vms/intro-avalanche-rs", + "rust-vms/setting-up-environment", + "rust-vms/installing-vm", + "timestamp-vm", "---Upgrade an Avalanche L1---", "...upgrade" ] diff --git a/content/docs/virtual-machines/rust-vms/installing-vm.mdx b/content/docs/avalanche-l1s/rust-vms/installing-vm.mdx similarity index 100% rename from content/docs/virtual-machines/rust-vms/installing-vm.mdx rename to content/docs/avalanche-l1s/rust-vms/installing-vm.mdx diff --git a/content/docs/virtual-machines/rust-vms/intro-avalanche-rs.mdx b/content/docs/avalanche-l1s/rust-vms/intro-avalanche-rs.mdx similarity index 100% rename from content/docs/virtual-machines/rust-vms/intro-avalanche-rs.mdx rename to content/docs/avalanche-l1s/rust-vms/intro-avalanche-rs.mdx diff --git a/content/docs/virtual-machines/rust-vms/setting-up-environment.mdx b/content/docs/avalanche-l1s/rust-vms/setting-up-environment.mdx similarity index 100% rename from content/docs/virtual-machines/rust-vms/setting-up-environment.mdx rename to content/docs/avalanche-l1s/rust-vms/setting-up-environment.mdx diff --git a/content/docs/virtual-machines/simple-vm-any-language.mdx b/content/docs/avalanche-l1s/simple-vm-any-language.mdx similarity index 100% rename from content/docs/virtual-machines/simple-vm-any-language.mdx rename to content/docs/avalanche-l1s/simple-vm-any-language.mdx diff --git a/content/docs/virtual-machines/timestamp-vm/apis.mdx b/content/docs/avalanche-l1s/timestamp-vm/apis.mdx similarity index 100% rename from content/docs/virtual-machines/timestamp-vm/apis.mdx rename to content/docs/avalanche-l1s/timestamp-vm/apis.mdx diff --git a/content/docs/virtual-machines/timestamp-vm/blocks.mdx b/content/docs/avalanche-l1s/timestamp-vm/blocks.mdx similarity index 100% rename from content/docs/virtual-machines/timestamp-vm/blocks.mdx rename to content/docs/avalanche-l1s/timestamp-vm/blocks.mdx diff --git a/content/docs/virtual-machines/timestamp-vm/defining-vm-itself.mdx b/content/docs/avalanche-l1s/timestamp-vm/defining-vm-itself.mdx similarity index 100% rename from content/docs/virtual-machines/timestamp-vm/defining-vm-itself.mdx rename to content/docs/avalanche-l1s/timestamp-vm/defining-vm-itself.mdx diff --git a/content/docs/virtual-machines/timestamp-vm/introduction.mdx b/content/docs/avalanche-l1s/timestamp-vm/introduction.mdx similarity index 100% rename from content/docs/virtual-machines/timestamp-vm/introduction.mdx rename to content/docs/avalanche-l1s/timestamp-vm/introduction.mdx diff --git a/content/docs/virtual-machines/timestamp-vm/meta.json b/content/docs/avalanche-l1s/timestamp-vm/meta.json similarity index 100% rename from content/docs/virtual-machines/timestamp-vm/meta.json rename to content/docs/avalanche-l1s/timestamp-vm/meta.json diff --git a/content/docs/virtual-machines/timestamp-vm/state.mdx b/content/docs/avalanche-l1s/timestamp-vm/state.mdx similarity index 100% rename from content/docs/virtual-machines/timestamp-vm/state.mdx rename to content/docs/avalanche-l1s/timestamp-vm/state.mdx diff --git a/content/docs/quick-start/validator-manager.mdx b/content/docs/avalanche-l1s/validator-manager.mdx similarity index 100% rename from content/docs/quick-start/validator-manager.mdx rename to content/docs/avalanche-l1s/validator-manager.mdx diff --git a/content/docs/virtual-machines/index.mdx b/content/docs/avalanche-l1s/virtual-machines-index.mdx similarity index 100% rename from content/docs/virtual-machines/index.mdx rename to content/docs/avalanche-l1s/virtual-machines-index.mdx diff --git a/content/docs/dapps/advanced-tutorials/add-network-programmatically.mdx b/content/docs/dapps/advanced-tutorials/add-network-programmatically.mdx deleted file mode 100644 index 913700c0605..00000000000 --- a/content/docs/dapps/advanced-tutorials/add-network-programmatically.mdx +++ /dev/null @@ -1,134 +0,0 @@ ---- -title: Add Network Programmatically -description: This document shows how to integrate Avalanche Network with your dApp, either using Core or MetaMask. ---- - -## Core - -Powered by Avalanche, [Core](https://core.app/en/) is an all-in-one operating system bringing together Avalanche apps, Avalanche L1s, bridges, and NFTs in one seamless, high-performance browser experience. Putting in another way, Core is more than a wallet. It is a curated web3 operating system combining Wallet, Explorer, Bridge, Avalanche L1s, dApps, and more. - -Getting a Dapp ready to connect to Core is made simple with pre-built tools from the Core Team. - -First download and install the Core browser extension from [here](https://chrome.google.com/webstore/detail/core/agoakfejjabomempkjlepdflaleeobhb). - -[avalanche-dapp-sdks](https://github.com/ava-labs/avalanche-dapp-sdks) contains an example of how to connect via @web3-react/core to the Core extension specifically. - -```rust -git clone https://github.com/ava-labs/avalanche-dapp-sdks.git -cd avalanche-dapp-sdks -yarn bootstrap -``` - - -The repository cloning method used is HTTPS, but SSH can be used too: - -`git clone git@github.com:ava-labs/avalanche-dapp-sdks.git` - -You can find more about SSH and how to use it [here](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/about-ssh). - - -Then check out [this sample project under `packages/avalanche-connector-example`](https://github.com/ava-labs/avalanche-dapp-sdks/tree/alpha-release/packages/web3-react-core-connector) - -```rust -cd packages/avalanche-connector-example -npm start -``` - -If everything works as expected, you should be able to load \[http://localhost:3000/\] on your browser, click on the "Connect Avalanche" button on the page as below: - -![connect core](/images/add-network1.jpeg) - -Check out the [README](https://github.com/ava-labs/avalanche-dapp-sdks/tree/alpha-release/packages/web3-react-core-connector) to see details how this works and use it to fit your needs. - -This [Google Drive](https://drive.google.com/drive/folders/1pQ98mIs65ET9JBGThzAAlGKv85BuQCAu?usp=sharing) has the assets needed to create a **Connect with Core** button. - -## MetaMask - -Adding new networks to MetaMask is not a trivial task for people that are not technically savvy, and it can be error prone. To help easier onboarding of users to your application it is useful to simplify that process as much as possible. - -This tutorial will show how to build a simple button in your front-end application that will automate the process of adding the Avalanche network to MetaMask. - -### EIP-3035 - -[EIP-3035](https://eips.ethereum.org/EIPS/eip-3085) is an [Ethereum Improvement Proposal](https://eips.ethereum.org/) that defines an RPC method for adding Ethereum-compatible chains to wallet applications. - -Since March 2021 MetaMask has implemented that EIP as part of their MetaMask [Custom Networks API](https://consensys.net/blog/metamask/connect-users-to-layer-2-networks-with-the-metamask-custom-networks-api/). - -Let's see how it works. - -#### Data Structures - -To add the Avalanche network to MetaMask, we need to prepare the data structures that will be contain all the necessary data. - -Main network data: - -```rust -export const AVALANCHE_MAINNET_PARAMS = { - chainId: "0xA86A", - chainName: "Avalanche Mainnet C-Chain", - nativeCurrency: { - name: "Avalanche", - symbol: "AVAX", - decimals: 18, - }, - rpcUrls: ["https://api.avax.network/ext/bc/C/rpc"], - blockExplorerUrls: ["https://snowtrace.io/"], -}; -``` - -Test network data: - -```rust -export const AVALANCHE_TESTNET_PARAMS = { - chainId: "0xA869", - chainName: "Avalanche Testnet C-Chain", - nativeCurrency: { - name: "Avalanche", - symbol: "AVAX", - decimals: 18, - }, - rpcUrls: ["https://api.avax-test.network/ext/bc/C/rpc"], - blockExplorerUrls: ["https://testnet.snowtrace.io/"], -}; -``` - -### Adding the Network - -To add the network to MetaMask, we need to call the `wallet_addEthereumChain` method, exposed by the web3 provider. - -```rust -function addAvalancheNetwork() { - injected.getProvider().then((provider) => { - provider - .request({ - method: "wallet_addEthereumChain", - params: [AVALANCHE_MAINNET_PARAMS], - }) - .catch((error: any) => { - console.log(error); - }); - }); -} -``` - -Where `injected` is initialized as a `web3-react/injected-connector` used to interface with MetaMask APIs. Usage for other popular web frameworks is similar. Replace `AVALANCHE_MAINNET_PARAMS` with `AVALANCHE_TESTNET_PARAMS` if you want to add the test network. - -Typical usage pattern would be to expose a button calling that method if you get `Wrong Network` or `Error connecting` errors when attempting to establish a connection to MetaMask. - -### User Experience - -When users first come to your dapp's website they need to approve connection to MetaMask. After they do that, if you don't detect successful web3 network connection, you can present them with a dialog asking them to confirm switch to a new network: - -![wrong network](/images/add-network2.png) - -If they press the button, they are shown a dialog from MetaMask asking for approval to add the new network: - -![add a network](/images/add-network3.png) - -If they approve, your app will be connected to the Avalanche network. Very easy, no need for any data entry, no chance of wrong data entry. And that's it, users are ready to interact with your dapp! - -## Conclusion - -Dapp users are often not very technically sophisticated and onboarding them needs to be as seamless and easy as possible. Manually adding a new network is a hurdle than a certain percentage of your potential users will not be able to clear. Removing that requirement is a simple step that will enhance their experience and enable more users to get to actually use your dapp. - -If you have any questions, problems, or ideas on how to improve, or simply want to join our developer community, you can contact us on our [Discord](https://chat.avalabs.org/) server. diff --git a/content/docs/dapps/advanced-tutorials/dynamic-gas-fees.mdx b/content/docs/dapps/advanced-tutorials/dynamic-gas-fees.mdx deleted file mode 100644 index 32096715e11..00000000000 --- a/content/docs/dapps/advanced-tutorials/dynamic-gas-fees.mdx +++ /dev/null @@ -1,216 +0,0 @@ ---- -title: Dynamic Gas Fees -description: Learn how to send transactions with dynamic fees using JavaScript. ---- - -The objective of this document is to provide and explain sending transactions with dynamic fees using JavaScript. Make sure you have followed [the tutorial on adjusting the dynamic fees using MetaMask](/docs/dapps/advanced-tutorials/manually-adjust-gas-price). There, we have explained the key concepts related to dynamic fees and EIP1559 type of transactions. - -## Prerequisites - -- Basic familiarity with [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript). -- Basic familiarity with [Node.js](https://nodejs.org/en) and [npm](https://www.npmjs.com/). -- Basic familiarity with [the Avalanche C-Chain](/docs/api-reference/c-chain/api) network and [EVM compatibility](https://ethereum.org/en/developers/docs/evm/) -- Basic understanding of [dynamic fee transactions](/docs/dapps/advanced-tutorials/manually-adjust-gas-price#good-to-know-keywords-and-concepts) - -## Installing Dependencies - -Open the terminal and install the following dependencies in a new folder. - -- Ethers -- avalanche -- dotenv - -```bash -npm install ethers avalanche dotenv -``` - -## Setting up Environment and Project - -To send a transaction we need to sign it using our private key. But private key should not be hard coded in the code, rather must be fetched through some environment variables. Make a `.env` file in the root folder with the following content. - -```bash -PRIVATEKEY= -``` - -Now make a new file `app.js` in the root folder, which will be our main and only file with the `sendAvax()` function. Follow the rest of the tutorial by understanding and pasting the provided snippets sequentially in the `app.js` file. - -## Importing Dependencies and Private Key - -```rust -const ethers = require("ethers"); -const Avalanche = require("avalanche").Avalanche; -require("dotenv").config(); - -const privateKey = process.env.PRIVATEKEY; -``` - -## Setting up HTTP Provider - -Using the HTTP provider, we will connect to one of the nodes on the Fuji network. Using this provider we will send the signed transaction to the network. You can also connect to Mainnet using the URL - `https://api.avax.network/ext/bc/C/rpc` - -```rust -// For sending a signed transaction to the network -const nodeURL = "https://api.avax-test.network/ext/bc/C/rpc"; -const HTTPSProvider = new ethers.providers.JsonRpcProvider(nodeURL); -``` - -## Setup C-Chain APIs to Estimate Fees - -To estimate the max fee and max priority fee on the network, we will be using C-Chain APIs. We can use the C-Chain through an AvalancheJS instance connected to the network as shown below. - -```rust -// For estimating max fee and priority fee using CChain APIs -const chainId = 43113; -const avalanche = new Avalanche( - "api.avax-test.network", - undefined, - "https", - chainId -); -const cchain = avalanche.CChain(); -``` - -### Function for Estimating Max Fee and Max Priority Fee - -The function `calcFeeData()` estimates the max fee and max priority fee per gas according to network activity using the C-Chain APIs. This function returns max fee and max priority fee per gas in units of `nAVAX` or `gwei` (1 AVAX = 10^9 gwei). - -```rust -// Function to estimate max fee and max priority fee -const calcFeeData = async ( - maxFeePerGas = undefined, - maxPriorityFeePerGas = undefined -) => { - const baseFee = parseInt(await cchain.getBaseFee(), 16) / 1e9; - maxPriorityFeePerGas = - maxPriorityFeePerGas == undefined - ? parseInt(await cchain.getMaxPriorityFeePerGas(), 16) / 1e9 - : maxPriorityFeePerGas; - maxFeePerGas = - maxFeePerGas == undefined ? baseFee + maxPriorityFeePerGas : maxFeePerGas; - - if (maxFeePerGas < maxPriorityFeePerGas) { - throw "Error: Max fee per gas cannot be less than max priority fee per gas"; - } - - return { - maxFeePerGas: maxFeePerGas.toString(), - maxPriorityFeePerGas: maxPriorityFeePerGas.toString(), - }; -}; -``` - -Actual API returns base fee and priority fee in units of `wei` which is one-billionth of a billionth of `AVAX` (1 AVAX = 10^18 wei). - -## Setting up Wallet - -A wallet is required for signing transactions with your private key and thus making it valid. - -```javascript -// For signing an unsigned transaction -const wallet = new ethers.Wallet(privateKey); -const address = wallet.address; -``` - -## Function to Create, Sign and Send Transaction - -The function `sendAvax()` takes 4 arguments - - -- `amount` - Amount of AVAX to send in the transaction -- `address` - Destination address to which we want to send AVAX -- `maxFeePerGas` - Desired maximum fee per gas you want to pay in nAVAX -- `maxPriorityFeePerGas` - Desired maximum priority fee per gas you want to pay in nAVAX -- `nonce` - Used as a differentiator for more than 1 transaction with same signer - -The last 3 arguments are optional, and if `undefined` is passed, then it will use the `calcFeeData()` function to estimate them. Each transaction with the same data and parameters is differentiated by a nonce value. If there are more than 1 transactions with the same nonce signed by the same address, then only 1 of them with the highest effective priority fee will be accepted. `nonce` parameter should only be used when you are either re-issuing or cancelling a stuck transaction. - -```rust -// Function to send AVAX -const sendAvax = async ( - amount, - to, - maxFeePerGas = undefined, - maxPriorityFeePerGas = undefined, - nonce = undefined -) => { - if (nonce == undefined) { - nonce = await HTTPSProvider.getTransactionCount(address); - } - - // If the max fee or max priority fee is not provided, then it will automatically calculate using CChain APIs - ({ maxFeePerGas, maxPriorityFeePerGas } = await calcFeeData( - maxFeePerGas, - maxPriorityFeePerGas - )); - - maxFeePerGas = ethers.utils.parseUnits(maxFeePerGas, "gwei"); - maxPriorityFeePerGas = ethers.utils.parseUnits(maxPriorityFeePerGas, "gwei"); - - // Type 2 transaction is for EIP1559 - const tx = { - type: 2, - nonce, - to, - maxPriorityFeePerGas, - maxFeePerGas, - value: ethers.utils.parseEther(amount), - chainId, - }; - - tx.gasLimit = await HTTPSProvider.estimateGas(tx); - - const signedTx = await wallet.signTransaction(tx); - const txHash = ethers.utils.keccak256(signedTx); - - console.log("Sending signed transaction"); - - // Sending a signed transaction and waiting for its inclusion - await (await HTTPSProvider.sendTransaction(signedTx)).wait(); - - console.log( - `View transaction with nonce ${nonce}: https://testnet.snowtrace.io/tx/${txHash}` - ); -}; -``` - -This function calculates transaction hash from the signed transaction and logs on the console, the URL for transaction status on the Snowtrace explorer. - -## Calling the `sendAVAX()` Function - -There are various ways to call this function. We may or may not pass the optional arguments like max fee and max priority fee. It is recommended to set the max fee as the maximum price per gas that you are willing to pay for a transaction, no matter how high or low the base fee will be, as at max you will only be charged the provided max fee, along with a small priority fee above the base fee. - -If you do not pass these arguments, then it will automatically estimate the max fee and priority fee from the network. For example, let's say, I want to pay 100 nAVAX per gas for a transaction and a small tip of 2 nAVAX, then we will call the following function. - -```rust -// setting max fee as 100 and priority fee as 2 -sendAvax("0.01", "0x856EA4B78947c3A5CD2256F85B2B147fEBDb7124", 100, 2); -``` - -This function should not be used without a max fee per gas. As you will have to pay the estimated price, even if it is higher than your budget. There could be the following cases: - -| Max Fee | Max Priority Fee | Comment | -|:-------------:|:----------------:|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:| -| **undefined** | 2 | It will calculate the max fee by adding the provided priority fee with the estimated base fee. Take extra precaution here as the max fee will now be capped by `baseFee + priorityFee`, which can consume all the provided priority fees. | -| 100 | **undefined*- | It will estimate the priority fee and use the provided max fee. If the estimated priority fee is more than the provided max fee, then it throws an error. | -| **undefined** | **undefined*- | It will estimate the base fee and priority fee from the network, and will add both the values to calculate the max fee per gas. Again, you have to pay whatever will be estimated. | - -You will get the following output on the successful submission of the signed transactions. Using this URL you can view the status of your transaction on Snowtrace. - -``` -View transaction with nonce 25: https://testnet.snowtrace.io/tx/0xd5b92b85beaf283fbaeeefb95c9a17a6b346a05b6f9687f2d6e421aa79243b35 -``` - -## Reissuance of Stuck Transaction - -Sometimes during high network activity, all transactions couldn't make it to the latest blocks for a long time, due to relatively lower effective tip than the other transactions in the pool. We can either re-issue the same transaction with a higher priority fee or cancel the transaction. To re-issue the stuck transaction, you can send a new one with same amount and data but higher priority fee and same nonce value as the stuck transaction. The transaction with lower effective tip will automatically be rejected (due to same nonce), and you do not need to worry about it. You can also cancel the stuck transaction, by keeping the amount to 0, with a higher priority fee and same nonce. Let's say, the above transaction with a nonce value of 25 has stuck. You can then re-issue a new transaction with same nonce, but higher priority fee this time. - -```rust -// reissuing transaction with nonce 25 -sendAvax("0.01", "0x856EA4B78947c3A5CD2256F85B2B147fEBDb7124", 100, 10, 25); - -// cancelling transaction with nonce 25 -sendAvax("0", "0x856EA4B78947c3A5CD2256F85B2B147fEBDb7124", 100, 10, 25); -``` - -## Conclusion - -You have learned about creating, signing, and sending transactions with dynamic fee parameters to the C-Chain of Avalanche network using JavaScript. It also explained, how to re-issue or cancel a stuck transaction, by sending a transaction with the same nonce. This tutorial points out the recommended way for choosing max fee cap and max priority fee cap for transactions and can also work as a general guide for all the EVM-based chains. diff --git a/content/docs/dapps/advanced-tutorials/manually-adjust-gas-price.mdx b/content/docs/dapps/advanced-tutorials/manually-adjust-gas-price.mdx deleted file mode 100644 index 91da1137057..00000000000 --- a/content/docs/dapps/advanced-tutorials/manually-adjust-gas-price.mdx +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: Manually Adjust Gas Price -description: Learn how to manually adjust gas price using MetaMask. ---- - -Sometimes during periods of high network activity, transactions either remain pending for a very long duration or instantly get a failed transaction notification. This may confuse and frustrate users, especially if they don't understand why their transactions are not getting accepted. - -## Probable Reasons You Are Here - -- Your transaction has stalled, and you don't know what to do -- Your transaction has failed, with an error - `transaction underpriced` -- It's your first transaction, and you want to be sure about any potential issues -- Just for general knowledge on adjusting dynamic fee settings - -If these are your reasons for being here, then you can either go through this entire section, for a better understanding of the scenario or directly skip to the [solution](#adjusting-gas-fees-before-submitting-the-transaction). - -## Good to Know Keywords and Concepts - -The amount of computation used by a transaction is measured in units of `gas`. Each unit of gas is paid for in AVAX at the `gas price` for the transaction. The `gas price` of the transaction is determined by the parameters of the transaction and the `base fee` of the block that it is included in. - -To avoid draining the user's wallet due to non-terminating execution through the EVM, transactions are submitted with a `gas limit`, which denotes the maximum units of gas that a particular transaction is allowed to consume. - -If a transaction attempts to use more than this limit, then the transaction will revert and still consume and pay for the full `gas limit`. Total fees paid by the user can be calculated as `(gas consumed) * (gas price)`, and is known as `gas fees`. Similarly, maximum gas fees can be calculated as `(gas limit) * (gas price)`. - -Originally, transactions could only set a single parameter to define how much they were willing to pay for gas: `gas price`. When dynamic fees were introduced, EIP-1559 style transactions were introduced as well which contain two parameters `maxFeeCap` and `maxPriorityFee` to determine the price a transaction is willing to pay. - -With the introduction of dynamic fees, legacy style transactions that only have a single `gas price` parameter can lead to both delayed transactions and overpaying for transactions. Dynamic fee transactions are the solution! For more info, read [this](/docs/api-reference/standards/guides/txn-fees#dynamic-fee-transactions). - -For the dynamic fee algorithm, when a block is produced or verified, we look over the past 10s to see how much gas has been consumed within that window (with an added charge for each block produced in that window) to determine the current network utilization. This window has a target utilization, which is currently set to `15M` gas units. - -Lastly, there is an added charge if a block is produced faster than the target rate of block production. Currently, the target rate of block production is one block every two seconds, so if a new block is produced one second after its parent, then there is an additional surcharge added into the base fee calculation. - -Base price could increase, decrease, or remain the same depending upon the amount of activity on the network in the most recent window. If the total gas in the last few blocks of the window is more, less or the same than the target gas, then the base price will increase, decrease, or remain the same, respectively. - -When estimating the base fee for users, we simply look at the currently preferred block and calculate what the base fee would be for a block built on top of that block immediately. - -Along with a gas limit, users can now pass 2 values in dynamic fee transactions: `gas fee cap` and `gas tip cap`. - -The maximum price per unit of gas, that the user is willing to pay for their transaction is called `gas fee cap`. If the base price for a block is more than the gas fee cap, then the transaction will remain in the transaction pool until the base fee has been changed to be less than or equal to the provided gas fee cap. - - -The transaction pool limits the number of pending transactions, so if the number of pending transactions exceeds the configured cap then the transactions with the lowest fees may be evicted from the transaction pool and need to be re-issued. - - -`Gas tip cap` is the maximum price per unit of gas, that the user is willing to pay above the base price to prioritize their transaction. But the tip is capped by both the gas tip cap as well as the gas fee cap. The actual tip paid above the `base fee` of the block is known as the `effective gas tip`. - -``` -EffectiveTip = min(MaxFeeCap - BaseFee, GasTipCap) -``` - -Consider the following examples (here Gwei or nAVAX is one-billionth of AVAX) - - -|Transaction|Max Fee Cap|Gas tip cap|Base price|Effective tip|Total price| -|-----------|-----------|-----------|----------|-------------|-----------| -|1 |50 Gwei |0 Gwei |25 Gwei |0 Gwei |25 Gwei | -|2 |50 Gwei |0 Gwei |50 Gwei |0 Gwei |50 Gwei | -|3 |50 Gwei |0 Gwei |60 Gwei |0 Gwei |PENDING | -|A |50 Gwei |10 Gwei |40 Gwei |10 Gwei |50 Gwei | -|B |40 Gwei |40 Gwei |40 Gwei |0 Gwei |40 Gwei | - -Look at transactions **A** and **B** (the bottom two transactions). In these scenarios, it looks like transaction B is paying a higher tip, however, this depends on the base fee of the block where the transactions are included. - -The effective tip of A is more than that of B. So, if both of these transaction competes for being included in the next block, then the validators would prioritize transaction A since it pays a higher effective tip. - -## Why My Transaction is on Hold or Failing? - -If your transaction is failing and giving an error - `transaction underpriced`, then the max fee cap of your transaction must be less than the minimum base price that the network supports (as of now, it's 25 nAVAX or Gwei). Although the base fee is automatically estimated in wallets like Core or MetaMask, you can try increasing the max fee cap in the wallet. - -During a period of heavy congestion on the network, all submitted transactions can't be included in the same block, due to the block's gas limit. So, validators choose transactions giving higher priority to transactions with the highest effective tips. - -Another reason your transaction may get stuck in pending, is that the max fee cap may be below the current base fee that the network is charging. In this case, you need to increase the max fee cap of your transaction above the current base fee for it to be included in the block. - -These fee adjustments can be made through wallets like Core or MetaMask. - -## Adjusting Gas Fees Before Submitting the Transaction - -You may not need to edit the gas fees on normal days. This is only required if there is heavy congestion on the network, and the base fees are frequently fluctuating. - -1. Let's create a sample transaction on Avalanche Mainnet, in which we will be sending 0.1 AVAX to a receiver using Core. Four predefined gas settings can be seen, which are Core's inbuilt gas estimation. To set a custom fee select “Custom” and enter the gas amount to use. By clicking on the **Settings** icon, we can review gas fees and the amount which we want to send. - - ![dynamic fees adjustment 1](/images/gas1.png) - -2. On this page, you can edit the priority fee (Max Priority Fee) and base fee (Max base fee). You can estimate the max fee as shown on [Snowtrace](https://snowtrace.io/gastracker), which represents the average max fee over the last 3 seconds. For more detailed statistics, you can have a look [here](https://stats.avax.network/dashboard/c-chain-activity/). - - ![dynamic fees adjustment 2](/images/gas2.png) - -3. If the network activity is high, you have to edit the priority and max fees accordingly, as given on Snowtrace. Consider the example below, where the average max fee is 26 Gwei (nAVAX). - - ![dynamic fees adjustment 3](/images/gas3.png) - -4. It is recommended to set the max fee cap as the maximum price that you are willing to pay for a transaction, no matter how high or low the base fee will be, as you will only be charged the minimum of base fee and the max fee cap, along with a small priority fee above the base fee. Now let's edit the max fee to 35 Gwei. This would ensure that our transaction would not fail until the base fee would exceed this amount. We can set a priority fee to anything between 0 and 35 Gwei. The higher the priority fee, the faster the transaction will be. For this example, let's set this to 2 Gwei. Now, save and send the transaction. - - ![dynamic fees adjustment 4](/images/gas4.png) - -5. After submitting the transaction, even if the base fee has decreased, you will only pay 2 Gwei above that fee as a priority fee. If this fee is one of the highest among the pending transactions, then it will be confirmed rapidly. We can see the confirmation of the transaction below. - - ![dynamic fees adjustment 5](/images/gas5.png) - - ![dynamic fees adjustment 6](/images/gas6.png) diff --git a/content/docs/dapps/c-chain-or-avalanche-l1.mdx b/content/docs/dapps/c-chain-or-avalanche-l1.mdx deleted file mode 100644 index 68b02ceaf29..00000000000 --- a/content/docs/dapps/c-chain-or-avalanche-l1.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: When to Build on C-Chain -description: Learn key concepts to decide when to build on the Avalanche C-Chain. ---- - -Here are some advantages of the Avalanche C-Chain that you should take into account. - -## High Composability with C-Chain Assets[​](#we-want-high-composability-with-c-chain-assets "Direct link to heading") - -C-Chain is a better option for seamless integration with existing C-Chain assets and contracts. It is easier to build a DeFi application on C-Chain, as it provides larger liquidity pools and thus allows for efficient exchange between popular assets. - -## Low Initial Cost[​](#we-want-low-initial-cost "Direct link to heading") - -C-Chain has economic advantages of low-cost deployment and cheap transactions. The recent Etna upgrade trim down the base fee of Avalanche C-Chain by 25x, which results in much lower transaction costs. - -## Low Operational Costs[​](#we-want-low-operational-costs "Direct link to heading") - -C-Chain is run and operated by thousands of nodes, it is highly decentralized and reliable, and all the infrastructure (explorers, indexers, exchanges, bridges) has already been built out by dedicated teams that maintain them for you at no extra charge. Project deployed on the C-Chain can leverage all of that basically for free. - -## High Security[​](#we-want-high-security "Direct link to heading") - -The security of Avalanche Primary Network is a function of the security of the underlying validators and stake delegators. You can choose C-Chain in order to achieve maximum security by utilizing thousands of Avalanche Primary Network validators. - -## Conclusion - -If an application has relatively low transaction rate and no special circumstances that would make the C-Chain a non-starter, you can begin with C-Chain deployment to leverage existing technical infrastructure, and later expand to an Avalanche L1. That way you can focus on working on the core of your project and once you have a solid product/market fit and have gained enough traction that the C-Chain is constricting you, plan a move to your own Avalanche L1. - -Of course, we're happy to talk to you about your architecture and help you choose the best path forward. Feel free to reach out to us on [Discord](https://chat.avalabs.org/) or other [community channels](https://www.avax.network/community) we run. \ No newline at end of file diff --git a/content/docs/dapps/deploy-nft-collection/deploy-erc-721.mdx b/content/docs/dapps/deploy-nft-collection/deploy-erc-721.mdx deleted file mode 100644 index 85ad48ee011..00000000000 --- a/content/docs/dapps/deploy-nft-collection/deploy-erc-721.mdx +++ /dev/null @@ -1,174 +0,0 @@ ---- -title: Deploy ERC-721 Contract -description: Learn how to deploy an ERC-721 contract on the Avalanche C-chain. ---- - -This tutorial will start you with a basic [ERC-721 (NFT)](https://eips.ethereum.org/EIPS/eip-721) smart contract on the Avalanche Network, regardless of your previous development experience. We'll deploy our NFT on the Avalanche Fuji Testnet and view it on the Snowtrace Testnet Explorer. - -Note that these aren't transferable to the Mainnet. However, once you feel comfortable launching your project, you can do so on the Avalanche Mainnet and list it on an NFT marketplace. - -The following tools will be used during this tutorial: - -- [Pinata](https://www.pinata.cloud/): To store your NFT images and metadata. -- [OpenZeppelin's Wizard](https://wizard.openzeppelin.com/#erc721): to create the ERC-721 smart contract. -- [Remix IDE](https://remix-project.org/): To edit the code and deploy it to Fuji. -- [Avalanche Testnet Faucet](https://core.app/tools/testnet-faucet/): To fund the deployment. -- [Core browser Extension](https://chrome.google.com/webstore/detail/core-crypto-wallet-nft-ex/agoakfejjabomempkjlepdflaleeobhb): To process transactions related to funding and deploying the smart contract. -- [Snowtrace Testnet Explorer](https://testnet.snowtrace.io/): To view the deployed smart contract. - - -This Solidity smart contract tutorial is for demonstration purposes only. Users should consider proper precautions, error handling, and safeguards for production use. No one at Ava Labs is responsible for your development, and you must take full responsibility for ensuring your code is secure. - - -## Preparing Your NFT Files - -The first step of setting up an NFT smart contract is having your NFT files ready to use. In this example, the files will get uploaded to Pinata, a pinning service that prevents files from being garbage collected on IPFS. - -If you're unfamiliar with the process of uploading image and metadata files to an IPFS provider for NFT collection usage, please check out [this article on preparing NFT files](/docs/dapps/deploy-nft-collection/prep-nft-files). Ensure that your files are uploaded and your base URI is ready to plug into your smart contract. - -Once the image and metadata files are ready, we can prepare to deploy a smart contract. - -## Preparing Your Environment - -### Core Extension - -You'll need the Core Extension installed on whatever browser you're using to be able to fund the deployment of the smart contract. If you've not done so already, download Core and enable Testnet Mode. To do that, go to **Settings** and click on **Advanced**. - -![Settings image 1](/images/nft-collection1.png) - -Here, turn on the **Testnet Mode** feature. This will automatically make Core switch to Fuji Testnet. - -![Settings image 2](/images/nft-collection2.png) - - -If you are using other wallets, like Core or MetaMask, you can add the Fuji Testnet using the following specs: - -- **Network Name**: Avalanche C-Chain -- **New RPC URL**: `https://api.avax-test.network/ext/bc/C/rpc` -- **ChainID**: `43113` -- **Symbol**: AVAX -- **Explorer**: [`https://testnet.snowtrace.io`](https://testnet.snowtrace.io) - - -### Getting Testnet Funds - -Because we're deploying on the Fuji Network, you'll need to get AVAX on the Fuji network. - -**Option 1 (Recommended):** Create a [Builder Hub account](https://build.avax.network/login) and connect your wallet to receive testnet AVAX automatically. - -**Option 2:** Use the [Avalanche Faucet](https://core.app/tools/testnet-faucet/). If you already have an AVAX balance greater than zero on Mainnet, paste your C-Chain address there, and request test tokens. Otherwise, please request a faucet coupon on [Guild](https://guild.xyz/avalanche). Admins and mods on the official [Discord](https://discord.com/invite/RwXY7P6) can provide testnet AVAX if developers are unable to obtain it from the other options. - -![Avalanche Faucet](/images/nft-collection3.png) - -## Creating the Smart Contract - -To create the smart contract, we're going to use [Open Zeppelin](https://docs.openzeppelin.com/). Open Zeppelin is a key tool for building smart contracts quickly and easily. While we're only scratching the surface in this tutorial, ample documentation is available on their website for you to read when you want to build more complex contracts. - -Open Zeppelin provides a [Contract Wizard](https://wizard.openzeppelin.com/#erc721) that will build out ERC contracts. To avoid any complex coding environments, we'll use this to create our ERC-721 contract. - -![Contract Wizard](/images/nft-collection4.png) - -Select `ERC-721` on the Contract Wizard to get started. This will create the contract in the [Solidity programming language](https://docs.soliditylang.org/en/v0.8.15/). - -As you can see, the template contract is bare-boned. We'll fill out the information in the left panel to auto-populate it into our contract. Make sure you change to the ERC-721 tab as you get started to make the proper contract. - -The Wizard auto-fills in a name and symbol for your NFT collection, which we'll modify here. I'm naming it `Photography` and giving it the symbol `FOTO`. If you chose your own files to use during this tutorial, you can choose a relevant name and symbol for your collection. - -The Base URI field listed here is the URL of the metadata folder uploaded to Pinata(for example, ours is `https://gateway.pinata.cloud/ipfs/QmYdWxbiwsfsYcW1CYQPgYujAc9FMLPG3fgFcxFskbSsFa`). Paste that into the Base URI field. After the Wizard adds our variables to the template, our contract should look like this: - -![Contract Wizard Populated](/images/nft-collection5.png) - -Next, we'll want to check the `Mintable` and `Auto Increment Ids` boxes. This will populate a mint function into our template that would handle the incrementing of token Ids on mint if we had more than one NFT in our collection. We still want it to auto-assign our 1 NFT, so we'll check it. - -This automatically checks the `Ownable` button, which gives the `safeMint` function the `onlyOwner` modifier. This modifier indicates that only the owner of the smart contract will be able to successfully call the function. - - -This modifier should be removed when creating a smart contract for a public mint. Otherwise, users wouldn't be able to successfully mint the NFTs when calling the `safeMint` function. This tutorial only handles the owner's wallet address, so it is being left in. - - -Now, our contract is a little more populated: - -![Contract Wizard SafeMint](/images/nft-collection6.png) - -For this simple example, we'll not add any additional functionality to the `safeMint` function. Currently, it mints one NFT to the address specified in the function call. There is no cost to mint the NFT other than the gas fee for the transaction itself. - -This `safeMint` function currently doubles as an airdrop function because the address the NFT is minted to does not need to be the function owner. This functionality becomes very useful when NFT collection owners want to give away NFTs for free outside of the normal minting window. - -At this point, our smart contract is ready. At the top, you can click `Open in Remix` to get ready to deploy your smart contract. - -![Contract Wizard Open Remix](/images/nft-collection7.png) - -## Deploying the Smart Contract with Remix - -[Remix IDE](https://remix.ethereum.org/) is a solidity compiler that allows you to edit, compile, and deploy your smart contract. This will prevent you from needing to download any other coding environments at this stage. - -Once you've imported your contract, the first thing you need to do is compile it. Hit the `Compile` button on the left-hand side. You could also use the keyboard shortcut `Ctrl / Command + S`. - -![Remix Compile](/images/nft-collection8.png) - -Once completed, you'll get a green checkmark on the far left tab and will see options to Publish on IPFS or Swarm. Those aren't important to our tutorial. Next, you'll click on the bottom tab on the left-hand side to move to the deployment page. - -![Remix Deploy Page](/images/nft-collection9.png) - -Now, we need to change the environment that Remix will try to use to deploy the smart contract. Click on the `Environment` drop-down, and select `Injected web3`. - -![Remix Web3](/images/nft-collection10.png) - -This should prompt you to connect with your Core account. Once connected, you can verify the correct connection by checking that the Account number matches your Core address. - -![Remix account](/images/nft-collection11.png) - -![Core account](/images/nft-collection12.png) - -Now click on the `Contract` drop-down and select the contract you created and compiled. It should show up with the name you gave it in the Open Zeppelin Wizard. - -![Remix Contract](/images/nft-collection13.png) - -Now, click deploy. This will open Core and ask you to confirm the transaction. Click `Confirm`. - -![Core Accept](/images/nft-collection14.png) - -It may take a second, but once completed, your newly deployed contract will appear underneath the `Transactions Recorded` field. - -![Remix Record](/images/nft-collection15.png) - -Copy your contract's address and open the [Snowtrace Testnet Explorer](https://testnet.snowtrace.io/). Paste your contract address in the search bar, and click `Search`. - -You'll now see [your contract information on Snowtrace](https://testnet.snowtrace.io/address/0xa03e85f4411e37cbaff635975bf38cb2737f0015). The first transaction you see should be the contract deployment you just did in the Remix IDE. - -![Snowtrace](/images/nft-collection16.png) - -## Minting an NFT - -Now that you've deployed the contract, you can mint the NFT. Go back to the Remix IDE tab and click on your contract to expand its information. A list of functions will appear that you can interact with. - -![Remix Functions](/images/nft-collection17.png) - -The only function you're interested in is the `safeMint` function. Click the drop-down arrow for the function to expand the address field. - -![](/images/nft-collection18.png) - -Now, copy your Core address and paste it into this address field. This will send the NFT to your address when the mint function is called. After, hit `transact`. - -This will reopen Core and ask you to verify the transaction. Click `Confirm` to mint your NFT. - -Once the transaction has been confirmed, you'll see a green checkmark in the terminal at the bottom of the Remix IDE. - -![Remix Confirm Mint](/images/nft-collection19.png) - -Head back to the Snowtrace Testnet explorer page for your contract and refresh it. You should now see a second transaction, your call to `safeMint`. - -![Snowtrace Mint](/images/nft-collection20.png) - -By clicking on the [TX Hash](https://testnet.snowtrace.io/tx/0x8b698ac72bd20b2a640167c5d9bacdcbb3d86fd696eb8cde6f28347f6f99a2c9), you see that your NFT was created! - -![Snowtrace Transaction](/images/nft-collection21.png) - -## On Mainnet - -All of the above steps can be used on Mainnet except the following changes: - -- Make sure that you switch to the Avalanche C-Chain in Core. -- Make sure that you have AVAX tokens in your account to cover transaction costs. -- You should use the Mainnet version of [Snowtrace Explorer](https://snowtrace.io/) to view transactions. - diff --git a/content/docs/dapps/deploy-nft-collection/index.mdx b/content/docs/dapps/deploy-nft-collection/index.mdx deleted file mode 100644 index fcec0af531a..00000000000 --- a/content/docs/dapps/deploy-nft-collection/index.mdx +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Deploy NFT Collection -description: Learn how to deploy an NFT collection on the Avalanche C-chain. -index: true ---- diff --git a/content/docs/dapps/deploy-nft-collection/prep-nft-files.mdx b/content/docs/dapps/deploy-nft-collection/prep-nft-files.mdx deleted file mode 100644 index 0c645a1abce..00000000000 --- a/content/docs/dapps/deploy-nft-collection/prep-nft-files.mdx +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: Prepare NFT Files -description: Learn how to prepare your NFT files. ---- - -The first step of setting up an NFT smart contract is having your NFT files ready to use. In this example, the files will get uploaded to [Pinata](https://www.pinata.cloud/), a pinning service that prevents files from being garbage collected on IPFS. If you don't already have an account, please create one. - -Preparing the Images[​](#preparing-the-images "Direct link to heading") ------------------------------------------------------------------------ - -This tutorial will create only 1 NFT, however, if you're interested in creating more, you're more than welcome to do so. The image I'm using is linked here if you'd like to use it. - -![Original NFT Photo](/images/nft-files1.jpeg) - -Place your image file in a folder on your computer. Name this image `0`, so it'll be the first image pulled from the smart contract. it'll be the first (and only) NFT in this collection, however, if you're adding more images you'd continue naming them in sequential numeric order. you'll upload this folder to Pinata once your images are organized and named correctly. - -info - -NOTE: Some projects start file names with `0`, and others with `1`. That choice will need to be consistent with the smart contract code. To be consistent with [this ERC-721 tutorial](/docs/dapps/deploy-nft-collection/deploy-erc-721), we'll name this file `0`. - -![Image Folder](/images/nft-files2.png) - -After you log into Pinata, you'll see your dashboard. you'll see the upload button on the left. Click `Upload`, and then `Folder`. - -![Pinata Dashboard](/images/nft-files3.png) - -![Folder Button](/images/nft-files4.png) - -You'll then select the folder that the image is in. You may get a pop-up from your browser confirming you want to upload the folder and the files in it. If you do, confirm by clicking `Upload`. - -![Confirm Upload](/images/nft-files5.png) - -You'll then be prompted to name the folder you've uploaded. This is beneficial when you have several sets of folders uploaded to Pinata and are trying to keep them organized. After giving it a name, click `Upload` and wait for your file to upload. The quantity and size of the images could affect the upload time, but if you're starting small, it should only take a few seconds. - -Once the upload is complete, you'll see your folder in your dashboard. - -![Uploaded Image Folder](/images/nft-files6.png) - -If you click on the folder name, it'll redirect you to the Pinata gateway to be able to view your newly uploaded files. If you have a paid Pinata account, it'll open the folder through your own gateway. Having a paid plan and personal gateway is NOT required for this tutorial but is recommended to have for larger collection sizes and hosting multiple folders. - -If you right-click on the image, you can copy the image's url. This URL is important. Copy this down to use in the next step as we set up the metadata. For this example, my URL is `https://gateway.pinata.cloud/ipfs/QmPWbixyMsaNkR9v612bBFbncKGmgXDKz9CgMtDDD7Bymw/0.png` - -Now that we have the image uploaded and its URL, we can create the matching metadata file for it. - -Where this NFT is going to be an ERC-721, we know we can use metadata standards often found on Marketplaces such as [Joepegs.com](https://joepegs.com/). The .json file below is an example of what the [metadata](https://docs.opensea.io/docs/metadata-standards#metadata-structure) should look like. - -```json -{ - "name": "", - "tokenId": 0, - "image": "", - "description": "", - "attributes": [] -} -``` - -Now, we'll populate the values into the metadata file. You can choose any `name` and `description` that you want. - -The `tokenId` here will be `0` so that it corresponds to the image we just uploaded. If uploading multiple files, this needs to be incremented in each file. - -The `image` link is the URL we saved from the last step of the previous section. Paste that link here so the smart contract knows where to find the image file for your NFT. If uploading multiple files, the end of the URL (the specific image) needs to increment in each file. - -The `attributes` field isn't quite as important here, but if you were uploading NFTs with several layers, the attributes would be the information of those specific layers. This is often used when calculating the rarity of NFTs to be able to rank them by how frequently their layers appear throughout the entire collection. it'll be erased in this tutorial. - -Below is an example of how you'd fill out the fields in the metadata file. - -```json -{ - "name": "Cool Photography", - "tokenId": 0, - "image": "https://gateway.pinata.cloud/ipfs/QmPWbixyMsaNkR9v612bBFbncKGmgXDKz9CgMtDDD7Bymw/0.png", - "description": "A cool image" -} -``` - -When saving this file, you want it to share the same name as the image it corresponds to. In this case, it is 0. - -Once the metadata file is uploaded to Pinata, the file extension will actually not be needed. it'll search for the file as a directory and be able to pull its information from there. To remove the file extension, follow these steps for a [Mac](https://support.apple.com/guide/mac-help/show-or-hide-filename-extensions-on-mac-mchlp2304/mac) environment, or these for a [Windows](https://www.techwalla.com/articles/how-to-remove-file-extensions) environment. - -Now that the file extension has been removed, place it in another folder as you did with the image file. They need to be SEPARATE folders. - -![Metadata Folder](/images/nft-files7.png) - -You'll now repeat the folder upload process to add the metadata to Pinata. Follow the same steps as above. Once completed, you'll have both folders available on your dashboard. - -![Uploaded Folders](/images/nft-files8.png) - -Click on the metadata folder to be directed to the IPFS gateway and save the URL. This URL will be your base URL and won't need the direct file links. The smart contract will append the necessary file information for each NFT as needed. For example, my URL is `https://gateway.pinata.cloud/ipfs/QmYdWxbiwsfsYcW1CYQPgYujAc9FMLPG3fgFcxFskbSsFa`. - -Now that the image and metadata files are ready, we can prepare to deploy a smart contract by following this [ERC-721 tutorial](/docs/dapps/deploy-nft-collection/deploy-erc-721). diff --git a/content/docs/dapps/end-to-end/fuji-workflow.mdx b/content/docs/dapps/end-to-end/fuji-workflow.mdx deleted file mode 100644 index de470de7277..00000000000 --- a/content/docs/dapps/end-to-end/fuji-workflow.mdx +++ /dev/null @@ -1,332 +0,0 @@ ---- -title: Fuji Workflow -description: Learn how to use the Fuji Testnet. ---- - -## Introduction - -Fuji is the Avalanche network's test network. You can use it to test your dapp -or smart contract after you've developed it locally. Fuji is -typically on the same version as the Avalanche Mainnet, but sometimes it is -running an unreleased version of AvalancheGo. - -In general, you can expect Fuji's behavior to be about the same as Avalanche Mainnet. Tools such as a explorers -and wallets should work with the Fuji Testnet. - -In this tutorial, we'll go through an example Fuji workflow to show how it can -be used. We'll do the following: - -1. Set up Fuji network on Core (optional) -2. Generate a 24 word english mnemonic via AvalancheJS -3. Derive external C-Chain addresses via AvalancheJS -4. Get AVAX from the Fuji faucet -5. Send AVAX via ethersJS -6. Examine the resulting transaction on the Avalanche Explorer -7. Use a private key derived from a mnemonic to sign into the Core extension (wallet) - -## Set up Fuji Network on Core (optional) - -To access the Fuji test network, Testnet Mode needs to be enabled. -In order to do that, go to **Settings** and click on **Advanced**. - -![Settings image 1](/images/fuji1.png) - -Here, turn on the **Testnet Mode** feature. This will automatically make Core switch to -Fuji Testnet. - -![Settings image 2](/images/fuji2.png) - - -If you are using other wallets, like MetaMask, you can add the Fuji Testnet -using the following details: - -- **Network Name**: Avalanche C-Chain -- **New RPC URL**: `https://api.avax-test.network/ext/bc/C/rpc` -- **ChainID**: `43113` -- **Symbol**: AVAX -- **Explorer**: [`https://testnet.snowtrace.io`](https://testnet.snowtrace.io/) - - -## Generate a Mnemonic - -To begin, we'll create a mnemonic phrase with -[AvalancheJS](/docs/tooling/avalanche-js). Mnemonics enable us to encode -strong security into a human-readable phrase. AvalancheJS supports 10 languages -including English, Japanese, Spanish, Italian, French, Korean, Czech, -Portuguese, Chinese Simplified and Chinese Traditional. - -First, generate a 24 word english -[BIP39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki)-compliant -mnemonic via AvalancheJS. - -```ts -import { Mnemonic } from "avalanche"; -const mnemonic: Mnemonic = Mnemonic.getInstance(); -const strength: number = 256; -const wordlist = mnemonic.getWordlists("english") as string[]; -const m: string = mnemonic.generateMnemonic(strength, randomBytes, wordlist); -console.log(m); -// "chimney asset heavy ecology accuse window gold weekend annual oil emerge alley retreat rabbit seed advance define off amused board quick wealth peasant disorder" -``` - -## Derive Addresses - -After generating a mnemonic we can use AvalancheJS to derive -[BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)-compliant -hierarchical deterministic (HD) Keypairs. - -```ts -import HDNode from "avalanche/dist/utils/hdnode"; -import { Avalanche, Mnemonic, Buffer } from "avalanche"; -import { EVMAPI, KeyChain } from "avalanche/dist/apis/evm"; -import { ethers } from "ethers"; - -const ip: string = "api.avax-test.network"; -const port: number = 443; -const protocol: string = "https"; -const networkID: number = 5; -const avalanche: Avalanche = new Avalanche(ip, port, protocol, networkID); -const cchain: EVMAPI = avalanche.CChain(); - -const mnemonic: Mnemonic = Mnemonic.getInstance(); -const m: string = "chimney asset heavy ecology accuse window gold weekend annual oil emerge alley retreat rabbit seed advance define off amused board quick wealth peasant disorder"; -const seed: Buffer = mnemonic.mnemonicToSeedSync(m); -const hdnode: HDNode = new HDNode(seed); - -const keyChain: KeyChain = cchain.newKeyChain(); - -const cAddresses: string[] = []; - -for (let i: number = 0; i <= 2; i++) { - const child: HDNode = hdnode.derive(`m/44'/60'/0'/0/${i}`); - keyChain.importKey(child.privateKey); - const cchainAddress = ethers.utils.computeAddress(child.privateKey); - cAddresses.push(cchainAddress); -} -console.log(cAddresses); -// [ -// '0x2d1d87fF3Ea2ba6E0576bCA4310fC057972F2559', -// '0x25d83F090D842c1b4645c1EFA46B15093d4CaC7C', -// '0xa14dFb7d8593c44a47A07298eCEA774557036ff3' -// ] -``` - -### Generate Private Keys from a Mnemonic - -As long as you have the mnemonic phrase, you can re-generate your private keys -and the addresses they control. - -For example, if you want to generate the private keys for the first 3 address in the C Chain keychain: - -- [0x2d1d87fF3Ea2ba6E0576bCA4310fC057972F2559](https://testnet.snowtrace.io/address/0x2d1d87fF3Ea2ba6E0576bCA4310fC057972F2559) -- [0x25d83F090D842c1b4645c1EFA46B15093d4CaC7C](https://testnet.snowtrace.io/address/0x25d83F090D842c1b4645c1EFA46B15093d4CaC7C) -- [0xa14dFb7d8593c44a47A07298eCEA774557036ff3](https://testnet.snowtrace.io/address/0xa14dFb7d8593c44a47A07298eCEA774557036ff3) - -you might update the example script above to the following: - -```ts -const cAddresses: string[] = []; -const privateKeys: string[] = []; -for (let i: number = 0; i <= 2; i++) { - // Deriving the _i_th external BIP44 C-Chain address - const child: HDNode = hdnode.derive(`m/44'/60'/0'/0/${i}`); - keyChain.importKey(child.privateKey); - // Converting the BIP44 addresses to hexadecimal addresses - const cchainAddress = ethers.utils.computeAddress(child.privateKey); - privateKeys.push(child.privateKey.toString("hex")); - cAddresses.push(cchainAddress); -} -console.log({ cAddresses, privateKeys }); -// { -// cAddresses: [ -// '0x2d1d87fF3Ea2ba6E0576bCA4310fC057972F2559', -// '0x25d83F090D842c1b4645c1EFA46B15093d4CaC7C', -// '0xa14dFb7d8593c44a47A07298eCEA774557036ff3' -// ], -// privateKeys: [ -// 'cd30aef1af167238c627593537e162ecf5aad1d4ab4ea98ed2f96ad4e47006dc', -// 'b85479b26bc8fbada4737e90ab2133204f2fa2a9ea33c1e0de4452cbf8fa3be4', -// 'c72e18ea0f9aa5457396e3bf810e9de8df0177c8e4e5bf83a85f871512d645a9' -// ] -// } -``` - -## Get a Drip from the Fuji Faucet - -**Option 1 (Recommended):** Create a [Builder Hub account](https://build.avax.network/login) and connect your wallet to receive testnet AVAX automatically. - -**Option 2:** Use the external faucet at [core.app/tools/testnet-faucet](https://core.app/tools/testnet-faucet/). If you already have an AVAX balance greater than zero on Mainnet, paste your C-Chain address there, and request test tokens. Otherwise, please request a faucet coupon on [Guild](https://guild.xyz/avalanche). - -Admins and mods on the official [Discord](https://discord.com/invite/RwXY7P6) -can provide testnet AVAX if developers are unable to obtain it from the other two options. -These AVAX are for the Fuji Testnet and have no monetary value. - -![Requesting AVAX](/images/fuji3.png) - -The faucet will send some AVAX to the address and return a transaction ID -(txID). This txID can be used with the Fuji Testnet Explorer to learn more about -the transaction. - -![Receiving AVAX](/images/fuji4.png) - -### Check the Transaction Details - -The txID, `0x1419b04559bf140ab82216f7696110936fb7d4bc1f147e3b85fef7ca1008a19e`, -can be seen on the [Fuji Testnet -Explorer](https://subnets-test.avax.network/c-chain/tx/0x86eef1a01b0a5fd45f2a71c217f99d63d427230a271d3319004f17fc26d7fb26). -Avalanche also has a [Mainnet Explorer](https://explorer.avax.network). - -![Transaction details](/images/fuji5.png) - -### Get the Balance - -We can also use the Fuji Explorer to get the balance for the 1st address—[0x2d1d87fF3Ea2ba6E0576bCA4310fC057972F2559](https://explorer.avax-test.network/address/0x2d1d87fF3Ea2ba6E0576bCA4310fC057972F2559). - -![1st derived address balance](/images/fuji6.png) - -Alternatively, we can use [ethersJS](https://docs.ethers.io/v5/) to get the balance. - -```ts -const ethers = require("ethers"); -const network = "https://api.avax-test.network/ext/bc/C/rpc"; -const provider = ethers.getDefaultProvider(network); -const address = "0x2d1d87fF3Ea2ba6E0576bCA4310fC057972F2559"; - -const main = async (): Promise => { - provider.getBalance(address).then((balance) => { - // convert a currency unit from wei to ether - const balanceInAvax = ethers.utils.formatEther(balance); - console.log(`balance: ${balanceInAvax} AVAX`); - // balance: 2 AVAX - }); -}; - -main(); -``` - -## Sending AVAX - -The faucet sent 2 AVAX to the first address we generated. Let's send AVAX from -the 1st address to the 2nd address. - -```ts -// import ethers.js -import { ethers } from "ethers"; -// network: using the Fuji testnet -const network = "https://api.avax-test.network/ext/bc/C/rpc"; -// provider: establish and RPC connection to the network -const provider = new ethers.providers.JsonRpcProvider(network); - -// Sender private key: -// corresponding address 0x0x2d1d87fF3Ea2ba6E0576bCA4310fC057972F2559 -let privateKey = - "cd30aef1af167238c627593537e162ecf5aad1d4ab4ea98ed2f96ad4e47006dc"; -// Create a wallet instance -let wallet = new ethers.Wallet(privateKey, provider); -// Receiver Address -let receiverAddress = "0x25d83F090D842c1b4645c1EFA46B15093d4CaC7C"; -// AVAX amount to send -let amountInAvax = "0.01"; -// Create a transaction object -let tx = { - to: receiverAddress, - // Convert currency unit from ether to wei - value: ethers.utils.parseEther(amountInAvax), -}; -// Send a transaction -wallet.sendTransaction(tx).then((txObj) => { - console.log(`"tx, https://testnet.snowtrace.io/tx/${txObj.hash}`); - // A transaction result can be checked in a snowtrace with a transaction link which can be obtained here. -}); -``` - -### Verify Success - -We can verify that the transaction, -`0x3a5f4198b3be8d24b272f8255912aae4dcf2fb1f97f70d1787434de7b3097aac`, was -successful using the Fuji Testnet Explorer. The transaction can be seen -[here](https://testnet.snowtrace.io/tx/0x3a5f4198b3be8d24b272f8255912aae4dcf2fb1f97f70d1787434de7b3097aac). - -![Transaction details](/images/fuji7.png) - -#### Get the Balance - -We can also use the Fuji Explorer to get the balance for the 2nd address—[0x25d83F090D842c1b4645c1EFA46B15093d4CaC7C](https://testnet.snowtrace.io/address/0x25d83F090D842c1b4645c1EFA46B15093d4CaC7C). - -Alternatively, we can use ethersJS to get the balance. - -```ts -const ethers = require("ethers"); -const network = "https://api.avax-test.network/ext/bc/C/rpc"; -const provider = ethers.getDefaultProvider(network); -const address = "0x25d83F090D842c1b4645c1EFA46B15093d4CaC7C"; - -const main = async (): Promise => { - provider.getBalance(address).then((balance) => { - // convert a currency unit from wei to ether - const balanceInAvax = ethers.utils.formatEther(balance); - console.log(`balance: ${balanceInAvax} AVAX`); - // balance: 0.02 AVAX - }); -}; - -main(); -``` - -### Sign in to Core Extension - -Lastly, we can [use the mnemonic to generate a private -key](#generate-private-keys-from-a-mnemonic) to access that account in -[Core extension](https://core.app/en/). -We'll see that it has the AVAX balance and -that it derives the hexadecimal address from the private key. - -Use the private key to access the account in Core Extension. - -![Access the wallet](/images/fuji8.png) - -The balance is correct and the address is the 1st derived address. - -![Core extension balance](/images/fuji9.png) ![3rd derived BIP44 address](/images/fuji10.png) - -We can repeat this login process using the private keys from the remaining 2 -addresses in the [script above](#generate-private-keys-from-a-mnemonic). - -![Wallet derived addresses](/images/fuji11.png) -![Wallet derived addresses2](/images/fuji12.png) -![Wallet derived addresses3](/images/fuji13.png) - -## Summary - -The Fuji Testnet plays a critical role in testing dapps, smart -contracts and financial products before deploying to the Mainnet. Tooling like -AvalancheJS, the public API, faucet, and explorer helps to ensure that your -testing and QA environment is close to Mainnet so that you can be confident when -you launch on Mainnet. - -## Resources - -For additional and valuable resources please see below. - -### Faucet - -You can get testnet AVAX in two ways: -- **Recommended:** Create a [Builder Hub account](https://build.avax.network/login) and connect your wallet to receive testnet AVAX automatically -- **Alternative:** Use the [Fuji Faucet](https://core.app/tools/testnet-faucet/) which sends AVAX to X-Chain or C-Chain addresses. (This testnet AVAX has no value.) - -### Wallet - -[Core extension](https://core.app/en/) and -[Core mobile](https://support.avax.network/en/articles/6066926-core-mobile-how-do-i-create-a-new-wallet) -are simple, secure, non-custodial wallets for storing Avalanche assets. -They support Mainnet, Fuji and custom networks. - -### Explorer - -The Avalanche Explorer allows you to explore the network on -[Mainnet](https://explorer.avax.network) and -[Fuji](https://explorer.avax-test.network). - -### RPC Endpoints - Public API Server - -See [here.](/docs/tooling/rpc-providers) diff --git a/content/docs/dapps/end-to-end/launch-ethereum-dapp.mdx b/content/docs/dapps/end-to-end/launch-ethereum-dapp.mdx deleted file mode 100644 index 09155f5dc17..00000000000 --- a/content/docs/dapps/end-to-end/launch-ethereum-dapp.mdx +++ /dev/null @@ -1,322 +0,0 @@ ---- -title: Ethereum dApp → Avalanche -description: Learn how to port a decentralized application from Ethereum to Avalanche. ---- - -## Overview - -The purpose of this document is to help you with launching your existing dapp on -Avalanche. It contains a series of resources designed to help you get the basics -of Avalanche Platform and how it works, show how to connect to the network, how -to use your existing tools and environments in developing and deploying on -Avalanche, as well as some common pitfalls you need to consider when running -your dapp on Avalanche. - -## Accessing Avalanche C-Chain - -C-Chain exposes the [same API](/docs/api-reference/c-chain/api) as -`go-ethereum`, so you can use all the familiar APIs that are available on Ethereum -for interaction with the platform. - -There are multiple ways of working with the C-Chain. - -### Through Core - -Powered by Avalanche, -[Core](https://core.app/en/) -is an all-in-one operating system bringing together Avalanche apps, Avalanche L1s, -bridges, and NFTs in one seamless, high-performance browser experience. Putting -in another way, Core is more than a wallet. It is a curated web3 operating -system combining Wallet, Explorer, Bridge, Avalanche L1s, dApps, and more. - -In your application's web interface, follow [this to add Avalanche programmatically](/docs/dapps/advanced-tutorials/add-network-programmatically#core). - -### Through MetaMask - -You can access C-Chain through MetaMask, by defining a custom network. Go to -MetaMask, log in, click the network dropdown, and select 'Custom RPC'. Data for -Avalanche is as follows. - -#### **Avalanche Mainnet Settings:** - -- **Network Name**: Avalanche Mainnet C-Chain -- **New RPC URL**: `https://api.avax.network/ext/bc/C/rpc` -- **ChainID**: `43114` -- **Symbol**: `AVAX` -- **Explorer**: [https://snowtrace.io/](https://snowtrace.io/) - -#### **Fuji Testnet Settings:** - -- **Network Name**: Avalanche Fuji C-Chain -- **New RPC URL**: `https://api.avax-test.network/ext/bc/C/rpc` -- **ChainID**: `43113` -- **Symbol**: `AVAX` -- **Explorer**: [https://testnet.snowtrace.io/](https://testnet.snowtrace.io/) - -In your application's web interface, you can -[add Avalanche programmatically](/docs/dapps/advanced-tutorials/add-network-programmatically#metamask) -so your users don't have to enter the network data manually. - -### Using the Public API Nodes or RPC Endpoints - -Instead of proxying network operations through MetaMask, you can use the public -API, which consists of a number of AvalancheGo nodes behind a load balancer. - -The C-Chain API endpoint is -`https://api.avax.network/ext/bc/C/rpc` -for the Mainnet and -`https://api.avax-test.network/ext/bc/C/rpc` -for the testnet. - -For more information, see [documentation](/docs/tooling/rpc-providers). - -However, public API does not expose all the APIs that are available on the node, -as some of them would not make sense on a publicly accessible service, and some -would present a security risk. If you need to use an API that is not available -publicly, you can run your own node. - -## Running Your Own Node - -If you don't want your dapp to depend on a centralized service you don't -control, or have specific needs that cannot be met through the public API, you -can run your own node and access the network that way. Running your own node -also avoids potential issues with public API congestion and rate-limiting. - -For development and experimental purposes, -[here](/docs/nodes/run-a-node/from-source) is a tutorial that shows -how to download, build, and install AvalancheGo. Simpler solution is to use the -prebuilt binary, available on -[GitHub](https://github.com/ava-labs/avalanchego/releases). - -If you're going to run a node on a Linux machine, you can use the -[installer script](/docs/nodes/using-install-script/installing-avalanche-go) to install the node as a -`systemd` service. Script also handles node upgrading. - -If you want to run a node in a docker container, there are [build -scripts](https://github.com/ava-labs/avalanchego/tree/master/scripts) in the -AvalancheGo repo for various Docker configs. - -### Node Configuration - -Node configuration options are explained -[here](/docs/nodes/configure/configs-flags). But unless you have -specific needs, you can mostly leave the main node config options at their -default values. - -On the other hand, you will most likely need to adjust C-Chain configuration to -suit your intended use. You can look up complete configuration options for -C-Chain [here](/docs/nodes/chain-configs/c-chain) as well -as the default configuration. Note that only the options that are different from -their default values need to be included in the config file. - -By default, the C-Chain config file is located at -`$HOME/.avalanchego/configs/chains/C/config.json`. We will go over how to adjust -the config to cover some common use cases in the following sections. - -#### Running an Archival Node - -If you need Ethereum's [Archive -Node](https://ethereum.org/en/developers/docs/nodes-and-clients/#archive-node) -functionality, you need to disable C-Chain pruning, which is enabled by default -to conserve disk space. To preserve full historical state, include -`"pruning-enabled": false` in the C-Chain config file. - - -After changing the flag to disable the database pruning, you will need to run -the bootstrap process again, as the node will not backfill any already pruned -and missing data. - -To re-bootstrap the node, stop it, delete the database (by default stored in -`~/.avalanchego/db/`) and start the node again. - - -#### Running a Node in Debug Mode - -By default, debug APIs are disabled. To enable them, you need to enable the -appropriate EVM APIs in the config file by including the `eth-apis` value in -your C-Chain config file to include the `debug`, `debug-tracer`, and -`internal-debug` APIs. - - -Including the `eth-apis` in the config flag overrides the defaults, so you need -to include the default APIs as well! - - -#### Example C-Chain Config File - -An example C-Chain config file that includes the archival mode, enables debug -APIs as well as default EVM APIs: - -```json -{ - "eth-apis": [ - "eth", - "eth-filter", - "net", - "web3", - "internal-eth", - "internal-blockchain", - "internal-transaction", - "debug-tracer" - ], - "pruning-enabled": false -} -``` - -Default config values for the C-Chain can be seen [here](/docs/nodes/chain-configs/c-chain). - -### Running a Local Test Network - -If you need a private test network to test your dapp, [Avalanche Network -Runner](https://github.com/ava-labs/avalanche-network-runner) is a shell client -for launching local Avalanche networks, similar to Ganache on Ethereum. - -For more information, see [documentation](/docs/tooling/avalanche-network-runner/introduction). - -## Developing and Deploying Contracts - -Being an Ethereum-compatible blockchain, all of the usual Ethereum developer -tools and environments can be used to develop and deploy dapps for Avalanche's -C-Chain. - -### Remix - -There is a -[tutorial](/docs/dapps/smart-contract-dev/deploy-with-remix-ide) -for using Remix to deploy smart contracts on Avalanche. It relies on Core -for access to the Avalanche network. - -### thirdweb - -You can also use thirdweb to test and deploy smart contracts on Avalanche. Find out how in this [tutorial](/docs/dapps/toolchains/thirdweb). - -### Hardhat - -Hardhat is the newest development and testing environment for Solidity smart -contracts, and the one our developers use the most. Due to its superb testing -support, it is the recommended way of developing for Avalanche. - -For more information see [this doc](/docs/dapps/toolchains/hardhat). - -## Avalanche Explorer - -An essential part of the smart contract development environment is the explorer, -which indexes and serves blockchain data. Mainnet C-Chain explorer is available -at [https://snowtrace.io/](https://snowtrace.io/) and testnet explorer at -[https://testnet.snowtrace.io/](https://testnet.snowtrace.io/). Besides the web -interface, it also exposes the standard [Ethereum JSON RPC -API](https://eth.wiki/json-rpc/API). - -## Avalanche Faucet - -For development purposes, you will need test tokens. Avalanche has a -[Faucet](https://core.app/tools/testnet-faucet/) that drips test tokens to the address of -your choice. If you already have an AVAX balance greater than zero on Mainnet, -paste your C-Chain address there, and request test tokens. Otherwise, -please request a faucet coupon on -[Guild](https://guild.xyz/avalanche). Admins and mods on the official [Discord](https://discord.com/invite/RwXY7P6) -can provide testnet AVAX if developers are unable to obtain it from the other two options. - -If you need, you can also run a faucet locally, but building it from the [repository](https://github.com/ava-labs/avalanche-faucet). - -## Contract Verification - -Smart contract verification provides transparency for users interacting with -smart contracts by publishing the source code, allowing everyone to attest that -it really does what it claims to do. You can verify your smart contracts using -the [C-Chain explorer](https://snowtrace.io/). The procedure is simple: - -- navigate to your published contract address on the explorer -- on the `code` tab select `verify & publish` -- copy and paste the flattened source code and enter all the build parameters exactly as they are on the published contract -- click `verify & publish` - -If successful, the `code` tab will now have a green checkmark, and your users -will be able to verify the contents of your contract. This is a strong positive -signal that your users can trust your contracts, and it is strongly recommended -for all production contracts. - -See -[this](/docs/dapps/verify-contract/hardhat) -for a detailed tutorial with Hardhat. - -## Contract Security Checks - -Due to the nature of distributed apps, it is very hard to fix bugs once the -application is deployed. Because of that, making sure your app is running -correctly and securely before deployment is of great importance. Contract -security reviews are done by specialized companies and services. They can be -very expensive, which might be out of reach for single developers and startups. -But, there are also automated services and programs that are free to use. - -Most popular are: - -- [Slither](https://github.com/crytic/slither), here's a [tutorial](https://blog.trailofbits.com/2018/10/19/slither-a-solidity-static-analysis-framework/) -- [MythX](https://mythx.io/) -- [Mythril](https://github.com/ConsenSys/mythril) - -We highly recommend using at least one of them if professional contract security -review is not possible. A more comprehensive look into secure development -practices can be found -[here](https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/workflow.md). - -## Gotchas and Things to Look out For - -Avalanche Platform's C-Chain is EVM-compatible, but it is not identical. There -are some differences you need to be aware of, otherwise, you may create subtle -bugs or inconsistencies in how your dapps behave. - -Here are the main differences you should be aware of. - -### Measuring Time - -Avalanche does not use the same mechanism to measure time as Ethereum which uses -consistent block times. Instead, Avalanche supports asynchronous block issuance, -block production targets a rate of every 2 seconds. If there is sufficient -demand, a block can be produced earlier. If there is no demand, a block will not -be produced until there are transactions for the network to process. - -Because of that, you should not measure the passage of time by the number of -blocks that are produced. The results will not be accurate, and your contract -may be manipulated by third parties. - -Instead of block rate, you should measure time simply by reading the timestamp -attribute of the produced blocks. Timestamps are guaranteed to be monotonically -increasing and to be within 30 seconds of the real time. - -### Finality - -On Ethereum, the blockchain can be reorganized and blocks can be orphaned, so -you cannot rely on the fact that a block has been accepted until it is several -blocks further from the tip (usually, it is presumed that blocks 6 places deep -are safe). That is not the case on Avalanche. Blocks are either accepted or -rejected within a second or two. And once the block has been accepted, it is -final, and cannot be replaced, dropped, or modified. So the concept of 'number -of confirmations' on Avalanche is not used. As soon as a block is accepted and -available in the explorer, it is final. - -### Using `eth_newFilter` and Related Calls with the Public API - -If you're using the -[`eth_newFilter`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_newfilter) API method on the -public API server, it may not behave as you expect because the public API is -actually several nodes behind a load balancer. If you make an `eth_newFilter` -call, subsequent calls to -[`eth_getFilterChanges`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getfilterchanges) may -not end up on the same node as the first call, and you will end up with -undefined results. - -If you need the log filtering functionality, you should use a websocket -connection, which ensures that your client is always talking to the same node -behind the load balancer. Alternatively, you can use -[`eth_getLogs`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getlogs), or run your own node -and make API calls to it. - -## Support - -Using this tutorial you should be able to quickly get up to speed on Avalanche, -deploy, and test your dapps. If you have questions, problems, or just want to -chat with us, you can reach us on our public -[Discord](https://chat.avalabs.org/) server. We'd love to hear from you and find -out what you're building on Avalanche! - diff --git a/content/docs/dapps/index.mdx b/content/docs/dapps/index.mdx index c2ecf278c40..349e0142828 100644 --- a/content/docs/dapps/index.mdx +++ b/content/docs/dapps/index.mdx @@ -1,38 +1,153 @@ --- -title: Introduction -description: Learn about the Avalanche C-Chain. +title: Network Information +description: Connect to Avalanche networks and explore the ecosystem. --- -Avalanche is a [network of networks](/docs/quick-start/primary-network). One of the chains running on Avalanche Primary Network is an EVM fork called the C-Chain (contract chain). +import { Network, Layers, Terminal, ArrowRight, Database, Package } from 'lucide-react'; -C-Chain runs a fork of [`go-ethereum`](https://geth.ethereum.org/docs/rpc/server) called [`coreth`](https://github.com/ava-labs/coreth) that has the networking and consensus portions replaced with Avalanche equivalents. What's left is the Ethereum VM, which runs Solidity smart contracts and manages data structures and blocks on the chain. +Avalanche provides both production and test networks for building and deploying decentralized applications. The Primary Network consists of three blockchains: C-Chain (Contract Chain), P-Chain (Platform Chain), and X-Chain (Exchange Chain). -As a result, you get a blockchain that can run all the Solidity smart contracts from Ethereum, but with much greater transaction bandwidth and instant finality that [Avalanche's revolutionary consensus](/docs/quick-start/avalanche-consensus) enables. +### C-Chain (Contract Chain) -Coreth is loaded as a plugin into [AvalancheGo](https://github.com/ava-labs/avalanchego), the client node application used to run Avalanche network. Any dApp deployed to Avalanche C-Chain will function the same as on Ethereum, but much faster and cheaper. +The C-Chain is an EVM-compatible blockchain for deploying smart contracts and dApps. -## Add C-Chain to Wallet +| Property | Mainnet | Fuji Testnet | +|----------|---------|--------------| +| **Network Name** | Avalanche C-Chain | Avalanche Fuji C-Chain | +| **Chain ID** | 43114 (0xA86A) | 43113 (0xA869) | +| **Currency** | AVAX | AVAX | +| **RPC URL** | https://api.avax.network/ext/bc/C/rpc | https://api.avax-test.network/ext/bc/C/rpc | +| **Explorer** | https://subnets.avax.network/c-chain | https://subnets-test.avax.network/c-chain | +| **Faucet** | - | [Get Test AVAX](/console/primary-network/faucet) | +| **Add to Wallet** | | | -### Avalanche C-Chain Mainnet +### P-Chain (Platform Chain) -- **Network Name**: Avalanche Mainnet C-Chain -- **RPC URL**: https://api.avax.network/ext/bc/C/rpc -- **WebSocket URL**: wss://api.avax.network/ext/bc/C/ws -- **ChainID**: `43114` -- **Symbol**: `AVAX` -- **Explorer**: https://subnets.avax.network/c-chain +The P-Chain manages validators, staking, and Avalanche L1 creation. -### Avalanche Fuji Testnet +| Property | Mainnet | Fuji Testnet | +|----------|---------|--------------| +| **RPC URL** | https://api.avax.network/ext/bc/P | https://api.avax-test.network/ext/bc/P | +| **Currency** | AVAX | AVAX | +| **Explorer** | https://subnets.avax.network/p-chain | https://subnets-test.avax.network/p-chain | -- **Network Name**: Avalanche Fuji C-Chain -- **RPC URL**: https://api.avax-test.network/ext/bc/C/rpc -- **WebSocket URL**: wss://api.avax-test.network/ext/bc/C/ws -- **ChainID**: `43113` -- **Symbol**: `AVAX` -- **Explorer**: https://subnets-test.avax.network/c-chain +### X-Chain (Exchange Chain) -### Via Block Explorers +The X-Chain is used for creating and trading Avalanche Native Tokens. -Head to either explorer linked above and select "Add Avalanche C-Chain to Wallet" under "Chain Info" to automatically add the network. +| Property | Mainnet | Fuji Testnet | +|----------|---------|--------------| +| **RPC URL** | https://api.avax.network/ext/bc/X | https://api.avax-test.network/ext/bc/X | +| **Currency** | AVAX | AVAX | +| **Explorer** | https://subnets.avax.network/x-chain | https://subnets-test.avax.network/x-chain | -Alternatively, visit [chainlist.org](https://chainlist.org/?search=Avalanche&testnets=true) and connect your wallet. \ No newline at end of file +## Explore More + + diff --git a/content/docs/dapps/meta.json b/content/docs/dapps/meta.json index 35c5c1d3c42..1859618b7c7 100644 --- a/content/docs/dapps/meta.json +++ b/content/docs/dapps/meta.json @@ -4,22 +4,16 @@ "icon": "SquareChartGantt", "root": true, "pages": [ - "---dApps on Avalanche---", "index", - "c-chain-or-avalanche-l1", - "[Block Explorers](/integrations#Block%20Explorers)", "---Smart Contract Development---", - "smart-contract-dev/get-test-funds", "smart-contract-dev/deploy-with-remix-ide", "smart-contract-dev/erc-20-token", - "deploy-nft-collection", "toolchains", "---Contract Verification---", "verify-contract/explorer", "verify-contract/snowtrace", "verify-contract/hardhat", "---Advanced Tutorials---", - "...advanced-tutorials", - "...end-to-end" + "...advanced-tutorials" ] } \ No newline at end of file diff --git a/content/docs/dapps/smart-contract-dev/erc-20-token.mdx b/content/docs/dapps/smart-contract-dev/erc-20-token.mdx deleted file mode 100644 index ca6b4a29c37..00000000000 --- a/content/docs/dapps/smart-contract-dev/erc-20-token.mdx +++ /dev/null @@ -1,132 +0,0 @@ ---- -title: Create an ERC-20 Token -description: Create an ERC-20 Token ---- - -[ERC-20 tokens](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/) are the most fundamental and essential concept in Ethereum. As the Avalanche community and the ecosystem are growing, new use cases and projects that are running on Ethereum or different chains would be implemented to Avalanche. - -Therefore, we will be creating our own mintable ERC-20 token and will mint it to any address we want. The token will be generated on Avalanche C-Chain and will be accessible on that chain. We are using Fuji Testnet in this tutorial. - -The article focuses on deploying a smart contract written with Solidity to Avalanche. This is the feature that Avalanche provides us - to be able to deploy any smart contract to the chain and no requirement for a new language specific contract concept to interact. Let's look at how to create an ERC-20 contract and deploy it to avalanche C-Chain. - -## Setup Core Wallet - -The first thing we should do is to enable Testnet mode on Core. To do that, go to **Settings** and click on **Advanced**. - -![Settings image 1](/images/erc1.png) - -Here, turn on the **Testnet Mode** feature. This will automatically make Core switch to Fuji Testnet. - -![Settings image 2](/images/erc2.png) - - -If you are using other wallets, like MetaMask, you can add the Fuji Testnet using the following specs: - -- **Network Name**: Avalanche C-Chain -- **New RPC URL**: https://api.avax-test.network/ext/bc/C/rpc -- **ChainID**: `43113` -- **Symbol**: AVAX -- **Explorer**: https://testnet.snowtrace.io - - -The setup is done. For now, we have 0 AVAX. - -## Fund Your C-Chain Address - -**Option 1 (Recommended):** Create a [Builder Hub account](https://build.avax.network/login) and connect your wallet to receive testnet AVAX automatically. - -**Option 2:** Use the [Avalanche Faucet](https://core.app/tools/testnet-faucet/). If you already have an AVAX balance greater than zero on Mainnet, paste your C-Chain address there, and request test tokens. Otherwise, please request a faucet coupon on [Guild](https://guild.xyz/avalanche). Admins and mods on the official [Discord](https://discord.com/invite/RwXY7P6) can provide testnet AVAX if developers are unable to obtain it from the other options. - -## Create Mintable Token - -Now, we can create our mintable token on Remix. Open Remix on your browser or go to [this link](https://remix.ethereum.org/#optimize=false&evmVersion=null&version=soljson-v0.8.29+commit.ab55807c.js). - -![Image for post](/images/erc3.png) - -You should view this page. On this page, first, click the "Create new file" button. When you click the New File button, you have to choose a name. - -Since we will use an ERC-20 contract from [OpenZeppelin](https://openzeppelin.com/contracts/), just paste this line to the file and save. - -```solidity -import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v4.9/contracts/token/ERC20/presets/ERC20PresetMinterPauser.sol"; -``` - -![Image for post](/images/erc4.png) - -After saving the file, we will see a bunch of files that are imported to remix. This is a remix feature that allows us to import a GitHub contract repository to remix by just giving the URL-link with an import statement. - -![Image for post](/images/erc5.png) - -We have ERC20PresetMinterPauser.sol file in the presets. This file is written by OpenZeppelin according to ERC20 standards with minter functionality. After deploying this file, we will be the owner of the contract and thus have the authority and ability to mint the tokens. - -![Image for post](/images/erc6.png) - -## Deploy the Contract - -Open the tab with label `Solidity compiler` and select the solidity version that matches with the solidity version written in file as `pragma solidity …..`. The version should be equal to or higher than the file's version. For example, in my file, `pragma solidity ^0.8.0` is written so the required version is 0.8.0 or higher. As shown, in the compiler the solidity version is 0.8.29, which is OK. After checking the solidity version click the compile button. If you did not change anything in the file, or the solidity version is not wrong, the contract should compile without any errors. - -![Image for post](/images/erc7.png) - -Then, let's jump to the tab with label `Deploy & run transactions`. Here before deploying our contract, we should change the environment. Click to the environment and select "Injected Web3." If a pop-up shows up and asks you to connect the account, click to connect. After, you should see the account address in the "ACCOUNT" text box. - -The last thing before the deployment process is to set the contract that will be deployed as a token. Above the Deploy Button, there is a drop-down menu to select a contract. Select the contract named `ERC20PresetMinterPauser.sol`. - -![Image for post](/images/erc8.png) - -Now, here enter the name and symbol of your token. I will name it "test" and the symbol will be `tst`. You can give it a and click to transact button. - -![Image for post](/images/erc9.png) - -After clicking the button, a pop-up will show up and just confirm it. - -![Core confirmation](/images/erc10.png) - -And then another pop-up, a Core confirmation, appears. Confirm it. - -After confirming all these pop-ups we have deployed our token to avalanche C-Chain. So we can start to interact with it. - -## Interact with Token - -We can see our transaction that deployed on avalanche C-Chain via this [c-chain explorer](https://testnet.snowtrace.io/). - -But firstly, let's see our transaction hash from the remix console. - -![Image for post](/images/erc11.png) - -After deploying the contract, we should see a log in remix console. When you click to arrow and expand it, a transaction hash will come up. Copy it. - -![Image for post](/images/erc12.png) - -Just paste the transaction hash to the [explorer](https://testnet.snowtrace.io/) I shared above and press enter. - -![Image for post](/images/erc13.png) - -Here we can see all details about the transaction and token contract. - -![Image for post](/images/erc14.png) - -The first one is my wallet address that creates token and the second address is my token contract address which is named `test`. Now, let's mint some token to our own address. - -![Image for post](/images/erc15.png) - -Come back to the remix and after deploying, you should be able to see the contract in "Deployed Contracts" section. - -Here, we have a bunch of functions that we can use to interact with our token contract. You can check all these methods from OpenZeppelin documentation to learn how to use them. But we will only use the mint method. - -Click to arrow beside the mint method to read it. - -![Image for post](/images/erc16.png) - -Enter your address and an amount in wei. For example, I will mint 1000 `tst` token so, I entered "1000000000000000000000" - -## Add Token to Core Wallet - -Now we minted 1000 token to our contract, but you should not be able to see the tokens in your Core wallet. In order to see our own token, we have to add it. On Core, click on the Avalanche C-Chain, and then select Manage: - -![Add token 1](/images/erc17.png) - -![Add token 2](/images/erc18.png) - -Click on Add custom token. Here,enter the token address that you can see from the explorer, as showed above. Copy and paste it here. Then click on the Add token button, you should see 1000 token that you named in your Core wallet. Also, you can send it to another account via either remix or Core. - -![Add token 3](/images/erc19.png) diff --git a/content/docs/dapps/smart-contract-dev/get-test-funds.mdx b/content/docs/dapps/smart-contract-dev/get-test-funds.mdx deleted file mode 100644 index 0d0cbf2b93b..00000000000 --- a/content/docs/dapps/smart-contract-dev/get-test-funds.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Get Test Funds -description: Learn how to get test funds for Avalanche from Faucet. ---- - -## Automated Testnet Tokens (Recommended) - -The easiest way to get testnet AVAX is through [Builder Hub](https://build.avax.network/): - -1. **[Create a Builder Hub account](https://build.avax.network/login)** (free) -2. **Connect your Core wallet** to Builder Hub -3. **Tokens are automatically sent** to your wallet on C-Chain, P-Chain, and supported L1s - -No coupon codes, no manual claims - just connect and go! This automated drip system ensures you always have enough testnet tokens for development. - -## Alternative: External Faucet - -If you prefer not to create a Builder Hub account, you can use the [Fuji Testnet Faucet](https://core.app/tools/testnet-faucet/). (This testnet AVAX has no value.) - -Paste your address into the [Fuji faucet website](https://core.app/tools/testnet-faucet/): - -![Requesting AVAX](/images/test-fund1.png) - -If you already have an AVAX balance greater than zero on Mainnet, paste your C-Chain address there, and request test tokens. The faucet will send some AVAX to the address and return a transaction ID (txID). - -![Requesting AVAX](/images/test-fund2.png) - -Otherwise, please request a faucet coupon on [Guild](https://guild.xyz/avalanche). Admins and mods on the official [Discord](https://discord.com/invite/RwXY7P6) can provide testnet AVAX if developers are unable to obtain it from the other options. - -![Requesting Coupon](/images/test-fund3.png) - diff --git a/content/docs/dapps/smart-contract-dev/interact-golang-app.mdx b/content/docs/dapps/smart-contract-dev/interact-golang-app.mdx deleted file mode 100644 index d5ea9e195d0..00000000000 --- a/content/docs/dapps/smart-contract-dev/interact-golang-app.mdx +++ /dev/null @@ -1,173 +0,0 @@ ---- -title: Interact from Golang App -description: Interact with a smart contract from your Golang-based application. ---- - -`abigen` is a tool provided by the Go Ethereum (Geth) client that generates Go bindings for Solidity smart contracts. Developers would need to use Abigen when they want to interact with a smart contract written in Solidity from a Go programming language application. It enables developers to easily call functions and access data from Solidity contracts in a Go application. This tutorial demonstrates how to compile a solidity contract into Golang to deploy and call contracts programmatically. - -## How to Build - -Download the solidity compiler from [solc-bin](https://github.com/ethereum/solc-bin). - -Copy the appropriate compiler into your current path. ~/bin/ is a common path in most Linux distributions. - -```bash -cp linux-amd64/solc-linux-amd64-v0.8.9+commit.e5eed63a ~/bin -``` - -Ensure solc is properly installed by checking its version. - -```bash -solc --version -``` - -Clone Coreth and Build Abigen. - -```bash -git clone [email protected]:ava-labs/coreth.git -cd coreth/ -go build -o abigen cmd/abigen/*.go -cp abigen ~/bin -``` - -Compile a contract. - -```bash -abigen --sol counter.sol --pkg main --out counter.go -``` - -This will produce `counter.go` suitable to interact with contract. - -## Example Code - -Setup the connection to `avalanchego`, then deploy, call, and fetch values from the contract. - -Abigen offers more features for complicated contracts, the following is provided as an example to get started using the basic contract - -```solidity -package main - -import ( - "context" - "log" - "math/big" - "strings" - "time" - - "github.com/ava-labs/avalanchego/utils/constants" - "github.com/ava-labs/avalanchego/utils/formatting" - "github.com/ava-labs/coreth/accounts/abi/bind" - "github.com/ava-labs/coreth/core/types" - "github.com/ava-labs/coreth/ethclient" - "github.com/ava-labs/coreth/params" - "github.com/ava-labs/coreth/rpc" - "github.com/decred/dcrd/dcrec/secp256k1/v3" - "github.com/ethereum/go-ethereum/common" - "github.com/ethereum/go-ethereum/crypto" -) - -func main() { - // setup client - rc, err := rpc.Dial("http://localhost:9650/ext/bc/C/rpc") - if err != nil { - log.Fatal(err) - } - ec := ethclient.NewClient(rc) - - ctx := context.Background() - - // fetch networkid - networkId, err := ec.ChainID(ctx) - if err != nil { - log.Fatal(err) - } - - // parse key - privateKeyString := "PrivateKey-ewoqjP7PxY4yr3iLTpLisriqt94hdyDFNgchSxGGztUrTXtNN" - privateKeyBytes, err := formatting.Decode(formatting.CB58, strings.TrimPrefix(privateKeyString, constants.SecretKeyPrefix)) - if err != nil { - log.Fatal(err) - } - privateKey := secp256k1.PrivKeyFromBytes(privateKeyBytes) - privateKeyECDSA := privateKey.ToECDSA() - - // derive 'c' address - cAddress := crypto.PubkeyToAddress(privateKeyECDSA.PublicKey) - - // setup signer and transaction options. - signer := types.LatestSignerForChainID(networkId) - to := &bind.TransactOpts{ - Signer: func(address common.Address, transaction *types.Transaction) (*types.Transaction, error) { - return types.SignTx(transaction, signer, privateKeyECDSA) - }, - From: cAddress, - Context: ctx, - GasLimit: params.ApricotPhase1GasLimit, - } - - // deploy the contract - storageAddress, storageTransaction, storageContract, err := DeployStorage(to, ec) - if err != nil { - log.Fatal(err) - } - - // wait for the transaction to be accepted - for { - r, err := ec.TransactionReceipt(ctx, storageTransaction.Hash()) - if err != nil { - if err.Error() != "not found" { - log.Fatal(err) - } - time.Sleep(1 * time.Second) - continue - } - if r.Status != 0 { - break - } - time.Sleep(1 * time.Second) - } - - log.Println("storageAddress", storageAddress) - log.Println("storageTransaction", storageTransaction) - - // Call store on the contract - storeTransaction, err := storageContract.Store(to, big.NewInt(1), common.BytesToAddress([]byte("addr1"))) - if err != nil { - log.Fatal(err) - } - - // wait for the transaction - for { - r, err := ec.TransactionReceipt(ctx, storeTransaction.Hash()) - if err != nil { - if err.Error() != "not found" { - log.Fatal(err) - } - time.Sleep(1 * time.Second) - continue - } - if r.Status != 0 { - break - } - time.Sleep(1 * time.Second) - } - - log.Println("storeTransaction", storeTransaction) - - // setup call options for storage - co := &bind.CallOpts{ - Accepted: true, - Context: ctx, - From: storageAddress, - } - - // retrieve the value of the contract - storageValue, err := storageContract.Retrieve(co) - if err != nil { - log.Fatal(err) - } - - log.Println("storageValue", storageValue) -} -``` - diff --git a/content/docs/nodes/meta.json b/content/docs/nodes/meta.json index 65d5b27d2d4..dd358a3c510 100644 --- a/content/docs/nodes/meta.json +++ b/content/docs/nodes/meta.json @@ -18,10 +18,6 @@ "configure/configs-flags", "chain-configs", "configure/avalanche-l1-configs", - "---Validate---", - "validate/validate-vs-delegate", - "validate/how-to-stake", - "validate/node-validator", "---Maintain---", "...maintain" ] diff --git a/content/docs/quick-start/avalanche-consensus.mdx b/content/docs/primary-network/avalanche-consensus.mdx similarity index 80% rename from content/docs/quick-start/avalanche-consensus.mdx rename to content/docs/primary-network/avalanche-consensus.mdx index 396119ab037..fb9c3c319ee 100644 --- a/content/docs/quick-start/avalanche-consensus.mdx +++ b/content/docs/primary-network/avalanche-consensus.mdx @@ -1,22 +1,22 @@ --- -title: Avalanche Consensus -description: Learn about the groundbreaking Avalanche Consensus algorithms. +title: Snowman Consensus +description: Learn about the Snowman Consensus protocol. --- Consensus is the task of getting a group of computers (a.k.a. nodes) to come to an agreement on a decision. In blockchain, this means that all the participants in a network have to agree on the changes made to the shared ledger. This agreement is reached through a specific process, a consensus protocol, that ensures that everyone sees the same information and that the information is accurate and trustworthy. -## Avalanche Consensus +## Snowman Consensus -Avalanche Consensus is a consensus protocol that is scalable, robust, and decentralized. It combines features of both classical and Nakamoto consensus mechanisms to achieve high throughput, fast finality, and energy efficiency. For the whitepaper, see [here](https://www.avalabs.org/whitepapers). +Snowman Consensus is a consensus protocol that is scalable, robust, and decentralized. It combines features of both classical and Nakamoto consensus mechanisms to achieve high throughput, fast finality, and energy efficiency. For the whitepaper, see [here](https://www.avalabs.org/whitepapers). Key Features Include: -- Speed: Avalanche consensus provides sub-second, immutable finality, ensuring that transactions are quickly confirmed and irreversible. -- Scalability: Avalanche consensus enables high network throughput while ensuring low latency. -- Energy Efficiency: Unlike other popular consensus protocols, participation in Avalanche consensus is neither computationally intensive nor expensive. -- Adaptive Security: Avalanche consensus is designed to resist various attacks, including sybil attacks, distributed denial-of-service (DDoS) attacks, and collusion attacks. Its probabilistic nature ensures that the consensus outcome converges to the desired state, even when the network is under attack. +- Speed: Snowman Consensus provides sub-second, immutable finality, ensuring that transactions are quickly confirmed and irreversible. +- Scalability: Snowman Consensus enables high network throughput while ensuring low latency. +- Energy Efficiency: Unlike other popular consensus protocols, participation in Snowman Consensus is neither computationally intensive nor expensive. +- Adaptive Security: Snowman Consensus is designed to resist various attacks, including sybil attacks, distributed denial-of-service (DDoS) attacks, and collusion attacks. Its probabilistic nature ensures that the consensus outcome converges to the desired state, even when the network is under attack. ## Conceptual Overview @@ -38,15 +38,15 @@ The node repeats this sampling process until the validators queried reply with t When a transaction has no conflicts, finalization happens very quickly. When conflicts exist, honest validators quickly cluster around conflicting transactions, entering a positive feedback loop until all correct validators prefer that transaction. This leads to the acceptance of non-conflicting transactions and the rejection of conflicting transactions. -![How Avalanche Consensus Works](/images/avalanche-consensus1.png) +![How Snowman Consensus Works](/images/avalanche-consensus1.png) -Avalanche Consensus guarantees that if any honest validator accepts a transaction, all honest validators will come to the same conclusion. +Snowman Consensus guarantees that if any honest validator accepts a transaction, all honest validators will come to the same conclusion. For a great visualization, check out [this demo](https://tedyin.com/archive/snow-bft-demo/#/snow). -## Deep Dive Into Avalanche Consensus +## Deep Dive Into Snowman Consensus @@ -60,7 +60,7 @@ Everyone repeats this process. Each round, more and more people have the same pr ### Snowball -The intuition above outlines the Snowball Algorithm, which is a building block of Avalanche consensus. Let's review the Snowball algorithm. +The intuition above outlines the Snowball Algorithm, which is a building block of Snowman Consensus. Let's review the Snowball algorithm. #### Parameters @@ -104,7 +104,7 @@ These values, which are constants, are quite small on the Avalanche Network. The Snowball is very scalable as the number of nodes on the network, _n_, increases. Regardless of the number of participants in the network, the number of consensus messages sent remains the same because in a given query, a node only queries `20` nodes, even if there are thousands of nodes in the network. -Everything discussed to this point is how Avalanche is described in [the Avalanche white-paper](https://assets-global.website-files.com/5d80307810123f5ffbb34d6e/6009805681b416f34dcae012_Avalanche%20Consensus%20Whitepaper.pdf). The implementation of the Avalanche consensus protocol by Ava Labs (namely in AvalancheGo) has some optimizations for latency and throughput. +Everything discussed to this point is how Avalanche is described in [the Avalanche white-paper](https://assets-global.website-files.com/5d80307810123f5ffbb34d6e/6009805681b416f34dcae012_Avalanche%20Consensus%20Whitepaper.pdf). The implementation of the Snowman Consensus protocol by Ava Labs (namely in AvalancheGo) has some optimizations for latency and throughput. ### Blocks @@ -116,7 +116,7 @@ If a node receives a vote for a block, it also counts as a vote for all of the b ### Finality -Avalanche consensus is probabilistically safe up to a safety threshold. That is, the probability that a correct node accepts a transaction that another correct node rejects can be made arbitrarily low by adjusting system parameters. In Nakamoto consensus protocol (as used in Bitcoin and Ethereum, for example), a block may be included in the chain but then be removed and not end up in the canonical chain. This means waiting an hour for transaction settlement. In Avalanche, acceptance/rejection are **final and irreversible** and only take a few seconds. +Snowman Consensus is probabilistically safe up to a safety threshold. That is, the probability that a correct node accepts a transaction that another correct node rejects can be made arbitrarily low by adjusting system parameters. In Nakamoto consensus protocol (as used in Bitcoin and Ethereum, for example), a block may be included in the chain but then be removed and not end up in the canonical chain. This means waiting an hour for transaction settlement. In Avalanche, acceptance/rejection are **final and irreversible** and only take a few seconds. ### Optimizations @@ -150,9 +150,9 @@ Transactions are created by users which call an API on an [AvalancheGo](https:// Conflicting transactions are not guaranteed to be live. That's not really a problem because if you want your transaction to be live then you should not issue a conflicting transaction. -Snowman is the name of Ava Labs' implementation of the Avalanche consensus protocol for linear chains. +Snowman is the name of Ava Labs' implementation of the Snowman Consensus protocol for linear chains. -If there are no undecided transactions, the Avalanche consensus protocol _quiesces_. That is, it does nothing if there is no work to be done. This makes Avalanche more sustainable than Proof-of-work where nodes need to constantly do work. +If there are no undecided transactions, the Snowman Consensus protocol _quiesces_. That is, it does nothing if there is no work to be done. This makes Avalanche more sustainable than Proof-of-work where nodes need to constantly do work. Avalanche has no leader. Any node can propose a transaction and any node that has staked AVAX can vote on every transaction, which makes the network more robust and decentralized. @@ -160,13 +160,13 @@ Avalanche has no leader. Any node can propose a transaction and any node that ha Avalanche is a general consensus engine. It doesn't matter what type of application is put on top of it. The protocol allows the decoupling of the application layer from the consensus layer. If you're building a dapp on Avalanche then you just need to define a few things, like how conflicts are defined and what is in a transaction. You don't need to worry about how nodes come to an agreement. The consensus protocol is a black box that put something into it and it comes back as accepted or rejected. -Avalanche can be used for all kinds of applications, not just P2P payment networks. Avalanche's Primary Network has an instance of the Ethereum Virtual Machine, which is backward compatible with existing Ethereum Dapps and dev tooling. The Ethereum consensus protocol has been replaced with Avalanche consensus to enable lower block latency and higher throughput. +Avalanche can be used for all kinds of applications, not just P2P payment networks. Avalanche's Primary Network has an instance of the Ethereum Virtual Machine, which is backward compatible with existing Ethereum Dapps and dev tooling. The Ethereum consensus protocol has been replaced with Snowman Consensus to enable lower block latency and higher throughput. Avalanche is very performant. It can process thousands of transactions per second with one to two second acceptance latency. ## Summary -Avalanche consensus is a radical breakthrough in distributed systems. It represents as large a leap forward as the classical and Nakamoto consensus protocols that came before it. Now that you have a better understanding of how it works, check out other documentations for building game-changing Dapps and financial instruments on Avalanche. +Snowman Consensus is a radical breakthrough in distributed systems. It represents as large a leap forward as the classical and Nakamoto consensus protocols that came before it. Now that you have a better understanding of how it works, check out other documentations for building game-changing Dapps and financial instruments on Avalanche. diff --git a/content/docs/quick-start/avax-token.mdx b/content/docs/primary-network/avax-token.mdx similarity index 100% rename from content/docs/quick-start/avax-token.mdx rename to content/docs/primary-network/avax-token.mdx diff --git a/content/docs/primary-network/index.mdx b/content/docs/primary-network/index.mdx new file mode 100644 index 00000000000..89ad2b6d690 --- /dev/null +++ b/content/docs/primary-network/index.mdx @@ -0,0 +1,93 @@ +--- +title: Primary Network +description: Learn about the Avalanche Primary Network and its three blockchains. +--- + +🏔️ Primary Network"] + + PN ==> XC["🔄 Exchange (X) Chain
━━━━━━━━━━━━━━━
Snowman Consensus Protocol"] + PN ==> PC["⚙️ Platform (P) Chain
━━━━━━━━━━━━━━━
Snowman Consensus Protocol"] + PN ==> CC["📝 Contract (C) Chain
━━━━━━━━━━━━━━━
Snowman Consensus Protocol"] + + XC --> XF1["Creates Assets"] + XC --> XF2["Exchanges Assets"] + + PC --> PF1["Coordinates Validators"] + PC --> PF2["Creates Subnets / Layer 1s"] + + CC --> CF1["Executes EVM Contracts"] + CC --> CF2["Smart Contracts"] + + XF1 -.-> A1["👤 Asset 1"] + XF1 -.-> A2["🏠 Asset 2"] + XF2 -.-> AV["⚡ AVAX"] + + PF2 -.-> C1["⛓️ Custom Chain 1"] + PF2 -.-> C2["⛓️ Custom Chain 2"] + + CF2 -.-> N1["🖼️ NFT"] + CF2 -.-> E1["🪙 ERC20"] + CF2 -.-> D1["🚀 DAPP"] + + style PN fill:#e74c3c,stroke:#c0392b,stroke-width:4px,color:#fff,rx:15,ry:15 + style XC fill:#3498db,stroke:#2980b9,stroke-width:3px,color:#fff,rx:10,ry:10 + style PC fill:#9b59b6,stroke:#8e44ad,stroke-width:3px,color:#fff,rx:10,ry:10 + style CC fill:#16a085,stroke:#138d75,stroke-width:3px,color:#fff,rx:10,ry:10 + + style XF1 fill:#5dade2,stroke:#3498db,stroke-width:2px,color:#fff,rx:8,ry:8 + style XF2 fill:#5dade2,stroke:#3498db,stroke-width:2px,color:#fff,rx:8,ry:8 + style PF1 fill:#bb8fce,stroke:#9b59b6,stroke-width:2px,color:#fff,rx:8,ry:8 + style PF2 fill:#bb8fce,stroke:#9b59b6,stroke-width:2px,color:#fff,rx:8,ry:8 + style CF1 fill:#52be80,stroke:#16a085,stroke-width:2px,color:#fff,rx:8,ry:8 + style CF2 fill:#52be80,stroke:#16a085,stroke-width:2px,color:#fff,rx:8,ry:8 + + style A1 fill:#85c1e9,stroke:#5dade2,stroke-width:1px,color:#2c3e50,rx:5,ry:5 + style A2 fill:#85c1e9,stroke:#5dade2,stroke-width:1px,color:#2c3e50,rx:5,ry:5 + style AV fill:#85c1e9,stroke:#5dade2,stroke-width:1px,color:#2c3e50,rx:5,ry:5 + style C1 fill:#d7bde2,stroke:#bb8fce,stroke-width:1px,color:#2c3e50,rx:5,ry:5 + style C2 fill:#d7bde2,stroke:#bb8fce,stroke-width:1px,color:#2c3e50,rx:5,ry:5 + style N1 fill:#a3e4d7,stroke:#52be80,stroke-width:1px,color:#2c3e50,rx:5,ry:5 + style E1 fill:#a3e4d7,stroke:#52be80,stroke-width:1px,color:#2c3e50,rx:5,ry:5 + style D1 fill:#a3e4d7,stroke:#52be80,stroke-width:1px,color:#2c3e50,rx:5,ry:5 +`} /> + +
+Avalanche is a heterogeneous network of blockchains. As opposed to homogeneous networks, where all applications reside in the same chain, heterogeneous networks allow separate chains to be created for different applications. + +The Primary Network is a special [Avalanche L1](/docs/quick-start/avalanche-l1s) that runs three blockchains: + +- The Platform Chain [(P-Chain)](/docs/quick-start/primary-network#p-chain) +- The Contract Chain [(C-Chain)](/docs/quick-start/primary-network#c-chain) +- The Exchange Chain [(X-Chain)](/docs/quick-start/primary-network#x-chain) + + +[Avalanche Mainnet](/docs/quick-start/networks/mainnet) is comprised of the Primary Network and all deployed Avalanche L1s. + + +A node can become a validator for the Primary Network by staking at least **2,000 AVAX**. + +## The Chains + +All validators of the Primary Network are required to validate and secure the following: + +### C-Chain + +The **C-Chain** is an implementation of the Ethereum Virtual Machine (EVM). The [C-Chain's API](/docs/api-reference/c-chain/api) supports Geth's API and supports the deployment and execution of smart contracts written in Solidity. + +The C-Chain is an instance of the [Coreth](https://github.com/ava-labs/coreth) Virtual Machine. + +### P-Chain + +The **P-Chain** is responsible for all validator and Avalanche L1-level operations. The [P-Chain API](/docs/api-reference/p-chain/api) supports the creation of new blockchains and Avalanche L1s, the addition of validators to Avalanche L1s, staking operations, and other platform-level operations. + +The P-Chain is an instance of the Platform Virtual Machine. + +### X-Chain + +The **X-Chain** is responsible for operations on digital smart assets known as **Avalanche Native Tokens**. A smart asset is a representation of a real-world resource (for example, equity, or a bond) with sets of rules that govern its behavior, like "can't be traded until tomorrow." The [X-Chain API](/docs/api-reference/x-chain/api) supports the creation and trade of Avalanche Native Tokens. + +One asset traded on the X-Chain is AVAX. When you issue a transaction to a blockchain on Avalanche, you pay a fee denominated in AVAX. + +The X-Chain is an instance of the Avalanche Virtual Machine (AVM). diff --git a/content/docs/primary-network/meta.json b/content/docs/primary-network/meta.json new file mode 100644 index 00000000000..68f7b39e6b4 --- /dev/null +++ b/content/docs/primary-network/meta.json @@ -0,0 +1,18 @@ +{ + "title": "Primary Network", + "description": "Learn about the Avalanche Primary Network and its three blockchains", + "icon": "Network", + "root": true, + "pages": [ + "index", + "avalanche-consensus", + "avax-token", + "virtual-machines", + "---Validate---", + "validate/rewards-formula", + "validate/validate-vs-delegate", + "validate/how-to-stake", + "validate/node-validator" + ] +} + diff --git a/content/docs/nodes/validate/how-to-stake.mdx b/content/docs/primary-network/validate/how-to-stake.mdx similarity index 100% rename from content/docs/nodes/validate/how-to-stake.mdx rename to content/docs/primary-network/validate/how-to-stake.mdx diff --git a/content/docs/nodes/validate/node-validator.mdx b/content/docs/primary-network/validate/node-validator.mdx similarity index 100% rename from content/docs/nodes/validate/node-validator.mdx rename to content/docs/primary-network/validate/node-validator.mdx diff --git a/content/docs/quick-start/rewards-formula.mdx b/content/docs/primary-network/validate/rewards-formula.mdx similarity index 100% rename from content/docs/quick-start/rewards-formula.mdx rename to content/docs/primary-network/validate/rewards-formula.mdx diff --git a/content/docs/nodes/validate/validate-vs-delegate.mdx b/content/docs/primary-network/validate/validate-vs-delegate.mdx similarity index 100% rename from content/docs/nodes/validate/validate-vs-delegate.mdx rename to content/docs/primary-network/validate/validate-vs-delegate.mdx diff --git a/content/docs/nodes/validate/what-is-staking.mdx b/content/docs/primary-network/validate/what-is-staking.mdx similarity index 100% rename from content/docs/nodes/validate/what-is-staking.mdx rename to content/docs/primary-network/validate/what-is-staking.mdx diff --git a/content/docs/quick-start/virtual-machines.mdx b/content/docs/primary-network/virtual-machines.mdx similarity index 100% rename from content/docs/quick-start/virtual-machines.mdx rename to content/docs/primary-network/virtual-machines.mdx diff --git a/content/docs/quick-start/avalanche-community-proposals.mdx b/content/docs/quick-start/avalanche-community-proposals.mdx deleted file mode 100644 index 3dcd856b6a3..00000000000 --- a/content/docs/quick-start/avalanche-community-proposals.mdx +++ /dev/null @@ -1,103 +0,0 @@ ---- -title: Avalanche Community Proposals -description: Learn about community proposals and how to create them. ---- - -An Avalanche Community Proposal is a concise document that introduces a change or best practice for adoption on the [Avalanche Network](https://www.avax.network/). ACPs should provide clear technical specifications of any proposals and a compelling rationale for their adoption. - -ACPs are an open framework for proposing improvements and gathering consensus around changes to the Avalanche Network. ACPs can be proposed by anyone and will be merged into this repository as long as they are well-formatted and coherent. Once an overwhelming majority of the Avalanche Network/Community have [signaled their support for an ACP](/docs/nodes/configure/configs-flags#avalanche-community-proposals), it may be scheduled for activation on the Avalanche Network by Avalanche Network Clients (ANCs). It is ultimately up to members of the Avalanche Network/Community to adopt ACPs they support by running a compatible ANC, such as [AvalancheGo](https://github.com/ava-labs/avalanchego). - -## ACP Tracks - -There are three kinds of ACP: - -- A `Standards Track` ACP describes a change to the design or function of the Avalanche Network, such as a change to the P2P networking protocol, P-Chain design, Avalanche L1 architecture, or any change/addition that affects the interoperability of Avalanche Network Clients (ANCs). -- A `Best Practices Track` ACP describes a design pattern or common interface that should be used across the Avalanche Network to make it easier to integrate with Avalanche or for Avalanche L1s to interoperate with each other. This would include things like proposing a smart contract interface, not proposing a change to how smart contracts are executed. -- A `Meta Track` ACP describes a change to the ACP process or suggests a new way for the Avalanche Community to collaborate. -- A `Subnet Track` ACP describes a change to a particular Avalanche L1. This would include things like configuration changes or coordinated Layer 1 upgrades. - -## ACP Statuses - -There are four statuses of an ACP: - -- A `Proposed` ACP has been merged into the main branch of the ACP repository. It is actively being discussed by the Avalanche Community and may be modified based on feedback. -- An `Implementable` ACP is considered "ready for implementation" by the author and will no longer change meaningfully from its current form (which would require a new ACP). -- An `Activated` ACP has been activated on the Avalanche Network via a coordinated upgrade by the Avalanche Community. Once an ACP is `Activated`, it is locked. -- A `Stale` ACP has been abandoned by its author because it is not supported by the Avalanche Community or has been replaced with another ACP. - -## ACP Workflow - -### Step 0: Think of a Novel Improvement to Avalanche - -The ACP process begins with a new idea for Avalanche. Each potential ACP must have an author: someone who writes the ACP using the style and format described below, shepherds the associated GitHub Discussion, and attempts to build consensus around the idea. Note that ideas and any resulting ACP is public. Authors should not post any ideas or anything in an ACP that the Author wants to keep confidential or to keep ownership rights in (such as intellectual property rights). - -### Step 1: Post Your Idea to [GitHub Discussions](https://github.com/avalanche-foundation/ACPs/discussions/categories/ideas) - -The author should first attempt to ascertain whether there is support for their idea by posting in the "Ideas" category of GitHub Discussions. Vetting an idea publicly before going as far as writing an ACP is meant to save both the potential author and the wider Avalanche Community time. Asking the Avalanche Community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Small enhancements or patches often don't need standardization between multiple projects; these don't need an ACP and should be injected into the relevant development workflow with a patch submission to the applicable ANC issue tracker. - -### Step 2: Propose an ACP via [Pull Request](https://github.com/avalanche-foundation/ACPs/pulls) - -Once the author feels confident that an idea has a decent chance of acceptance, an ACP should be drafted and submitted as a pull request (PR). This draft must be written in ACP style as described below. It is highly recommended that a single ACP contain a single key proposal or new idea. The more focused the ACP, the more successful it tends to be. If in doubt, split your ACP into several well-focused ones. The PR number of the ACP will become its assigned number. - -### Step 3: Build Consensus on [GitHub Discussions](https://github.com/avalanche-foundation/ACPs/discussions/categories/discussion) and Provide an Implementation (if Applicable) - -ACPs will be merged by ACP maintainers if the proposal is generally well-formatted and coherent. ACP editors will attempt to merge anything worthy of discussion, regardless of feasibility or complexity, that is not a duplicate or incomplete. After an ACP is merged, an official GitHub Discussion will be opened for the ACP and linked to the proposal for community discussion. It is recommended for author or supportive Avalanche Community members to post an accompanying non-technical overview of their ACP for general consumption in this GitHub Discussion. The ACP should be reviewed and broadly supported before a reference implementation is started, again to avoid wasting the author and the Avalanche Community's time, unless a reference implementation will aid people in studying the ACP. - -### Step 4: Mark ACP as `Implementable` via [Pull Request](https://github.com/avalanche-foundation/ACPs/pulls) - -Once an ACP is considered complete by the author, it should be marked as `Implementable`. At this point, all open questions should be addressed and an associated reference implementation should be provided (if applicable). As mentioned earlier, the Avalanche Foundation meets periodically to recommend the ratification of specific ACPs but it is ultimately up to members of the Avalanche Network/Community to adopt ACPs they support by running a compatible Avalanche Network Client (ANC), such as [AvalancheGo](https://github.com/ava-labs/avalanchego). - -### [Optional] Step 5: Mark ACP as `Stale` via [Pull Request](https://github.com/avalanche-foundation/ACPs/pulls) - -An ACP can be superseded by a different ACP, rendering the original obsolete. If this occurs, the original ACP will be marked as `Stale`. ACPs may also be marked as `Stale` if the author abandon work on it for a prolonged period of time (12+ months). ACPs may be reopened and moved back to `Proposed` if the author restart work. - -## What Belongs in a Successful ACP? - -Each ACP must have the following parts: - -- `Preamble`: Markdown table containing metadata about the ACP, including the ACP number, a short descriptive title, the author, and optionally the contact info for each author, etc. -- `Abstract`: Concise (~200 word) description of the ACP -- `Motivation`: Rationale for adopting the ACP and the specific issue/challenge/opportunity it addresses -- `Specification`: Complete description of the semantics of any change should allow any ANC/Avalanche Community member to implement the ACP -- `Security Considerations`: Security implications of the proposed ACP - -Each ACP can have the following parts: - -- `Open Questions`: Questions that should be resolved before implementation - -Each `Standards Track` ACP must have the following parts: - -- `Backwards Compatibility`: List of backwards incompatible changes required to implement the ACP and their impact on the Avalanche Community -- `Reference Implementation`: Code, documentation, and telemetry (from a local network) of the ACP change - -Each `Best Practices Track` ACP can have the following parts: - -- `Backwards Compatibility`: List of backwards incompatible changes required to implement the ACP and their impact on the Avalanche Community -- `Reference Implementation`: Code, documentation, and telemetry (from a local network) of the ACP change - -### ACP Formats and Templates - -Each ACP is allocated a unique subdirectory in the `ACPs` directory. The name of this subdirectory must be of the form `N-T` where `N` is the ACP number and `T` is the ACP title with any spaces replaced by hyphens. ACPs must be written in [markdown](https://daringfireball.net/projects/markdown/syntax) format and stored at `ACPs/N-T/README.md`. Please see the [ACP template](https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/TEMPLATE.md) for an example of the correct layout. - -### Auxiliary Files - -ACPs may include auxiliary files such as diagrams or code snippets. Such files should be stored in the ACP's subdirectory (`ACPs/N-T/*`). There is no required naming convention for auxiliary files. - -### Waived Copyright - -ACP authors must waive any copyright claims before an ACP will be merged into the repository. This can be done by including the following text in an ACP: - -``` -## Copyright -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -``` - -## Contributing - -Before contributing to ACPs, please read the [ACP Terms of Contribution](https://github.com/avalanche-foundation/ACPs/blob/main/CONTRIBUTING.md). - - - - - - diff --git a/content/docs/quick-start/avalanche-l1s.mdx b/content/docs/quick-start/avalanche-l1s.mdx deleted file mode 100644 index d5d2891056a..00000000000 --- a/content/docs/quick-start/avalanche-l1s.mdx +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: Avalanche L1s -description: Explore the multi-chain architecture of Avalanche ecosystem. ---- - -An Avalanche L1 is a sovereign network which defines its own rules regarding its membership and token economics. It is composed of a dynamic subset of Avalanche validators working together to achieve consensus on the state of one or more blockchains. Each blockchain is validated by exactly one Avalanche L1, while an Avalanche L1 can validate many blockchains. - -Avalanche's [Primary Network](/docs/quick-start/primary-network) is a special Avalanche L1 running three blockchains: - -- The Platform Chain [(P-Chain)](/docs/quick-start/primary-network#p-chain) -- The Contract Chain [(C-Chain)](/docs/quick-start/primary-network#c-chain) -- The Exchange Chain [(X-Chain)](/docs/quick-start/primary-network#x-chain) - -![image](/images/subnet1.png) - - -Every validator of an Avalanche L1 **must** sync the P-Chain of the Primary Network for interoperability. - - -Node operators that validate an Avalanche L1 with multiple chains do not need to run multiple machines for validation. For example, the Primary Network is an Avalanche L1 with three coexisting chains, all of which can be validated by a single node, or a single machine. - -## Advantages - -### Independent Networks - -- Avalanche L1s use virtual machines to specify their own execution logic, determine their own fee regime, maintain their own state, facilitate their own networking, and provide their own security. -- Each Avalanche L1's performance is isolated from other Avalanche L1s in the ecosystem, so increased usage on one Avalanche L1 won't affect another. -- Avalanche L1s can have their own token economics with their own native tokens, fee markets, and incentives determined by the Avalanche L1 deployer. -- One Avalanche L1 can host multiple blockchains with customized [virtual machines](/docs/quick-start/virtual-machines). - -### Native Interoperability - -Avalanche Warp Messaging enables native cross-Avalanche L1 communication and allows Virtual Machine (VM) developers to implement arbitrary communication protocols between any two Avalanche L1s. - -### Accommodate App-Specific Requirements - -Different blockchain-based applications may require validators to have certain properties such as large amounts of RAM or CPU power. - -an Avalanche L1 could require that validators meet certain [hardware requirements](/docs/nodes/system-requirements#hardware-and-operating-systems) so that the application doesn't suffer from low performance due to slow validators. - -### Launch Networks Designed With Compliance - -Avalanche's L1 architecture makes regulatory compliance manageable. As mentioned above, an Avalanche L1 may require validators to meet a set of requirements. - -Some examples of requirements the creators of an Avalanche L1 may choose include: - -- Validators must be located in a given country. -- Validators must pass KYC/AML checks. -- Validators must hold a certain license. - -### Control Privacy of On-Chain Data - -Avalanche L1s are ideal for organizations interested in keeping their information private. - -Institutions conscious of their stakeholders' privacy can create a private Avalanche L1 where the contents of the blockchains would be visible only to a set of pre-approved validators. - -Define this at creation with a [single parameter](/docs/nodes/configure/avalanche-l1-configs#private-avalanche-l1). - -### Validator Sovereignty - -In a heterogeneous network of blockchains, some validators will not want to validate certain blockchains because they simply have no interest in those blockchains. - -The Avalanche L1 model enables validators to concern themselves only with blockchain networks they choose to participate in. This greatly reduces the computational burden on validators. - -## Develop Your Own Avalanche L1 - -Avalanche L1s on Avalanche are deployed by default with [Subnet-EVM](https://github.com/ava-labs/subnet-evm#subnet-evm), a fork of go-ethereum. It implements the Ethereum Virtual Machine and supports Solidity smart contracts as well as most other Ethereum client functionality. - -To get started, check out our [L1 Toolbox](/tools/l1-toolbox) or the tutorials in the [Avalanche CLI](/docs/tooling/create-avalanche-l1) section. diff --git a/content/docs/quick-start/disclaimer.mdx b/content/docs/quick-start/disclaimer.mdx deleted file mode 100644 index ba83c7a818e..00000000000 --- a/content/docs/quick-start/disclaimer.mdx +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: Disclaimer ---- - -The Knowledge Base, including all the Help articles on this site, is provided for technical support purposes only, without representation, warranty or guarantee of any kind. - -Not an offer to sell or solicitation of an offer to buy any security or other regulated financial instrument. Not technical, investment, financial, accounting, tax, legal or other advice; please consult your own professionals. - -Please conduct your own research before connecting to or interacting with any dapp or third party or making any investment or financial decisions. - -MoonPay, ParaSwap and any other third party services or dapps you access are offered by third parties unaffiliated with us. - -Please review this [Notice](https://assets.website-files.com/602e8e4411398ca20cfcafd3/60ec9607c853cd466383f1ad_Important%20Notice%20-%20avalabs.org.pdf) and the [Terms of Use](https://core.app/terms/core). - - - - diff --git a/content/docs/quick-start/index.mdx b/content/docs/quick-start/index.mdx deleted file mode 100644 index bde4dbd7dfd..00000000000 --- a/content/docs/quick-start/index.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: Introduction -description: Learn about Avalanche Protocol and its unique features. ---- - -Avalanche is an open-source platform for building decentralized applications in one interoperable, decentralized, and highly scalable ecosystem. - -Powered by a uniquely powerful [consensus mechanism](/docs/quick-start/avalanche-consensus), Avalanche is the first ecosystem designed to accommodate the scale of global finance, with near-instant transaction finality. - -## Blazingly Fast - -Avalanche employs the fastest consensus mechanism of any Layer 1 blockchain. The unique consensus mechanism enables quick finality and low latency: in less than 2 seconds, your transaction is effectively processed and verified. - -## Built to Scale - -Developers who build on Avalanche can build application-specific blockchains with complex rulesets or build on existing private or public Avalanche L1s in any language. - -Avalanche is incredibly energy-efficient and can run easily on consumer-grade hardware. The entire Avalanche network consumes the same amount of energy as 46 US households, equivalent to 0.0005% of the amount of energy consumed by Bitcoin. - -Solidity developers can build on Avalanche's implementation of the EVM straight out-of-the box, or build their own custom Virtual Machine (VM) for advanced use cases. - -## Advanced Security - -Avalanche consensus scales to thousands of concurrent validators without suffering performance degradation making it one of the most secure protocols for internet scaling systems. - -Permissionless and permissioned custom blockchains deployed as an Avalanche L1s can include custom rulesets designed to be compliant with legal and jurisdictional considerations. - - - diff --git a/content/docs/quick-start/meta.json b/content/docs/quick-start/meta.json deleted file mode 100644 index 10b29b9e9e2..00000000000 --- a/content/docs/quick-start/meta.json +++ /dev/null @@ -1,23 +0,0 @@ -{ - "title": "Quick Start", - "description": "Learn about Avalanche", - "icon": "Sprout", - "root": true, - "pages": [ - "index", - "avalanche-consensus", - "avax-token", - "---Multi-chain Architecture---", - "avalanche-l1s", - "validator-manager", - "primary-network", - "rewards-formula", - "virtual-machines", - "---Networks---", - "networks/mainnet", - "networks/fuji-testnet", - "---Extras---", - "avalanche-community-proposals", - "disclaimer" - ] -} diff --git a/content/docs/quick-start/networks/fuji-testnet.mdx b/content/docs/quick-start/networks/fuji-testnet.mdx deleted file mode 100644 index 3e30d0b492c..00000000000 --- a/content/docs/quick-start/networks/fuji-testnet.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Fuji Testnet -description: Learn about the official Testnet for the Avalanche ecosystem. ---- - -Fuji's infrastructure imitates Avalanche Mainnet. It's comprised of a [Primary Network](/docs/quick-start/primary-network) formed by instances of X, P, and C-Chain, as well as many test Avalanche L1s. - -## When to Use Fuji - -Fuji provides users with a platform to simulate the conditions found in the Mainnet environment. It enables developers to deploy demo Smart Contracts, allowing them to test and refine their applications before deploying them on the [Primary Network](/docs/quick-start/primary-network). - -Users interested in experimenting with Avalanche can receive free testnet AVAX, allowing them to explore the platform without any risk. These testnet tokens have no value in the real world and are only meant for experimentation purposes within the Fuji test network. - -To receive testnet tokens, users can request funds from the [Avalanche Faucet](/docs/dapps/smart-contract-dev/get-test-funds). If there's already an AVAX balance greater than zero on Mainnet, paste the C-Chain address there, and request test tokens. Otherwise, please request a faucet coupon on [Guild](https://guild.xyz/avalanche). Admins and mods on the official [Discord](https://discord.com/invite/RwXY7P6) can provide testnet AVAX if developers are unable to obtain it from the other two options. - -## Add Avalanche C-Chain Testnet to Wallet - -- **Network Name**: Avalanche Fuji C-Chain -- **RPC URL**: https://api.avax-test.network/ext/bc/C/rpc -- **WebSocket URL**: wss://api.avax-test.network/ext/bc/C/ws -- **ChainID**: `43113` -- **Symbol**: `AVAX` -- **Explorer**: https://subnets-test.avax.network/c-chain - -Head over to explorer linked above and select "Add Avalanche C-Chain to Wallet" under "Chain Info" to automatically add the network. - -## Additional Details - -- Fuji Testnet has its own dedicated [block explorer](https://subnets-test.avax.network/). -- The Public API endpoint for Fuji is not the same as Mainnet. More info is available in the [Public API Server](/docs/tooling/rpc-providers) documentation. -- You can run a Fuji validator node by staking only **1 Fuji AVAX**. diff --git a/content/docs/quick-start/networks/mainnet.mdx b/content/docs/quick-start/networks/mainnet.mdx deleted file mode 100644 index 1c9be75d052..00000000000 --- a/content/docs/quick-start/networks/mainnet.mdx +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Avalanche Mainnet -description: Learn about the Avalanche Mainnet. ---- - -The Avalanche Mainnet refers to the main network of the Avalanche blockchain where real transactions and smart contract executions occur. It is the final and production-ready version of the blockchain where users can interact with the network and transact with real world assets. - -A _network of networks_, Avalanche Mainnet includes the [Primary Network](/docs/quick-start/primary-network) formed by the X, P, and C-Chain, as well as all in-production [Avalanche L1s](/docs/quick-start/avalanche-l1s). - -These Avalanche L1s are independent blockchain sub-networks that can be tailored to specific application use cases, use their own consensus mechanisms, define their own token economics, and be run by different [virtual machines](/docs/quick-start/virtual-machines). - -## Add Avalanche C-Chain Mainnet to Wallet - -- **Network Name**: Avalanche Mainnet C-Chain -- **RPC URL**: https://api.avax.network/ext/bc/C/rpc -- **WebSocket URL**: wss://api.avax.network/ext/bc/C/ws -- **ChainID**: `43114` -- **Symbol**: `AVAX` -- **Explorer**: https://subnets.avax.network/c-chain - -Head over to explorer linked above and select "Add Avalanche C-Chain to Wallet" under "Chain Info" to automatically add the network. \ No newline at end of file diff --git a/content/docs/quick-start/primary-network.mdx b/content/docs/quick-start/primary-network.mdx deleted file mode 100644 index af1c813950a..00000000000 --- a/content/docs/quick-start/primary-network.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: Primary Network -description: Learn about the Avalanche Primary Network and its three blockchains. ---- - -Avalanche is a heterogeneous network of blockchains. As opposed to homogeneous networks, where all applications reside in the same chain, heterogeneous networks allow separate chains to be created for different applications. - -The Primary Network is a special [Avalanche L1](/docs/quick-start/avalanche-l1s) that runs three blockchains: - -- The Platform Chain [(P-Chain)](/docs/quick-start/primary-network#p-chain) -- The Contract Chain [(C-Chain)](/docs/quick-start/primary-network#c-chain) -- The Exchange Chain [(X-Chain)](/docs/quick-start/primary-network#x-chain) - - -[Avalanche Mainnet](/docs/quick-start/networks/mainnet) is comprised of the Primary Network and all deployed Avalanche L1s. - - -A node can become a validator for the Primary Network by staking at least **2,000 AVAX**. - -![Primary network](/images/primary-network1.png) - -## The Chains - -All validators of the Primary Network are required to validate and secure the following: - -### C-Chain - -The **C-Chain** is an implementation of the Ethereum Virtual Machine (EVM). The [C-Chain's API](/docs/api-reference/c-chain/api) supports Geth's API and supports the deployment and execution of smart contracts written in Solidity. - -The C-Chain is an instance of the [Coreth](https://github.com/ava-labs/coreth) Virtual Machine. - -### P-Chain - -The **P-Chain** is responsible for all validator and Avalanche L1-level operations. The [P-Chain API](/docs/api-reference/p-chain/api) supports the creation of new blockchains and Avalanche L1s, the addition of validators to Avalanche L1s, staking operations, and other platform-level operations. - -The P-Chain is an instance of the Platform Virtual Machine. - -### X-Chain - -The **X-Chain** is responsible for operations on digital smart assets known as **Avalanche Native Tokens**. A smart asset is a representation of a real-world resource (for example, equity, or a bond) with sets of rules that govern its behavior, like "can't be traded until tomorrow." The [X-Chain API](/docs/api-reference/x-chain/api) supports the creation and trade of Avalanche Native Tokens. - -One asset traded on the X-Chain is AVAX. When you issue a transaction to a blockchain on Avalanche, you pay a fee denominated in AVAX. - -The X-Chain is an instance of the Avalanche Virtual Machine (AVM). diff --git a/content/docs/virtual-machines/evm-l1-customization.mdx b/content/docs/virtual-machines/evm-l1-customization.mdx deleted file mode 100644 index 8eba2a7e251..00000000000 --- a/content/docs/virtual-machines/evm-l1-customization.mdx +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: Introduction -description: Learn how to customize the Ethereum Virtual Machine with EVM and Precompiles. -root: true ---- - -Welcome to the EVM customization guide. This documentation provides an overview of **EVM**, the purpose of **Validator Manager Contracts**, the capabilities of **precompiles**, and how you can create custom precompiles to extend the functionality of the Ethereum Virtual Machine (EVM). - -## Overview of EVM - -EVM is Avalanche's customized version of the Ethereum Virtual Machine, tailored to run on Avalanche L1s. It allows developers to deploy Solidity smart contracts with enhanced capabilities, benefiting from Avalanche's high throughput and low latency. EVM enables more flexibility and performance optimizations compared to the standard EVM. - -## Validator Manager Contracts - -Validator Manager Contracts (VMCs) are smart contracts that manage the validators of an L1. They allow you to define rules and criteria for validator participation directly within smart contracts. VMCs enable dynamic validator sets, making it easier to add or remove validators without requiring a network restart. This provides greater control over the L1's validator management and enhances network governance. - -## Precompiles - -Precompiles are specialized smart contracts that execute native Go code within the EVM context. They act as a bridge between Solidity and lower-level functionalities, allowing for performance optimizations and access to features not available in Solidity alone. - -### Default Precompiles in EVM - -EVM comes with a set of default precompiles that extend the EVM's functionality. For detailed documentation on each precompile, visit the [Avalanche L1s Precompiles](/docs/avalanche-l1s/evm-configuration/evm-l1-customization#precompiles) section: - -- [AllowList](/docs/avalanche-l1s/evm-configuration/allowlist): A reusable interface for permission management -- [Permissions](/docs/avalanche-l1s/evm-configuration/permissions): Control contract deployment and transaction submission -- [Tokenomics](/docs/avalanche-l1s/evm-configuration/tokenomics): Manage native token supply and minting -- [Transaction Fees](/docs/avalanche-l1s/evm-configuration/transaction-fees): Configure fee parameters and reward mechanisms -- [Warp Messenger](/docs/avalanche-l1s/evm-configuration/warpmessenger): Perform cross-chain operations - -## Custom Precompiles - -One of the powerful features of EVM is the ability to create custom precompiles. By writing Go code and integrating it as a precompile, you can extend the EVM's functionality to suit specific use cases. Custom precompiles allow you to: - -- Achieve higher performance for computationally intensive tasks. -- Access lower-level system functions not available in Solidity. -- Implement custom cryptographic functions or algorithms. -- Interact with external systems or data sources. - -Creating custom precompiles opens up a wide range of possibilities for developers to optimize and expand their decentralized applications on Avalanche L1s. - -By leveraging EVM, Validator Manager Contracts, and precompiles, you can build customized and efficient decentralized applications with greater control and enhanced functionality. Explore the following sections to learn how to implement and utilize these powerful features. diff --git a/content/docs/virtual-machines/meta.json b/content/docs/virtual-machines/meta.json deleted file mode 100644 index b176e2fd7ae..00000000000 --- a/content/docs/virtual-machines/meta.json +++ /dev/null @@ -1,24 +0,0 @@ -{ - "title": "Custom VMs", - "description": "Customize Execution Layer", - "icon": "MonitorCog", - "root": true, - "pages": [ - "---Virtual Machines---", - "index", - "introduction-vms", - "simple-vm-any-language", - "manage-vm-binaries", - "---EVM Customization---", - "evm-l1-customization", - "custom-precompiles", - "---Golang VMs---", - "golang-vms/simple-golang-vm", - "golang-vms/complex-golang-vm", - "---Rust VMs---", - "rust-vms/intro-avalanche-rs", - "rust-vms/setting-up-environment", - "rust-vms/installing-vm", - "timestamp-vm" - ] -} \ No newline at end of file diff --git a/content/integrations-contributing.md b/content/integrations-contributing.md deleted file mode 100644 index 8e9eff29882..00000000000 --- a/content/integrations-contributing.md +++ /dev/null @@ -1,150 +0,0 @@ -# Contributing to Integrations - -This guide explains how to add new integrations to the Avalanche documentation. - -## Quick Start - -To add a new integration, create a new `.mdx` file in the `content/integrations/` directory following the structure outlined below. - -## File Structure - -### 1. File Naming -- Use lowercase with hyphens: `your-integration-name.mdx` -- Example: `openfort.mdx`, `chainlink.mdx`, `metamask.mdx` - -### 2. Frontmatter Requirements - -Every integration file must start with frontmatter containing the following fields: - -```yaml ---- -title: "Your Integration Name" -category: ["Category Name"] -available: ["C-Chain", "All EVM L1s"] -description: "Brief description of what your integration does" -logo: /images/your-logo.png -developer: "Developer/Company Name" -website: https://your-website.com -documentation: https://your-docs.com ---- -``` - -#### Field Descriptions: - -- **title**: The display name of your integration -- **category**: Array of categories (e.g., `["DeFi"]`, `["Account Abstraction"]`, `["Oracles"]`) - - If your category doesn't exist, it will be automatically created -- **available**: Which Avalanche networks support this integration - - Options: `"C-Chain"`, `"Subnet"`, `"All EVM L1s"`, `"Fuji Testnet"` -- **description**: A concise description of the integration's purpose -- **logo**: Path to your logo image (place in `/public/images/`) -- **developer**: Name of the company or developer -- **website**: Main website URL -- **documentation**: Link to technical documentation - -## Content Structure - -### 1. Overview Section -Start with an `## Overview` section that explains: -- What your integration does -- Key features and benefits -- Any sub-products or components - -### 2. Getting Started Section -Include a `## Getting Started` section with: -- Installation instructions -- Basic configuration -- Simple implementation example - -### 3. Code Examples -- Use proper syntax highlighting for code blocks -- Include both client-side and server-side examples where applicable -- Show Avalanche-specific configurations (Chain ID: 43114 for C-Chain) - -### 4. Documentation Link -End with a link to your full documentation. - -## Categories - -Common categories include: -- **DeFi**: Decentralized Finance protocols -- **Account Abstraction**: Wallet and account management -- **Oracles**: Data feeds and external data -- **Infrastructure**: Development tools and services -- **NFT**: Non-fungible token platforms -- **Analytics**: Data analysis and monitoring -- **Security**: Auditing and security tools - -Don't worry if your category doesn't exist - the system will automatically create new categories as needed. - -## Example Template - -```mdx ---- -title: "Your Integration" -category: ["Your Category"] -available: ["C-Chain"] -description: "What your integration does in one sentence." -logo: /images/your-logo.png -developer: "Your Company" -website: https://your-site.com -documentation: https://docs.your-site.com ---- - -## Overview -[Your Integration](https://your-site.com) provides [brief description of what it does and why it's useful for Avalanche developers]. - -Key features include: -- **Feature 1**: Description -- **Feature 2**: Description -- **Feature 3**: Description - -## Getting Started - -### 1. Installation - -```bash -npm install your-package -``` - -### 2. Configuration - -```typescript -// Basic setup example -const client = new YourClient({ - apiKey: "YOUR_API_KEY", - chainId: 43114 // Avalanche C-Chain -}); -``` - -### 3. Basic Usage - -```typescript -// Show how to use with Avalanche -const result = await client.someMethod({ - // Avalanche-specific parameters -}); -``` - -## Documentation -For detailed guides and API references, visit [Your Documentation](https://docs.your-site.com) -``` - -## Submission Process - -1. Create your `.mdx` file following the structure above -2. Add your logo to `/public/images/` -3. Test locally to ensure proper formatting -4. Submit a pull request with your integration - -## Tips - -- Keep descriptions concise but informative -- Include working code examples -- Make sure your logo is optimized for web (PNG/SVG preferred) -- Test all links before submitting -- Follow the existing style and tone of other integrations - -## Need Help? - -If you have questions about contributing an integration, feel free to reach out to the Avalanche documentation team. From 5cd7b34f96933340f892f919ebdec9ba2b432eb3 Mon Sep 17 00:00:00 2001 From: Owen Date: Wed, 19 Nov 2025 17:19:52 -0500 Subject: [PATCH 02/19] nodes and validator restructure --- .gitignore | 9 +- app/docs/docs-layout-wrapper.tsx | 4 +- app/docs/styles.css | 11 + app/global.css | 6 + content/docs/avalanche-l1s/meta.json | 10 +- content/docs/dapps/index.mdx | 2 - .../avalanche-l1s/avalanche-l1-configs.mdx | 106 ++++++ .../chain-configs/avalanche-l1s/meta.json | 8 + .../avalanche-l1s/subnet-evm.mdx | 307 ++++++++++++++++++ content/docs/nodes/chain-configs/index.mdx | 34 -- content/docs/nodes/chain-configs/meta.json | 8 +- .../chain-configs/primary-network/meta.json | 9 + content/docs/nodes/meta.json | 25 +- content/docs/nodes/run-a-node/meta.json | 13 + .../amazon-web-services.mdx | 0 .../aws-marketplace.mdx | 0 .../on-third-party-services/google-cloud.mdx | 0 .../on-third-party-services/latitude.mdx | 0 .../on-third-party-services/meta.json | 0 .../microsoft-azure.mdx | 0 .../installing-avalanche-go.mdx | 0 .../managing-avalanche-go.mdx | 0 .../using-install-script/meta.json | 0 .../node-config-maintenance.mdx | 0 .../preparing-environment.mdx | 0 content/docs/primary-network/index.mdx | 22 +- content/docs/primary-network/meta.json | 2 +- content/docs/rpcs/c-chain/index.mdx | 52 +-- content/docs/rpcs/c-chain/meta.json | 5 +- content/docs/rpcs/p-chain/meta.json | 5 +- content/docs/rpcs/subnet-evm/config.mdx | 307 ++++++++++++++++++ content/docs/rpcs/x-chain/meta.json | 5 +- utils/remote-content/primary-network.mts | 6 +- 33 files changed, 826 insertions(+), 130 deletions(-) create mode 100644 content/docs/nodes/chain-configs/avalanche-l1s/avalanche-l1-configs.mdx create mode 100644 content/docs/nodes/chain-configs/avalanche-l1s/meta.json create mode 100644 content/docs/nodes/chain-configs/avalanche-l1s/subnet-evm.mdx delete mode 100644 content/docs/nodes/chain-configs/index.mdx create mode 100644 content/docs/nodes/chain-configs/primary-network/meta.json create mode 100644 content/docs/nodes/run-a-node/meta.json rename content/docs/nodes/{ => run-a-node}/on-third-party-services/amazon-web-services.mdx (100%) rename content/docs/nodes/{ => run-a-node}/on-third-party-services/aws-marketplace.mdx (100%) rename content/docs/nodes/{ => run-a-node}/on-third-party-services/google-cloud.mdx (100%) rename content/docs/nodes/{ => run-a-node}/on-third-party-services/latitude.mdx (100%) rename content/docs/nodes/{ => run-a-node}/on-third-party-services/meta.json (100%) rename content/docs/nodes/{ => run-a-node}/on-third-party-services/microsoft-azure.mdx (100%) rename content/docs/nodes/{ => run-a-node}/using-install-script/installing-avalanche-go.mdx (100%) rename content/docs/nodes/{ => run-a-node}/using-install-script/managing-avalanche-go.mdx (100%) rename content/docs/nodes/{ => run-a-node}/using-install-script/meta.json (100%) rename content/docs/nodes/{ => run-a-node}/using-install-script/node-config-maintenance.mdx (100%) rename content/docs/nodes/{ => run-a-node}/using-install-script/preparing-environment.mdx (100%) create mode 100644 content/docs/rpcs/subnet-evm/config.mdx diff --git a/.gitignore b/.gitignore index 5d274798b63..bb3dbfd248e 100644 --- a/.gitignore +++ b/.gitignore @@ -144,6 +144,9 @@ package-lock.json + + + # Remote content output paths content/docs/acps/103-dynamic-fees.mdx content/docs/acps/108-evm-event-importing.mdx @@ -186,10 +189,10 @@ content/docs/cross-chain/teleporter/cli.mdx content/docs/cross-chain/teleporter/deep-dive.mdx content/docs/cross-chain/teleporter/overview.mdx content/docs/cross-chain/teleporter/upgradeability.mdx -content/docs/nodes/chain-configs/c-chain.mdx -content/docs/nodes/chain-configs/p-chain.mdx +content/docs/nodes/chain-configs/primary-network/c-chain.mdx +content/docs/nodes/chain-configs/primary-network/p-chain.mdx +content/docs/nodes/chain-configs/primary-network/x-chain.mdx content/docs/nodes/chain-configs/subnet-evm.mdx -content/docs/nodes/chain-configs/x-chain.mdx content/docs/nodes/configure/avalanche-l1-configs.mdx content/docs/nodes/configure/configs-flags.mdx content/docs/rpcs/c-chain/index.mdx diff --git a/app/docs/docs-layout-wrapper.tsx b/app/docs/docs-layout-wrapper.tsx index d89d20b99f6..ed3d3995466 100644 --- a/app/docs/docs-layout-wrapper.tsx +++ b/app/docs/docs-layout-wrapper.tsx @@ -136,8 +136,8 @@ export function DocsLayoutWrapper({ url: '/docs/cross-chain', }, { - title: 'Nodes and Validators', - description: 'Run network infrastructure', + title: 'AvalancheGo Node', + description: 'Run nodes and validators', icon: , url: '/docs/nodes', }, diff --git a/app/docs/styles.css b/app/docs/styles.css index 6488060fce6..974ba5e8884 100644 --- a/app/docs/styles.css +++ b/app/docs/styles.css @@ -359,6 +359,17 @@ body.search-open #docs-subnav { display: none !important; } +/* Fix sidebar dropdown icon centering */ +body[data-layout="docs"] #nd-sidebar button[aria-haspopup] > div:first-child { + display: flex !important; + align-items: center !important; + justify-content: center !important; +} + +body[data-layout="docs"] #nd-sidebar button[aria-haspopup] > div:first-child svg { + transform: translateY(-5px) !important; +} + /* Reduce sidebar horizontal padding and push down below subnavbar - DOCS ONLY */ body[data-layout="docs"] #nd-sidebar, body[data-layout="docs"] [data-sidebar="sidebar"] { diff --git a/app/global.css b/app/global.css index 141664f874c..afc3594a2d8 100644 --- a/app/global.css +++ b/app/global.css @@ -21,6 +21,12 @@ div.group\/accordion h3 { margin-top: 0 !important; } +/* Adjust login icon position in navbar */ +nav[aria-label="Main"] a[href="/login"] svg, +header a[href="/login"] svg { + transform: translateY(4px); +} + /* Make granite banner fixed instead of sticky */ [data-granite-banner] { position: fixed !important; diff --git a/content/docs/avalanche-l1s/meta.json b/content/docs/avalanche-l1s/meta.json index ea18798e380..a3a8b549917 100644 --- a/content/docs/avalanche-l1s/meta.json +++ b/content/docs/avalanche-l1s/meta.json @@ -8,9 +8,11 @@ "index", "when-to-build-avalanche-l1", "---Deploy an Avalanche L1---", - "[Wrench][Using L1 Toolbox](https://build.avax.network/tools/l1-toolbox#createSubnet)", + "[Wrench][Using Builder Console](https://build.avax.network/console/layer-1/create/create-chain)", "[SquareTerminal][Using Avalanche CLI](https://build.avax.network/docs/tooling/create-avalanche-l1)", - "[Globe][Using BaaS Providers](https://build.avax.network/integrations#Blockchain%20as%20a%20Service)", + "[Globe][Using Service Provider](https://build.avax.network/integrations#Blockchain%20as%20a%20Service)", + "---Upgrade an Avalanche L1---", + "...upgrade", "---Validator Manager---", "validator-manager/poa-vs-pos", "validator-manager/contract", @@ -39,8 +41,6 @@ "rust-vms/intro-avalanche-rs", "rust-vms/setting-up-environment", "rust-vms/installing-vm", - "timestamp-vm", - "---Upgrade an Avalanche L1---", - "...upgrade" + "timestamp-vm" ] } \ No newline at end of file diff --git a/content/docs/dapps/index.mdx b/content/docs/dapps/index.mdx index 349e0142828..33c1ee0e61d 100644 --- a/content/docs/dapps/index.mdx +++ b/content/docs/dapps/index.mdx @@ -5,8 +5,6 @@ description: Connect to Avalanche networks and explore the ecosystem. import { Network, Layers, Terminal, ArrowRight, Database, Package } from 'lucide-react'; -Avalanche provides both production and test networks for building and deploying decentralized applications. The Primary Network consists of three blockchains: C-Chain (Contract Chain), P-Chain (Platform Chain), and X-Chain (Exchange Chain). - ### C-Chain (Contract Chain) The C-Chain is an EVM-compatible blockchain for deploying smart contracts and dApps. diff --git a/content/docs/nodes/chain-configs/avalanche-l1s/avalanche-l1-configs.mdx b/content/docs/nodes/chain-configs/avalanche-l1s/avalanche-l1-configs.mdx new file mode 100644 index 00000000000..c6cda5a0423 --- /dev/null +++ b/content/docs/nodes/chain-configs/avalanche-l1s/avalanche-l1-configs.mdx @@ -0,0 +1,106 @@ +--- +title: "Avalanche L1 Configs" +description: "This page describes the configuration options available for Avalanche L1s." +edit_url: https://github.com/ava-labs/avalanchego/edit/master/subnets/config.md +--- + +# Subnet Configs + +It is possible to provide parameters for a Subnet. Parameters here apply to all +chains in the specified Subnet. + +AvalancheGo looks for files specified with `{subnetID}.json` under +`--subnet-config-dir` as documented +[here](https://build.avax.network/docs/nodes/configure/configs-flags#subnet-configs). + +Here is an example of Subnet config file: + +```json +{ + "validatorOnly": false, + "consensusParameters": { + "k": 25, + "alpha": 18 + } +} +``` + +## Parameters + +### Private Subnet + +#### `validatorOnly` (bool) + +If `true` this node does not expose Subnet blockchain contents to non-validators +via P2P messages. Defaults to `false`. + +Avalanche Subnets are public by default. It means that every node can sync and +listen ongoing transactions/blocks in Subnets, even they're not validating the +listened Subnet. + +Subnet validators can choose not to publish contents of blockchains via this +configuration. If a node sets `validatorOnly` to true, the node exchanges +messages only with this Subnet's validators. Other peers will not be able to +learn contents of this Subnet from this node. + +:::tip +This is a node-specific configuration. Every validator of this Subnet has to use +this configuration in order to create a full private Subnet. + +::: + +#### `allowedNodes` (string list) + +If `validatorOnly=true` this allows explicitly specified NodeIDs to be allowed +to sync the Subnet regardless of validator status. Defaults to be empty. + +:::tip +This is a node-specific configuration. Every validator of this Subnet has to use +this configuration in order to properly allow a node in the private Subnet. + +::: + +### Consensus Parameters + +Subnet configs supports loading new consensus parameters. JSON keys are +different from their matching `CLI` keys. These parameters must be grouped under +`consensusParameters` key. The consensus parameters of a Subnet default to the +same values used for the Primary Network, which are given [CLI Snow Parameters](https://build.avax.network/docs/nodes/configure/configs-flags#snow-parameters). + +| CLI Key | JSON Key | +| :------------------------------- | :-------------------- | +| --snow-sample-size | k | +| --snow-quorum-size | alpha | +| --snow-commit-threshold | `beta` | +| --snow-concurrent-repolls | concurrentRepolls | +| --snow-optimal-processing | `optimalProcessing` | +| --snow-max-processing | maxOutstandingItems | +| --snow-max-time-processing | maxItemProcessingTime | +| --snow-avalanche-batch-size | `batchSize` | +| --snow-avalanche-num-parents | `parentSize` | + +#### `proposerMinBlockDelay` (duration) + +The minimum delay performed when building snowman++ blocks. Default is set to 1 second. + +As one of the ways to control network congestion, Snowman++ will only build a +block `proposerMinBlockDelay` after the parent block's timestamp. Some +high-performance custom VMs may find this too strict. This flag allows tuning the +frequency at which blocks are built. + +### Gossip Configs + +It's possible to define different Gossip configurations for each Subnet without +changing values for Primary Network. JSON keys of these +parameters are different from their matching `CLI` keys. These parameters +default to the same values used for the Primary Network. For more information +see [CLI Gossip Configs](https://build.avax.network/docs/nodes/configure/configs-flags#gossiping). + +| CLI Key | JSON Key | +| :------------------------------------------------------ | :------------------------------------- | +| --consensus-accepted-frontier-gossip-validator-size | gossipAcceptedFrontierValidatorSize | +| --consensus-accepted-frontier-gossip-non-validator-size | gossipAcceptedFrontierNonValidatorSize | +| --consensus-accepted-frontier-gossip-peer-size | gossipAcceptedFrontierPeerSize | +| --consensus-on-accept-gossip-validator-size | gossipOnAcceptValidatorSize | +| --consensus-on-accept-gossip-non-validator-size | gossipOnAcceptNonValidatorSize | +| --consensus-on-accept-gossip-peer-size | gossipOnAcceptPeerSize | \ No newline at end of file diff --git a/content/docs/nodes/chain-configs/avalanche-l1s/meta.json b/content/docs/nodes/chain-configs/avalanche-l1s/meta.json new file mode 100644 index 00000000000..3f142644a38 --- /dev/null +++ b/content/docs/nodes/chain-configs/avalanche-l1s/meta.json @@ -0,0 +1,8 @@ +{ + "title": "Avalanche L1s", + "pages": [ + "subnet-evm", + "avalanche-l1-configs" + ] +} + diff --git a/content/docs/nodes/chain-configs/avalanche-l1s/subnet-evm.mdx b/content/docs/nodes/chain-configs/avalanche-l1s/subnet-evm.mdx new file mode 100644 index 00000000000..5542445586f --- /dev/null +++ b/content/docs/nodes/chain-configs/avalanche-l1s/subnet-evm.mdx @@ -0,0 +1,307 @@ +--- +title: "Subnet-EVM Configs" +description: "This page describes the configuration options available for the Subnet-EVM." +edit_url: https://github.com/ava-labs/subnet-evm/edit/master/plugin/evm/config/config.md +--- + +# Subnet-EVM Configuration + +> **Note**: These are the configuration options available in the Subnet-EVM codebase. To set these values, you need to create a configuration file at `~/.avalanchego/configs/chains//config.json`. +> +> For the AvalancheGo node configuration options, see the AvalancheGo Configuration page. + +This document describes all configuration options available for Subnet-EVM. + +## Example Configuration + +```json +{ + "eth-apis": ["eth", "eth-filter", "net", "web3"], + "pruning-enabled": true, + "commit-interval": 4096, + "trie-clean-cache": 512, + "trie-dirty-cache": 512, + "snapshot-cache": 256, + "rpc-gas-cap": 50000000, + "log-level": "info", + "metrics-expensive-enabled": true, + "continuous-profiler-dir": "./profiles", + "state-sync-enabled": false, + "accepted-cache-size": 32 +} +``` + +## Configuration Format + +Configuration is provided as a JSON object. All fields are optional unless otherwise specified. + +## API Configuration + +### Ethereum APIs + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `eth-apis` | array of strings | List of Ethereum services that should be enabled | `["eth", "eth-filter", "net", "web3", "internal-eth", "internal-blockchain", "internal-transaction"]` | + +### Subnet-EVM Specific APIs + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `validators-api-enabled` | bool | Enable the validators API | `true` | +| `admin-api-enabled` | bool | Enable the admin API for administrative operations | `false` | +| `admin-api-dir` | string | Directory for admin API operations | - | +| `warp-api-enabled` | bool | Enable the Warp API for cross-chain messaging | `false` | + +### API Limits and Security + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `rpc-gas-cap` | uint64 | Maximum gas limit for RPC calls | `50,000,000` | +| `rpc-tx-fee-cap` | float64 | Maximum transaction fee cap in AVAX | `100` | +| `api-max-duration` | duration | Maximum duration for API calls (0 = no limit) | `0` | +| `api-max-blocks-per-request` | int64 | Maximum number of blocks per getLogs request (0 = no limit) | `0` | +| `http-body-limit` | uint64 | Maximum size of HTTP request bodies | - | +| `batch-request-limit` | uint64 | Maximum number of requests that can be batched in an RPC call. For no limit, set either this or `batch-response-max-size` to 0 | `1000` | +| `batch-response-max-size` | uint64 | Maximum size (in bytes) of response that can be returned from a batched RPC call. For no limit, set either this or `batch-request-limit` to 0. Defaults to `25 MB`| `1000` | + +### WebSocket Settings + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `ws-cpu-refill-rate` | duration | Rate at which WebSocket CPU usage quota is refilled (0 = no limit) | `0` | +| `ws-cpu-max-stored` | duration | Maximum stored WebSocket CPU usage quota (0 = no limit) | `0` | + +## Cache Configuration + +### Trie Caches + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `trie-clean-cache` | int | Size of the trie clean cache in MB | `512` | +| `trie-dirty-cache` | int | Size of the trie dirty cache in MB | `512` | +| `trie-dirty-commit-target` | int | Memory limit to target in the dirty cache before performing a commit in MB | `20` | +| `trie-prefetcher-parallelism` | int | Maximum concurrent disk reads trie prefetcher should perform | `16` | + +### Other Caches + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `snapshot-cache` | int | Size of the snapshot disk layer clean cache in MB | `256` | +| `accepted-cache-size` | int | Depth to keep in the accepted headers and logs cache (blocks) | `32` | +| `state-sync-server-trie-cache` | int | Trie cache size for state sync server in MB | `64` | + +## Ethereum Settings + +### Transaction Processing + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `preimages-enabled` | bool | Enable preimage recording | `false` | +| `allow-unfinalized-queries` | bool | Allow queries for unfinalized blocks | `false` | +| `allow-unprotected-txs` | bool | Allow unprotected transactions (without EIP-155) | `false` | +| `allow-unprotected-tx-hashes` | array | List of specific transaction hashes allowed to be unprotected | EIP-1820 registry tx | +| `local-txs-enabled` | bool | Enable treatment of transactions from local accounts as local | `false` | + +### Snapshots + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `snapshot-wait` | bool | Wait for snapshot generation on startup | `false` | +| `snapshot-verification-enabled` | bool | Enable snapshot verification | `false` | + +## Pruning and State Management + +### Basic Pruning + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `pruning-enabled` | bool | Enable state pruning to save disk space | `true` | +| `commit-interval` | uint64 | Interval at which to persist EVM and atomic tries (blocks) | `4096` | +| `accepted-queue-limit` | int | Maximum blocks to queue before blocking during acceptance | `64` | + +### State Reconstruction + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `allow-missing-tries` | bool | Suppress warnings about incomplete trie index | `false` | +| `populate-missing-tries` | uint64 | Starting block for re-populating missing tries (null = disabled) | `null` | +| `populate-missing-tries-parallelism` | int | Concurrent readers for re-populating missing tries | `1024` | + +### Offline Pruning + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `offline-pruning-enabled` | bool | Enable offline pruning | `false` | +| `offline-pruning-bloom-filter-size` | uint64 | Bloom filter size for offline pruning in MB | `512` | +| `offline-pruning-data-directory` | string | Directory for offline pruning data | - | + +### Historical Data + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `historical-proof-query-window` | uint64 | Number of blocks before last accepted for proof queries (archive mode only, ~24 hours) | `43200` | +| `state-history` | uint64 | Number of most recent states that are accesible on disk (pruning mode only) | `32` | + +## Transaction Pool Configuration + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `tx-pool-price-limit` | uint64 | Minimum gas price for transaction acceptance | - | +| `tx-pool-price-bump` | uint64 | Minimum price bump percentage for transaction replacement | - | +| `tx-pool-account-slots` | uint64 | Maximum number of executable transaction slots per account | - | +| `tx-pool-global-slots` | uint64 | Maximum number of executable transaction slots for all accounts | - | +| `tx-pool-account-queue` | uint64 | Maximum number of non-executable transaction slots per account | - | +| `tx-pool-global-queue` | uint64 | Maximum number of non-executable transaction slots for all accounts | - | +| `tx-pool-lifetime` | duration | Maximum time transactions can stay in the pool | - | + +## Gossip Configuration + +### Push Gossip Settings + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `push-gossip-percent-stake` | float64 | Percentage of total stake to push gossip to (range: [0, 1]) | `0.9` | +| `push-gossip-num-validators` | int | Number of validators to push gossip to | `100` | +| `push-gossip-num-peers` | int | Number of non-validator peers to push gossip to | `0` | + +### Regossip Settings + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `push-regossip-num-validators` | int | Number of validators to regossip to | `10` | +| `push-regossip-num-peers` | int | Number of non-validator peers to regossip to | `0` | +| `priority-regossip-addresses` | array | Addresses to prioritize for regossip | - | + +### Timing Configuration + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `push-gossip-frequency` | duration | Frequency of push gossip | `100ms` | +| `pull-gossip-frequency` | duration | Frequency of pull gossip | `1s` | +| `regossip-frequency` | duration | Frequency of regossip | `30s` | + +## Logging and Monitoring + +### Logging + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `log-level` | string | Logging level (trace, debug, info, warn, error, crit) | `"info"` | +| `log-json-format` | bool | Use JSON format for logs | `false` | + +### Profiling + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `continuous-profiler-dir` | string | Directory for continuous profiler output (empty = disabled) | - | +| `continuous-profiler-frequency` | duration | Frequency to run continuous profiler | `15m` | +| `continuous-profiler-max-files` | int | Maximum number of profiler files to maintain | `5` | + +### Metrics + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `metrics-expensive-enabled` | bool | Enable expensive debug-level metrics; this includes Firewood metrics | `true` | + +## Security and Access + +### Keystore + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `keystore-directory` | string | Directory for keystore files (absolute or relative path) | - | +| `keystore-external-signer` | string | External signer configuration | - | +| `keystore-insecure-unlock-allowed` | bool | Allow insecure account unlocking | `false` | + +### Fee Configuration + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `feeRecipient` | string | Address to send transaction fees to (leave empty if not supported) | - | + +## Network and Sync + +### Network + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `max-outbound-active-requests` | int64 | Maximum number of outbound active requests for VM2VM network | `16` | + +### State Sync + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `state-sync-enabled` | bool | Enable state sync | `false` | +| `state-sync-skip-resume` | bool | Force state sync to use highest available summary block | `false` | +| `state-sync-ids` | string | Comma-separated list of state sync IDs | - | +| `state-sync-commit-interval` | uint64 | Commit interval for state sync (blocks) | `16384` | +| `state-sync-min-blocks` | uint64 | Minimum blocks ahead required for state sync | `300000` | +| `state-sync-request-size` | uint16 | Number of key/values to request per state sync request | `1024` | + +## Database Configuration + +> **WARNING**: `firewood` and `path` schemes are untested in production. Using `path` is strongly discouraged. To use `firewood`, you must also set the following config options: +> +> - `pruning-enabled: true` (enabled by default) +> - `state-sync-enabled: false` +> - `snapshot-cache: 0` + +Failing to set these options will result in errors on VM initialization. Additionally, not all APIs are available - see these portions of the config documentation for more details. + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `database-type` | string | Type of database to use | `"pebbledb"` | +| `database-path` | string | Path to database directory | - | +| `database-read-only` | bool | Open database in read-only mode | `false` | +| `database-config` | string | Inline database configuration | - | +| `database-config-file` | string | Path to database configuration file | - | +| `use-standalone-database` | bool | Use standalone database instead of shared one | - | +| `inspect-database` | bool | Inspect database on startup | `false` | +| `state-scheme` | string | EXPERIMENTAL: specifies the database scheme to store state data; can be one of `hash` or `firewood` | `hash` | + +## Transaction Indexing + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `transaction-history` | uint64 | Maximum number of blocks from head whose transaction indices are reserved (0 = no limit) | - | +| `tx-lookup-limit` | uint64 | **Deprecated** - use `transaction-history` instead | - | +| `skip-tx-indexing` | bool | Skip indexing transactions entirely | `false` | + +## Warp Configuration + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `warp-off-chain-messages` | array | Off-chain messages the node should be willing to sign | - | +| `prune-warp-db-enabled` | bool | Clear warp database on startup | `false` | + +## Miscellaneous + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `airdrop` | string | Path to airdrop file | - | +| `skip-upgrade-check` | bool | Skip checking that upgrades occur before last accepted block ⚠️ **Warning**: Only use when you understand the implications | `false` | +| `min-delay-target` | integer | The minimum delay between blocks (in milliseconds) that this node will attempt to use when creating blocks | Parent block's target | + +## Gossip Constants + +The following constants are defined for transaction gossip behavior and cannot be configured without a custom build of Subnet-EVM: + +| Constant | Type | Description | Value | +|----------|------|-------------|-------| +| Bloom Filter Min Target Elements | int | Minimum target elements for bloom filter | `8,192` | +| Bloom Filter Target False Positive Rate | float | Target false positive rate | `1%` | +| Bloom Filter Reset False Positive Rate | float | Reset false positive rate | `5%` | +| Bloom Filter Churn Multiplier | int | Churn multiplier | `3` | +| Push Gossip Discarded Elements | int | Number of discarded elements | `16,384` | +| Tx Gossip Target Message Size | size | Target message size for transaction gossip | `20 KiB` | +| Tx Gossip Throttling Period | duration | Throttling period | `10s` | +| Tx Gossip Throttling Limit | int | Throttling limit | `2` | +| Tx Gossip Poll Size | int | Poll size | `1` | + +## Validation Notes + +- Cannot enable `populate-missing-tries` while pruning or offline pruning is enabled +- Cannot run offline pruning while pruning is disabled +- Commit interval must be non-zero when pruning is enabled +- `push-gossip-percent-stake` must be in range `[0, 1]` +- Some settings may require node restart to take effect \ No newline at end of file diff --git a/content/docs/nodes/chain-configs/index.mdx b/content/docs/nodes/chain-configs/index.mdx deleted file mode 100644 index 8625195f011..00000000000 --- a/content/docs/nodes/chain-configs/index.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: Chain Specific Configs ---- - -Some chains allow the node operator to provide a custom configuration. AvalancheGo can read chain configurations from files and pass them to the corresponding chains on initialization. - -AvalancheGo looks for these files in the directory specified by `--chain-config-dir` AvalancheGo flag, as documented [here](/docs/nodes/configure/configs-flags#--chain-config-dir-string). If omitted, value defaults to `$HOME/.avalanchego/configs/chains`. This directory can have sub-directories whose names are chain IDs or chain aliases. Each sub-directory contains the configuration for the chain specified in the directory name. Each sub-directory should contain a file named `config`, whose value is passed in when the corresponding chain is initialized (see below for extension). For example, config for the C-Chain should be at: `{chain-config-dir}/C/config.json`. - -This also applies to Avalanche L1s, for example, if an Avalanche L1's chain id is `2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt`, the config for this chain should be at `{chain-config-dir}/2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt/config.json` - -} > -By default, none of these directories and/or files exist. You would need to create them manually if needed. - - -The filename extension that these files should have, and the contents of these files, is VM-dependent. For example, some chains may expect `config.txt` while others expect `config.json`. If multiple files are provided with the same name but different extensions (for example `config.json` and `config.txt`) in the same sub-directory, AvalancheGo will exit with an error. - -For a given chain, AvalancheGo will follow the sequence below to look for its config file, where all folder and file names are case sensitive: - -1. First it looks for a config sub-directory whose name is the Chain ID. -2. If it isn't found, it looks for a config sub-directory whose name is the chain's primary alias. -3. If it's not found, it looks for a config sub-directory whose name is another alias for the chain - -Alternatively, for some setups it might be more convenient to provide config entirely via the command line. For that, you can use AvalancheGo `--chain-config-content` flag, as documented [here](/docs/nodes/configure/configs-flags#--chain-config-content-string). - -It is not required to provide these custom configurations. If they are not provided, a VM-specific default config will be used. And the values of these default config are printed when the node starts. - -## Avalanche L1 Chain Configs - -As mentioned above, if an Avalanche L1's chain id is `2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt`, the config for this chain should be at `{chain-config-dir}/2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt/config.json` - -## FAQs - -- When using `getBlockNumber` it will return finalized blocks. To allow for queries for unfinalized (not yet accepted) blocks/transactions use `allow-unfainalized-queries` and set to true (by default it is set to `false`) -- When deactivating offline pruning `(pruning-enabled: false)` from previously enabled state, this will not impact blocks whose state was already pruned. This will return missing trie node errors, as the node can't lookup the state of a historical block if that state was deleted. diff --git a/content/docs/nodes/chain-configs/meta.json b/content/docs/nodes/chain-configs/meta.json index 32b1a596d6c..f87102d5aa3 100644 --- a/content/docs/nodes/chain-configs/meta.json +++ b/content/docs/nodes/chain-configs/meta.json @@ -1,4 +1,8 @@ { - "title": "Chain Specific Configs", - "pages": ["subnet-evm", "p-chain", "c-chain", "x-chain"] + "title": "Chain Configs", + "pages": [ + "primary-network", + "avalanche-l1s" + ] } + diff --git a/content/docs/nodes/chain-configs/primary-network/meta.json b/content/docs/nodes/chain-configs/primary-network/meta.json new file mode 100644 index 00000000000..3060d68b8f9 --- /dev/null +++ b/content/docs/nodes/chain-configs/primary-network/meta.json @@ -0,0 +1,9 @@ +{ + "title": "Primary Network", + "pages": [ + "c-chain", + "p-chain", + "x-chain" + ] +} + diff --git a/content/docs/nodes/meta.json b/content/docs/nodes/meta.json index dd358a3c510..22d06450a23 100644 --- a/content/docs/nodes/meta.json +++ b/content/docs/nodes/meta.json @@ -1,24 +1,19 @@ { - "title": "Nodes & Validators", - "description": "Participate in the Network", + "title": "AvalancheGo Node", + "description": "Run nodes and validators", "icon": "MonitorCheck", "root": true, "pages": [ "index", + "---Getting Started---", "system-requirements", - "---Run A Node---", - "run-a-node/from-source", - "run-a-node/using-binary", - "run-a-node/using-docker", - "using-install-script", - "run-a-node/avalanche-l1-nodes", - "on-third-party-services", - "run-a-node/common-errors", - "---Configure Node---", + "run-a-node", + "---AvalancheGo Configuration---", "configure/configs-flags", - "chain-configs", - "configure/avalanche-l1-configs", - "---Maintain---", - "...maintain" + "chain-configs/primary-network", + "chain-configs/avalanche-l1s", + "---Maintenance---", + "...maintain", + "run-a-node/common-errors" ] } \ No newline at end of file diff --git a/content/docs/nodes/run-a-node/meta.json b/content/docs/nodes/run-a-node/meta.json new file mode 100644 index 00000000000..928997a0666 --- /dev/null +++ b/content/docs/nodes/run-a-node/meta.json @@ -0,0 +1,13 @@ +{ + "title": "Install Node", + "pages": [ + "using-binary", + "from-source", + "using-docker", + "using-install-script", + "on-third-party-services", + "---Avalanche L1s---", + "avalanche-l1-nodes" + ] +} + diff --git a/content/docs/nodes/on-third-party-services/amazon-web-services.mdx b/content/docs/nodes/run-a-node/on-third-party-services/amazon-web-services.mdx similarity index 100% rename from content/docs/nodes/on-third-party-services/amazon-web-services.mdx rename to content/docs/nodes/run-a-node/on-third-party-services/amazon-web-services.mdx diff --git a/content/docs/nodes/on-third-party-services/aws-marketplace.mdx b/content/docs/nodes/run-a-node/on-third-party-services/aws-marketplace.mdx similarity index 100% rename from content/docs/nodes/on-third-party-services/aws-marketplace.mdx rename to content/docs/nodes/run-a-node/on-third-party-services/aws-marketplace.mdx diff --git a/content/docs/nodes/on-third-party-services/google-cloud.mdx b/content/docs/nodes/run-a-node/on-third-party-services/google-cloud.mdx similarity index 100% rename from content/docs/nodes/on-third-party-services/google-cloud.mdx rename to content/docs/nodes/run-a-node/on-third-party-services/google-cloud.mdx diff --git a/content/docs/nodes/on-third-party-services/latitude.mdx b/content/docs/nodes/run-a-node/on-third-party-services/latitude.mdx similarity index 100% rename from content/docs/nodes/on-third-party-services/latitude.mdx rename to content/docs/nodes/run-a-node/on-third-party-services/latitude.mdx diff --git a/content/docs/nodes/on-third-party-services/meta.json b/content/docs/nodes/run-a-node/on-third-party-services/meta.json similarity index 100% rename from content/docs/nodes/on-third-party-services/meta.json rename to content/docs/nodes/run-a-node/on-third-party-services/meta.json diff --git a/content/docs/nodes/on-third-party-services/microsoft-azure.mdx b/content/docs/nodes/run-a-node/on-third-party-services/microsoft-azure.mdx similarity index 100% rename from content/docs/nodes/on-third-party-services/microsoft-azure.mdx rename to content/docs/nodes/run-a-node/on-third-party-services/microsoft-azure.mdx diff --git a/content/docs/nodes/using-install-script/installing-avalanche-go.mdx b/content/docs/nodes/run-a-node/using-install-script/installing-avalanche-go.mdx similarity index 100% rename from content/docs/nodes/using-install-script/installing-avalanche-go.mdx rename to content/docs/nodes/run-a-node/using-install-script/installing-avalanche-go.mdx diff --git a/content/docs/nodes/using-install-script/managing-avalanche-go.mdx b/content/docs/nodes/run-a-node/using-install-script/managing-avalanche-go.mdx similarity index 100% rename from content/docs/nodes/using-install-script/managing-avalanche-go.mdx rename to content/docs/nodes/run-a-node/using-install-script/managing-avalanche-go.mdx diff --git a/content/docs/nodes/using-install-script/meta.json b/content/docs/nodes/run-a-node/using-install-script/meta.json similarity index 100% rename from content/docs/nodes/using-install-script/meta.json rename to content/docs/nodes/run-a-node/using-install-script/meta.json diff --git a/content/docs/nodes/using-install-script/node-config-maintenance.mdx b/content/docs/nodes/run-a-node/using-install-script/node-config-maintenance.mdx similarity index 100% rename from content/docs/nodes/using-install-script/node-config-maintenance.mdx rename to content/docs/nodes/run-a-node/using-install-script/node-config-maintenance.mdx diff --git a/content/docs/nodes/using-install-script/preparing-environment.mdx b/content/docs/nodes/run-a-node/using-install-script/preparing-environment.mdx similarity index 100% rename from content/docs/nodes/using-install-script/preparing-environment.mdx rename to content/docs/nodes/run-a-node/using-install-script/preparing-environment.mdx diff --git a/content/docs/primary-network/index.mdx b/content/docs/primary-network/index.mdx index 89ad2b6d690..0049b08bd28 100644 --- a/content/docs/primary-network/index.mdx +++ b/content/docs/primary-network/index.mdx @@ -7,9 +7,9 @@ description: Learn about the Avalanche Primary Network and its three blockchains graph TB PN["🏔️ Primary Network"] - PN ==> XC["🔄 Exchange (X) Chain
━━━━━━━━━━━━━━━
Snowman Consensus Protocol"] - PN ==> PC["⚙️ Platform (P) Chain
━━━━━━━━━━━━━━━
Snowman Consensus Protocol"] - PN ==> CC["📝 Contract (C) Chain
━━━━━━━━━━━━━━━
Snowman Consensus Protocol"] + PN ==> XC["Exchange (X) Chain
━━━━━━━━━━━━━━━
Snowman Consensus Protocol"] + PN ==> PC["Platform (P) Chain
━━━━━━━━━━━━━━━
Snowman Consensus Protocol"] + PN ==> CC["Contract (C) Chain
━━━━━━━━━━━━━━━
Snowman Consensus Protocol"] XC --> XF1["Creates Assets"] XC --> XF2["Exchanges Assets"] @@ -20,16 +20,16 @@ graph TB CC --> CF1["Executes EVM Contracts"] CC --> CF2["Smart Contracts"] - XF1 -.-> A1["👤 Asset 1"] - XF1 -.-> A2["🏠 Asset 2"] - XF2 -.-> AV["⚡ AVAX"] + XF1 -.-> A1["Asset 1"] + XF1 -.-> A2["Asset 2"] + XF2 -.-> AV["AVAX"] - PF2 -.-> C1["⛓️ Custom Chain 1"] - PF2 -.-> C2["⛓️ Custom Chain 2"] + PF2 -.-> C1["Custom Chain 1"] + PF2 -.-> C2["Custom Chain 2"] - CF2 -.-> N1["🖼️ NFT"] - CF2 -.-> E1["🪙 ERC20"] - CF2 -.-> D1["🚀 DAPP"] + CF2 -.-> N1["NFT"] + CF2 -.-> E1["ERC20"] + CF2 -.-> D1["DAPP"] style PN fill:#e74c3c,stroke:#c0392b,stroke-width:4px,color:#fff,rx:15,ry:15 style XC fill:#3498db,stroke:#2980b9,stroke-width:3px,color:#fff,rx:10,ry:10 diff --git a/content/docs/primary-network/meta.json b/content/docs/primary-network/meta.json index 68f7b39e6b4..9cd73e7e12e 100644 --- a/content/docs/primary-network/meta.json +++ b/content/docs/primary-network/meta.json @@ -9,8 +9,8 @@ "avax-token", "virtual-machines", "---Validate---", - "validate/rewards-formula", "validate/validate-vs-delegate", + "validate/rewards-formula", "validate/how-to-stake", "validate/node-validator" ] diff --git a/content/docs/rpcs/c-chain/index.mdx b/content/docs/rpcs/c-chain/index.mdx index 0a9514a6203..2081bceb23a 100644 --- a/content/docs/rpcs/c-chain/index.mdx +++ b/content/docs/rpcs/c-chain/index.mdx @@ -4,9 +4,7 @@ description: "This page is an overview of the C-Chain RPC associated with Avalan edit_url: https://github.com/ava-labs/coreth/edit/master/plugin/evm/api.md --- - -Ethereum has its own notion of `networkID` and `chainID`. These have no relationship to Avalanche's view of networkID and chainID and are purely internal to the [C-Chain](https://github.com/docs/quick-start/primary-network#c-chain). On Mainnet, the C-Chain uses `1` and `43114` for these values. On the Fuji Testnet, it uses `1` and `43113` for these values. `networkID` and `chainID` can also be obtained using the `net_version` and `eth_chainId` methods. - +> **Note:** Ethereum has its own notion of `networkID` and `chainID`. These have no relationship to Avalanche's view of networkID and chainID and are purely internal to the [C-Chain](https://build.avax.network/docs/quick-start/primary-network#c-chain). On Mainnet, the C-Chain uses `1` and `43114` for these values. On the Fuji Testnet, it uses `1` and `43113` for these values. `networkID` and `chainID` can also be obtained using the `net_version` and `eth_chainId` methods. ## Ethereum APIs @@ -30,10 +28,7 @@ where `blockchainID` is the ID of the blockchain running the EVM. #### WebSocket Endpoints - -On the [public API node](https://github.com/docs/tooling/rpc-providers), it only supports C-Chain -websocket API calls for API methods that don't exist on the C-Chain's HTTP API - +> **Info:** The [public API node](https://build.avax.network/integrations#RPC%20Providers) (api.avax.network) supports HTTP APIs for X-Chain, P-Chain, and C-Chain, but websocket connections are only available for C-Chain. Other EVM chains are not available via websocket on the public API node. To interact with C-Chain via the websocket endpoint: @@ -47,10 +42,7 @@ For example, to interact with the C-Chain's Ethereum APIs via websocket on local ws://127.0.0.1:9650/ext/bc/C/ws ``` -} > -On localhost, use `ws://`. When using the [Public API](https://github.com/docs/tooling/rpc-providers) or another -host that supports encryption, use `wss://`. - +> **Tip:** On localhost, use `ws://`. When using the [Public API](https://build.avax.network/integrations#RPC%20Providers) or another host that supports encryption, use `wss://`. To interact with other instances of the EVM via the websocket endpoint: @@ -77,10 +69,7 @@ You can interact with these services the same exact way you'd interact with Geth and [Geth's JSON-RPC Documentation](https://geth.ethereum.org/docs/rpc/server) for a full description of this API. - -For batched requests on the [public API node](https://github.com/docs/tooling/rpc-providers) , the maximum -number of items is 40. - +> **Info:** For batched requests on the [public API node](https://build.avax.network/integrations#RPC%20Providers) , the maximum number of items is 40. #### Exceptions @@ -167,19 +156,19 @@ curl -X POST --data '{ ``` For more information on dynamic fees see the [C-Chain section of the transaction fee -documentation](https://github.com/docs/api-reference/guides/txn-fees#c-chain-fees). +documentation](https://build.avax.network/docs/rpcs/other/guides/txn-fees#c-chain-fees). ## Admin APIs The Admin API provides administrative functionality for the EVM. -### Endpoint +### Admin API Endpoint ```sh /ext/bc/C/admin ``` -### Methods +### Admin API Methods #### `admin_startCPUProfiler` @@ -317,13 +306,13 @@ curl -X POST --data '{ ## Avalanche-Specific APIs -### Endpoint +### Avalanche-Specific API Endpoint ```sh /ext/bc/C/avax ``` -### Methods +### Avalanche-Specific API Methods #### `avax.getUTXOs` @@ -454,27 +443,4 @@ curl -X POST --data '{ "encoding": "hex" }] }' -H 'content-type:application/json;' 127.0.0.1:9650/ext/bc/C/avax -``` - -#### `avax.version` - -Returns the version of the VM. - -**Signature:** - -```sh -avax.version() -> { - version: string -} -``` - -**Example Call:** - -```sh -curl -X POST --data '{ - "jsonrpc":"2.0", - "id" :1, - "method" :"avax.version", - "params" :[] -}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/bc/C/avax ``` \ No newline at end of file diff --git a/content/docs/rpcs/c-chain/meta.json b/content/docs/rpcs/c-chain/meta.json index 2786ae13eae..5d669672ab6 100644 --- a/content/docs/rpcs/c-chain/meta.json +++ b/content/docs/rpcs/c-chain/meta.json @@ -5,6 +5,7 @@ "root": true, "pages": [ "index", + "txn-format", "---RPC Methods---", "eth", "web3", @@ -13,8 +14,6 @@ "txpool", "debug", "avalanche", - "warp", - "---Reference---", - "txn-format" + "warp" ] } diff --git a/content/docs/rpcs/p-chain/meta.json b/content/docs/rpcs/p-chain/meta.json index dd2d0d347a8..53b24ba8cdd 100644 --- a/content/docs/rpcs/p-chain/meta.json +++ b/content/docs/rpcs/p-chain/meta.json @@ -5,6 +5,7 @@ "root": true, "pages": [ "index", + "txn-format", "---RPC Methods---", "chain-info", "subnets", @@ -15,8 +16,6 @@ "balances-utxos", "staking", "rewards", - "fees", - "---Reference---", - "txn-format" + "fees" ] } diff --git a/content/docs/rpcs/subnet-evm/config.mdx b/content/docs/rpcs/subnet-evm/config.mdx new file mode 100644 index 00000000000..5542445586f --- /dev/null +++ b/content/docs/rpcs/subnet-evm/config.mdx @@ -0,0 +1,307 @@ +--- +title: "Subnet-EVM Configs" +description: "This page describes the configuration options available for the Subnet-EVM." +edit_url: https://github.com/ava-labs/subnet-evm/edit/master/plugin/evm/config/config.md +--- + +# Subnet-EVM Configuration + +> **Note**: These are the configuration options available in the Subnet-EVM codebase. To set these values, you need to create a configuration file at `~/.avalanchego/configs/chains//config.json`. +> +> For the AvalancheGo node configuration options, see the AvalancheGo Configuration page. + +This document describes all configuration options available for Subnet-EVM. + +## Example Configuration + +```json +{ + "eth-apis": ["eth", "eth-filter", "net", "web3"], + "pruning-enabled": true, + "commit-interval": 4096, + "trie-clean-cache": 512, + "trie-dirty-cache": 512, + "snapshot-cache": 256, + "rpc-gas-cap": 50000000, + "log-level": "info", + "metrics-expensive-enabled": true, + "continuous-profiler-dir": "./profiles", + "state-sync-enabled": false, + "accepted-cache-size": 32 +} +``` + +## Configuration Format + +Configuration is provided as a JSON object. All fields are optional unless otherwise specified. + +## API Configuration + +### Ethereum APIs + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `eth-apis` | array of strings | List of Ethereum services that should be enabled | `["eth", "eth-filter", "net", "web3", "internal-eth", "internal-blockchain", "internal-transaction"]` | + +### Subnet-EVM Specific APIs + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `validators-api-enabled` | bool | Enable the validators API | `true` | +| `admin-api-enabled` | bool | Enable the admin API for administrative operations | `false` | +| `admin-api-dir` | string | Directory for admin API operations | - | +| `warp-api-enabled` | bool | Enable the Warp API for cross-chain messaging | `false` | + +### API Limits and Security + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `rpc-gas-cap` | uint64 | Maximum gas limit for RPC calls | `50,000,000` | +| `rpc-tx-fee-cap` | float64 | Maximum transaction fee cap in AVAX | `100` | +| `api-max-duration` | duration | Maximum duration for API calls (0 = no limit) | `0` | +| `api-max-blocks-per-request` | int64 | Maximum number of blocks per getLogs request (0 = no limit) | `0` | +| `http-body-limit` | uint64 | Maximum size of HTTP request bodies | - | +| `batch-request-limit` | uint64 | Maximum number of requests that can be batched in an RPC call. For no limit, set either this or `batch-response-max-size` to 0 | `1000` | +| `batch-response-max-size` | uint64 | Maximum size (in bytes) of response that can be returned from a batched RPC call. For no limit, set either this or `batch-request-limit` to 0. Defaults to `25 MB`| `1000` | + +### WebSocket Settings + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `ws-cpu-refill-rate` | duration | Rate at which WebSocket CPU usage quota is refilled (0 = no limit) | `0` | +| `ws-cpu-max-stored` | duration | Maximum stored WebSocket CPU usage quota (0 = no limit) | `0` | + +## Cache Configuration + +### Trie Caches + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `trie-clean-cache` | int | Size of the trie clean cache in MB | `512` | +| `trie-dirty-cache` | int | Size of the trie dirty cache in MB | `512` | +| `trie-dirty-commit-target` | int | Memory limit to target in the dirty cache before performing a commit in MB | `20` | +| `trie-prefetcher-parallelism` | int | Maximum concurrent disk reads trie prefetcher should perform | `16` | + +### Other Caches + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `snapshot-cache` | int | Size of the snapshot disk layer clean cache in MB | `256` | +| `accepted-cache-size` | int | Depth to keep in the accepted headers and logs cache (blocks) | `32` | +| `state-sync-server-trie-cache` | int | Trie cache size for state sync server in MB | `64` | + +## Ethereum Settings + +### Transaction Processing + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `preimages-enabled` | bool | Enable preimage recording | `false` | +| `allow-unfinalized-queries` | bool | Allow queries for unfinalized blocks | `false` | +| `allow-unprotected-txs` | bool | Allow unprotected transactions (without EIP-155) | `false` | +| `allow-unprotected-tx-hashes` | array | List of specific transaction hashes allowed to be unprotected | EIP-1820 registry tx | +| `local-txs-enabled` | bool | Enable treatment of transactions from local accounts as local | `false` | + +### Snapshots + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `snapshot-wait` | bool | Wait for snapshot generation on startup | `false` | +| `snapshot-verification-enabled` | bool | Enable snapshot verification | `false` | + +## Pruning and State Management + +### Basic Pruning + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `pruning-enabled` | bool | Enable state pruning to save disk space | `true` | +| `commit-interval` | uint64 | Interval at which to persist EVM and atomic tries (blocks) | `4096` | +| `accepted-queue-limit` | int | Maximum blocks to queue before blocking during acceptance | `64` | + +### State Reconstruction + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `allow-missing-tries` | bool | Suppress warnings about incomplete trie index | `false` | +| `populate-missing-tries` | uint64 | Starting block for re-populating missing tries (null = disabled) | `null` | +| `populate-missing-tries-parallelism` | int | Concurrent readers for re-populating missing tries | `1024` | + +### Offline Pruning + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `offline-pruning-enabled` | bool | Enable offline pruning | `false` | +| `offline-pruning-bloom-filter-size` | uint64 | Bloom filter size for offline pruning in MB | `512` | +| `offline-pruning-data-directory` | string | Directory for offline pruning data | - | + +### Historical Data + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `historical-proof-query-window` | uint64 | Number of blocks before last accepted for proof queries (archive mode only, ~24 hours) | `43200` | +| `state-history` | uint64 | Number of most recent states that are accesible on disk (pruning mode only) | `32` | + +## Transaction Pool Configuration + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `tx-pool-price-limit` | uint64 | Minimum gas price for transaction acceptance | - | +| `tx-pool-price-bump` | uint64 | Minimum price bump percentage for transaction replacement | - | +| `tx-pool-account-slots` | uint64 | Maximum number of executable transaction slots per account | - | +| `tx-pool-global-slots` | uint64 | Maximum number of executable transaction slots for all accounts | - | +| `tx-pool-account-queue` | uint64 | Maximum number of non-executable transaction slots per account | - | +| `tx-pool-global-queue` | uint64 | Maximum number of non-executable transaction slots for all accounts | - | +| `tx-pool-lifetime` | duration | Maximum time transactions can stay in the pool | - | + +## Gossip Configuration + +### Push Gossip Settings + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `push-gossip-percent-stake` | float64 | Percentage of total stake to push gossip to (range: [0, 1]) | `0.9` | +| `push-gossip-num-validators` | int | Number of validators to push gossip to | `100` | +| `push-gossip-num-peers` | int | Number of non-validator peers to push gossip to | `0` | + +### Regossip Settings + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `push-regossip-num-validators` | int | Number of validators to regossip to | `10` | +| `push-regossip-num-peers` | int | Number of non-validator peers to regossip to | `0` | +| `priority-regossip-addresses` | array | Addresses to prioritize for regossip | - | + +### Timing Configuration + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `push-gossip-frequency` | duration | Frequency of push gossip | `100ms` | +| `pull-gossip-frequency` | duration | Frequency of pull gossip | `1s` | +| `regossip-frequency` | duration | Frequency of regossip | `30s` | + +## Logging and Monitoring + +### Logging + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `log-level` | string | Logging level (trace, debug, info, warn, error, crit) | `"info"` | +| `log-json-format` | bool | Use JSON format for logs | `false` | + +### Profiling + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `continuous-profiler-dir` | string | Directory for continuous profiler output (empty = disabled) | - | +| `continuous-profiler-frequency` | duration | Frequency to run continuous profiler | `15m` | +| `continuous-profiler-max-files` | int | Maximum number of profiler files to maintain | `5` | + +### Metrics + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `metrics-expensive-enabled` | bool | Enable expensive debug-level metrics; this includes Firewood metrics | `true` | + +## Security and Access + +### Keystore + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `keystore-directory` | string | Directory for keystore files (absolute or relative path) | - | +| `keystore-external-signer` | string | External signer configuration | - | +| `keystore-insecure-unlock-allowed` | bool | Allow insecure account unlocking | `false` | + +### Fee Configuration + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `feeRecipient` | string | Address to send transaction fees to (leave empty if not supported) | - | + +## Network and Sync + +### Network + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `max-outbound-active-requests` | int64 | Maximum number of outbound active requests for VM2VM network | `16` | + +### State Sync + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `state-sync-enabled` | bool | Enable state sync | `false` | +| `state-sync-skip-resume` | bool | Force state sync to use highest available summary block | `false` | +| `state-sync-ids` | string | Comma-separated list of state sync IDs | - | +| `state-sync-commit-interval` | uint64 | Commit interval for state sync (blocks) | `16384` | +| `state-sync-min-blocks` | uint64 | Minimum blocks ahead required for state sync | `300000` | +| `state-sync-request-size` | uint16 | Number of key/values to request per state sync request | `1024` | + +## Database Configuration + +> **WARNING**: `firewood` and `path` schemes are untested in production. Using `path` is strongly discouraged. To use `firewood`, you must also set the following config options: +> +> - `pruning-enabled: true` (enabled by default) +> - `state-sync-enabled: false` +> - `snapshot-cache: 0` + +Failing to set these options will result in errors on VM initialization. Additionally, not all APIs are available - see these portions of the config documentation for more details. + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `database-type` | string | Type of database to use | `"pebbledb"` | +| `database-path` | string | Path to database directory | - | +| `database-read-only` | bool | Open database in read-only mode | `false` | +| `database-config` | string | Inline database configuration | - | +| `database-config-file` | string | Path to database configuration file | - | +| `use-standalone-database` | bool | Use standalone database instead of shared one | - | +| `inspect-database` | bool | Inspect database on startup | `false` | +| `state-scheme` | string | EXPERIMENTAL: specifies the database scheme to store state data; can be one of `hash` or `firewood` | `hash` | + +## Transaction Indexing + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `transaction-history` | uint64 | Maximum number of blocks from head whose transaction indices are reserved (0 = no limit) | - | +| `tx-lookup-limit` | uint64 | **Deprecated** - use `transaction-history` instead | - | +| `skip-tx-indexing` | bool | Skip indexing transactions entirely | `false` | + +## Warp Configuration + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `warp-off-chain-messages` | array | Off-chain messages the node should be willing to sign | - | +| `prune-warp-db-enabled` | bool | Clear warp database on startup | `false` | + +## Miscellaneous + +| Option | Type | Description | Default | +|--------|------|-------------|---------| +| `airdrop` | string | Path to airdrop file | - | +| `skip-upgrade-check` | bool | Skip checking that upgrades occur before last accepted block ⚠️ **Warning**: Only use when you understand the implications | `false` | +| `min-delay-target` | integer | The minimum delay between blocks (in milliseconds) that this node will attempt to use when creating blocks | Parent block's target | + +## Gossip Constants + +The following constants are defined for transaction gossip behavior and cannot be configured without a custom build of Subnet-EVM: + +| Constant | Type | Description | Value | +|----------|------|-------------|-------| +| Bloom Filter Min Target Elements | int | Minimum target elements for bloom filter | `8,192` | +| Bloom Filter Target False Positive Rate | float | Target false positive rate | `1%` | +| Bloom Filter Reset False Positive Rate | float | Reset false positive rate | `5%` | +| Bloom Filter Churn Multiplier | int | Churn multiplier | `3` | +| Push Gossip Discarded Elements | int | Number of discarded elements | `16,384` | +| Tx Gossip Target Message Size | size | Target message size for transaction gossip | `20 KiB` | +| Tx Gossip Throttling Period | duration | Throttling period | `10s` | +| Tx Gossip Throttling Limit | int | Throttling limit | `2` | +| Tx Gossip Poll Size | int | Poll size | `1` | + +## Validation Notes + +- Cannot enable `populate-missing-tries` while pruning or offline pruning is enabled +- Cannot run offline pruning while pruning is disabled +- Commit interval must be non-zero when pruning is enabled +- `push-gossip-percent-stake` must be in range `[0, 1]` +- Some settings may require node restart to take effect \ No newline at end of file diff --git a/content/docs/rpcs/x-chain/meta.json b/content/docs/rpcs/x-chain/meta.json index 93df4ad08e4..33b9bc690cb 100644 --- a/content/docs/rpcs/x-chain/meta.json +++ b/content/docs/rpcs/x-chain/meta.json @@ -5,9 +5,8 @@ "root": true, "pages": [ "index", + "txn-format", "---RPC Methods---", - "...chain", - "---Reference---", - "txn-format" + "...chain" ] } diff --git a/utils/remote-content/primary-network.mts b/utils/remote-content/primary-network.mts index e289908784d..43e5aa4430d 100644 --- a/utils/remote-content/primary-network.mts +++ b/utils/remote-content/primary-network.mts @@ -7,21 +7,21 @@ export function getPrimaryNetworkConfigs(): FileConfig[] { return [ { sourceUrl: "https://raw.githubusercontent.com/ava-labs/avalanchego/master/vms/platformvm/config/config.md", - outputPath: "content/docs/nodes/chain-configs/p-chain.mdx", + outputPath: "content/docs/nodes/chain-configs/primary-network/p-chain.mdx", title: "P-Chain Configs", description: "This page describes the configuration options available for the P-Chain.", contentUrl: "https://github.com/ava-labs/avalanchego/blob/master/vms/platformvm/config/", }, { sourceUrl: "https://raw.githubusercontent.com/ava-labs/coreth/master/plugin/evm/config/config.md", - outputPath: "content/docs/nodes/chain-configs/c-chain.mdx", + outputPath: "content/docs/nodes/chain-configs/primary-network/c-chain.mdx", title: "C-Chain Configs", description: "This page describes the configuration options available for the C-Chain.", contentUrl: "https://github.com/ava-labs/coreth/blob/master/plugin/evm/config/", }, { sourceUrl: "https://raw.githubusercontent.com/ava-labs/avalanchego/master/vms/avm/config.md", - outputPath: "content/docs/nodes/chain-configs/x-chain.mdx", + outputPath: "content/docs/nodes/chain-configs/primary-network/x-chain.mdx", title: "X-Chain Configs", description: "This page describes the configuration options available for the X-Chain.", contentUrl: "https://github.com/ava-labs/avalanchego/blob/master/vms/avm/", From 5864110d97ead53346b2d0caf6ef472c7e2cade5 Mon Sep 17 00:00:00 2001 From: Owen Date: Wed, 19 Nov 2025 22:26:20 -0500 Subject: [PATCH 03/19] cleanup --- app/api/latest-blogs/route.ts | 33 +++++ app/layout-wrapper.client.tsx | 16 ++- app/layout.config.tsx | 78 +++++++---- components/ai/search.tsx | 139 +++++++++++--------- components/landing/globe.tsx | 2 +- components/landing/hero.tsx | 26 ++-- components/navigation/dynamic-blog-menu.tsx | 57 ++++++++ components/navigation/footer.tsx | 51 +++---- components/ui/chatbot.tsx | 35 ++--- public/avax-gpt.png | Bin 0 -> 1423915 bytes 10 files changed, 287 insertions(+), 150 deletions(-) create mode 100644 app/api/latest-blogs/route.ts create mode 100644 components/navigation/dynamic-blog-menu.tsx create mode 100644 public/avax-gpt.png diff --git a/app/api/latest-blogs/route.ts b/app/api/latest-blogs/route.ts new file mode 100644 index 00000000000..ed9a4005080 --- /dev/null +++ b/app/api/latest-blogs/route.ts @@ -0,0 +1,33 @@ +import { NextResponse } from 'next/server'; +import { blog } from '@/lib/source'; + +export const dynamic = 'force-static'; +export const revalidate = 3600; // Revalidate every hour + +export async function GET() { + try { + const blogPages = [...blog.getPages()] + .sort( + (a, b) => + new Date((b.data.date as string) ?? b.url).getTime() - + new Date((a.data.date as string) ?? a.url).getTime() + ) + .slice(0, 2); + + const latestBlogs = blogPages.map((page) => ({ + title: page.data.title || 'Untitled', + description: page.data.description || '', + url: page.url, + date: + page.data.date instanceof Date + ? page.data.date.toISOString() + : (page.data.date as string) || '', + })); + + return NextResponse.json(latestBlogs); + } catch (error) { + console.error('Error fetching latest blogs:', error); + return NextResponse.json([], { status: 500 }); + } +} + diff --git a/app/layout-wrapper.client.tsx b/app/layout-wrapper.client.tsx index 169a2d13b36..ff91040c110 100644 --- a/app/layout-wrapper.client.tsx +++ b/app/layout-wrapper.client.tsx @@ -4,6 +4,7 @@ import { HomeLayout } from 'fumadocs-ui/layouts/home'; import type { ReactNode } from 'react'; import type { BaseLayoutProps } from 'fumadocs-ui/layouts/shared'; import { ActiveNavHighlighter } from '@/components/navigation/active-nav-highlighter'; +import { useDynamicBlogMenu } from '@/components/navigation/dynamic-blog-menu'; interface LayoutWrapperProps { children: ReactNode; @@ -11,10 +12,23 @@ interface LayoutWrapperProps { } export function LayoutWrapper({ children, baseOptions }: LayoutWrapperProps) { + const dynamicBlogMenu = useDynamicBlogMenu(); + + // Replace the blog menu with the dynamic one + const updatedOptions = { + ...baseOptions, + links: baseOptions.links?.map(link => { + if (link && typeof link === 'object' && 'text' in link && link.text === 'Blog') { + return dynamicBlogMenu; + } + return link; + }), + }; + return ( <> - {children} + {children} ); } diff --git a/app/layout.config.tsx b/app/layout.config.tsx index af6aa99d475..781626629ac 100644 --- a/app/layout.config.tsx +++ b/app/layout.config.tsx @@ -31,6 +31,7 @@ import { GraduationCap, BookOpen, Users, + FileText, } from 'lucide-react'; import Image from 'next/image'; import { UserButtonWrapper } from '@/components/login/user-button/UserButtonWrapper'; @@ -104,9 +105,45 @@ export const integrationsMenu: LinkItemType = { }; export const blogMenu: LinkItemType = { - type: 'main', + type: 'menu', text: 'Blog', url: '/guides', + items: [ + { + menu: { + banner: ( +
+ Blog Preview +
+ ), + className: 'md:row-span-2', + }, + icon: , + text: 'Latest Articles', + description: + 'Read the latest guides, tutorials, and insights from the Avalanche ecosystem.', + url: '/guides', + }, + { + icon: , + text: 'Browse All Posts', + description: + 'Explore our complete collection of articles, guides, and community content.', + url: '/guides', + menu: { + className: 'lg:col-start-2', + }, + }, + ], }; export const stats: LinkItemType = { @@ -458,7 +495,7 @@ export const eventsMenu: LinkItemType = { banner: (
Preview, + text: 'Community driven events', + description: + 'Check out and join the global meetups, workshops and events organized by Avalanche Team1', + url: 'https://lu.ma/Team1?utm_source=builder_hub', + }, + { icon: , text: 'Avalanche Calendar', description: 'Explore upcoming Avalanche events, meetups, and community gatherings. Stay connected with the latest happenings in the ecosystem.', url: 'https://lu.ma/calendar/cal-Igl2DB6quhzn7Z4', + menu: { + className: 'lg:col-start-3 lg:row-start-1', + }, }, { + icon: , + text: 'Campus Connect', + description: + 'Discover opportunities for students and educators to explore blockchain technology and join our community of builders.', + url: '/university', menu: { - banner: ( -
- Preview -
- ), - className: 'md:row-span-2', + className: 'lg:col-start-3 lg:row-start-2', }, - icon: , - text: 'Community driven events', - description: - 'Check out and join the global meetups, workshops and events organized by Avalanche Team1', - url: 'https://lu.ma/Team1?utm_source=builder_hub', }, ], }; @@ -529,6 +562,5 @@ export const baseOptions: BaseLayoutProps = { integrationsMenu, userMenu, blogMenu, - universityMenu ], }; diff --git a/components/ai/search.tsx b/components/ai/search.tsx index c9607fb2201..6d7d7e68962 100644 --- a/components/ai/search.tsx +++ b/components/ai/search.tsx @@ -13,7 +13,7 @@ import { useRef, useState, } from 'react'; -import { Loader2, RefreshCw, Send, X, User, Bot, Sparkles, StopCircle, HelpCircle, ChevronRight, Maximize2, Minimize2 } from 'lucide-react'; +import { Loader2, RefreshCw, Send, X, User, Bot, Sparkles, StopCircle, HelpCircle, ChevronRight, Maximize2, Minimize2, ArrowRight } from 'lucide-react'; import defaultMdxComponents from 'fumadocs-ui/mdx'; import { cn } from '../../lib/cn'; import { buttonVariants } from '../ui/button'; @@ -100,15 +100,16 @@ function SearchAIInput(props: FormHTMLAttributes) {
-
+
{ setInput(e.target.value); @@ -123,20 +124,20 @@ function SearchAIInput(props: FormHTMLAttributes) {
@@ -223,7 +224,13 @@ const roleName: Record = { const roleIcon: Record = { user: , - assistant: , + assistant: ( + AI + ), }; function parseFollowUpQuestions(content: string): string[] { @@ -261,30 +268,23 @@ function SuggestedFollowUps({ questions, onQuestionClick }: { if (questions.length === 0) return null; return ( -
-

- Related topics you might find helpful: +

+

+ Suggested

-
+
{questions.map((question, index) => ( ))}
@@ -515,7 +515,7 @@ export default function AISearch(props: DialogProps & { onToolSelect?: (toolId: "transition-all duration-300" )} > -
+
setViewMode('big')} /> @@ -534,11 +534,11 @@ export default function AISearch(props: DialogProps & { onToolSelect?: (toolId: aria-describedby={undefined} className={cn( "fixed inset-4 md:inset-auto md:left-1/2 md:top-1/2 md:-translate-x-1/2 md:-translate-y-1/2 z-50", - selectedTool && !isMobile ? "md:max-w-[1400px] md:w-[95vw]" : "md:max-w-2xl md:w-[90vw]", + selectedTool && !isMobile ? "md:max-w-[1600px] md:w-[95vw]" : "md:max-w-5xl md:w-[90vw]", "md:h-[85vh] max-h-[90vh] focus-visible:outline-none data-[state=closed]:animate-fd-fade-out data-[state=open]:animate-fd-fade-in transition-all duration-300" )} > -
+
{/* Desktop view - side by side */}
void }) { return (
-
- +
+ AI AI Assistant
@@ -610,17 +614,19 @@ function SmallViewContent({ onExpand }: { onExpand: () => void }) { {messages.length === 0 ? ( -
-
-
- +
+
+ AI +

How can I help?

+

+ Ask me anything about Avalanche +

+
-

How can I help?

-

- Ask me anything about Avalanche -

-
-
) : (
{messages.map((item, index) => ( @@ -640,7 +646,11 @@ function SmallViewContent({ onExpand }: { onExpand: () => void }) { {status === 'streaming' && messages[messages.length - 1]?.role === 'user' && (
- + AI
@@ -703,8 +713,12 @@ function Content({ onToolReference, onCollapse }: { onToolReference?: (toolId: s return (
-
- +
+ AI AI Assistant
@@ -737,36 +751,31 @@ function Content({ onToolReference, onCollapse }: { onToolReference?: (toolId: s
-
- -
+ AI

How can I help you today?

Ask me anything about the documentation or get help with your code.

-
+
{suggestedQuestions.map((question, index) => ( ))}
@@ -787,7 +796,11 @@ function Content({ onToolReference, onCollapse }: { onToolReference?: (toolId: s {isLoading && messages[messages.length - 1]?.role === 'user' && (
- + AI
diff --git a/components/landing/globe.tsx b/components/landing/globe.tsx index 157dd7c8b20..04f213b95fb 100644 --- a/components/landing/globe.tsx +++ b/components/landing/globe.tsx @@ -17,7 +17,7 @@ export const Sponsors = () => { { name: "Avalanche", image: "https://images.ctfassets.net/gcj8jwzm6086/5VHupNKwnDYJvqMENeV7iJ/3e4b8ff10b69bfa31e70080a4b142cd0/avalanche-avax-logo.svg", - link: "https://www.avax.network/", + link: "/docs/primary-network", type: "Primary" }, // Primary networks diff --git a/components/landing/hero.tsx b/components/landing/hero.tsx index 2838bdc5fd6..f831c765691 100644 --- a/components/landing/hero.tsx +++ b/components/landing/hero.tsx @@ -200,12 +200,11 @@ function RotatingText() { // Extract Background Component export function HeroBackground() { return ( -
+
{/* Premium Background */} -
+
{/* Subtle grid overlay */}
-
); @@ -238,10 +237,10 @@ export default function Hero() {
{/* CTA Buttons */} -
+
Start Learning @@ -249,21 +248,20 @@ export default function Hero() { Build -
- - {/* AI Assistant */} -
- + +
+ +
diff --git a/components/navigation/dynamic-blog-menu.tsx b/components/navigation/dynamic-blog-menu.tsx new file mode 100644 index 00000000000..af6aacee517 --- /dev/null +++ b/components/navigation/dynamic-blog-menu.tsx @@ -0,0 +1,57 @@ +"use client"; + +import { useEffect, useState } from 'react'; +import { type LinkItemType } from 'fumadocs-ui/layouts/docs'; +import { BookOpen, FileText, ArrowUpRight } from 'lucide-react'; +import Image from 'next/image'; + +interface BlogPost { + title: string; + description: string; + url: string; + date: string; +} + +export function useDynamicBlogMenu(): LinkItemType { + const [latestBlogs, setLatestBlogs] = useState([]); + + useEffect(() => { + fetch('/api/latest-blogs') + .then(res => res.json()) + .then(data => setLatestBlogs(data)) + .catch(err => console.error('Failed to fetch latest blogs:', err)); + }, []); + + const blogItems: any[] = []; + + // Add dynamic blog posts + if (latestBlogs.length > 0) { + latestBlogs.forEach((post, index) => { + blogItems.push({ + icon: , + text: post.title, + description: post.description.length > 100 + ? post.description.substring(0, 100) + '...' + : post.description, + url: post.url, + } as any); + }); + } + + // Add "Browse All" link + blogItems.push({ + icon: , + text: 'Browse All Posts', + description: + 'Explore our complete collection of articles, guides, and community content.', + url: '/guides', + } as any); + + return { + type: 'menu', + text: 'Blog', + url: '/guides', + items: blogItems, + }; +} + diff --git a/components/navigation/footer.tsx b/components/navigation/footer.tsx index 5edd33262ed..a892cadb49d 100644 --- a/components/navigation/footer.tsx +++ b/components/navigation/footer.tsx @@ -39,21 +39,21 @@ export function Footer() { }; return ( -