diff --git a/app/(home)/page.tsx b/app/(home)/page.tsx
index a535b71c..b16ca8c4 100644
--- a/app/(home)/page.tsx
+++ b/app/(home)/page.tsx
@@ -1,29 +1,6 @@
-import { AcademicCapIcon, ChatBubbleLeftRightIcon, CloudArrowUpIcon, GiftIcon, LockClosedIcon, ServerIcon } from '@heroicons/react/20/solid'
-
 import COURSES from '@/content/courses';
 import Link from 'next/link';
 
-
-const features = [
-  {
-    name: 'Earn an Avalanche Academy Certificate.',
-    description: 'Showcase your Avalanche Academy accomplishments on your CV and platforms like LinkedIn, X, and more.',
-    icon: AcademicCapIcon,
-  },
-  {
-    name: 'Join the Avalanche Community.',
-    description:
-      'Get connected with other Avalanche builders and like-minded individuals passionate about Avalanche.',
-    icon: ChatBubbleLeftRightIcon,
-  },
-  {
-    name: 'Get Rewards.',
-    description: 'Top performing students can earn benefits, such as exclusive Avalanche Merchandise, complimentary event tickets, and additional privileges.',
-    icon: GiftIcon,
-  },
-]
-
-
 export default function HomePage(): React.ReactElement {
   return (
     <>
diff --git a/app/hackathon/layout.tsx b/app/hackathon/layout.tsx
new file mode 100644
index 00000000..a15489ac
--- /dev/null
+++ b/app/hackathon/layout.tsx
@@ -0,0 +1,15 @@
+import { Layout } from 'fumadocs-ui/layout';
+import type { ReactNode } from 'react';
+import { Footer } from '@/components/footer';
+import { baseOptions } from '@/app/layout.config';
+
+export default function HomeLayout({
+  children,
+}: {
+  children: ReactNode;
+}): React.ReactElement {
+  return <Layout {...baseOptions}>
+    {children}
+    <Footer />
+    </Layout>;
+}
diff --git a/app/hackathon/page.tsx b/app/hackathon/page.tsx
new file mode 100644
index 00000000..246f9c34
--- /dev/null
+++ b/app/hackathon/page.tsx
@@ -0,0 +1,362 @@
+"use client"
+import React, { useState, ReactNode } from "react";
+import Link from 'next/link';
+import { ArrowUpRight, Code, Link as Zap, Link2, Lightbulb, X, Book, Users, SquareTerminal } from 'lucide-react';
+import PartnerTracks from './partners';
+import { buttonVariants } from '@/components/ui/button';
+
+const Card = ({ children, className = "", onClick = () => {} }: { children: ReactNode; className?: string; onClick?: () => void }) => (
+  <div className={`bg-white dark:bg-gray-800 rounded-lg shadow-md overflow-hidden ${className}`} onClick={onClick}>
+    {children}
+  </div>
+);
+
+const Badge = ({ children, className = "" }: { children: React.ReactNode; className?: string }) => (
+  <span className={`inline-block px-2 py-1 text-sm font-semibold rounded-full ${className}`}>
+    {children}
+  </span>
+);
+
+interface Resource {
+  name: string;
+  url: string;
+}
+
+interface Track {
+  id: string;
+  title: string;
+  description: string;
+  difficulty: 'Beginner' | 'Intermediate' | 'Advanced' | 'Open';
+  color: string;
+  icon: React.ReactNode;
+  challengeDetails?: string[];
+  technologies?: { [key: string]: string | { description: string; skills?: string } };
+  examples?: string[];
+  resources?: Resource[];
+}
+
+const Modal: React.FC<{ isOpen: boolean; onClose: () => void; track: Track }> = ({ isOpen, onClose, track }) => {
+  if (!isOpen) return null;
+
+  return (
+    <div className="fixed inset-0 bg-black bg-opacity-50 z-50 flex justify-center items-center p-4">
+      <div className="bg-white dark:bg-gray-800 rounded-lg max-w-3xl w-full max-h-[90vh] overflow-y-auto">
+        <div className="sticky top-0 bg-white dark:bg-gray-800 z-10 flex justify-between items-center p-6 border-b dark:border-gray-700">
+          <div className="flex items-center">
+            {track.icon}
+            <h2 className="text-2xl font-bold text-gray-800 dark:text-gray-200 ml-3">{track.title}</h2>
+          </div>
+          <button onClick={onClose} className="text-gray-500 hover:text-gray-700">
+            <X size={24} />
+          </button>
+        </div>
+        <div className="p-6">
+          <p className="text-gray-600 dark:text-gray-400 mb-6 text-lg">{track.description}</p>
+          
+          {track.challengeDetails && track.challengeDetails.length > 0 && (
+            <Section title="Challenge Details">
+              <ul className="list-disc pl-5 space-y-2">
+                {track.challengeDetails.map((detail, index) => (
+                  <li key={index} className="text-gray-600 dark:text-gray-400">{detail}</li>
+                ))}
+              </ul>
+            </Section>
+          )}
+          
+          {track.technologies && Object.keys(track.technologies).length > 0 && (
+            <Section title="Technologies">
+              {Object.entries(track.technologies).map(([name, details], index) => (
+                <div key={index} className="mb-4">
+                  <h4 className="font-semibold text-gray-800 dark:text-gray-200">{name}</h4>
+                  <p className="text-gray-600 dark:text-gray-400">
+                    {typeof details === 'string' ? details : details.description}
+                  </p>
+                  {typeof details !== 'string' && details.skills && (
+                    <p className="text-sm text-gray-500 mt-1">Skills required: {details.skills}</p>
+                  )}
+                </div>
+              ))}
+            </Section>
+          )}
+          
+          {track.examples && track.examples.length > 0 && (
+            <Section title="Examples">
+              <ul className="list-disc pl-5 space-y-2">
+                {track.examples.map((example, index) => (
+                  <li key={index} className="text-gray-600 dark:text-gray-400">{example}</li>
+                ))}
+              </ul>
+            </Section>
+          )}
+          
+          {track.resources && track.resources.length > 0 && (
+            <Section title="Recommended Resources">
+              <ul className="list-disc pl-5 space-y-2">
+                {track.resources.map((resource, index) => (
+                  <li key={index}>
+                    <Link 
+                      href={resource.url} 
+                      className="text-blue-600 hover:underline"
+                      target="_blank"
+                      rel="noopener noreferrer"
+                    >
+                      {resource.name}
+                    </Link>
+                  </li>
+                ))}
+              </ul>
+            </Section>
+          )}
+        </div>
+      </div>
+    </div>
+  );
+};
+
+const Section: React.FC<{ title: string; children: React.ReactNode }> = ({ title, children }) => (
+  <div className="mb-6">
+    <h3 className="text-xl font-semibold mb-3 text-gray-800 dark:text-gray-200 border-b pb-2 dark:border-gray-700">{title}</h3>
+    {children}
+  </div>
+);
+
+const TrackCard: React.FC<{ track: Track }> = ({ track }) => {
+  const [isModalOpen, setIsModalOpen] = useState(false);
+
+  const badgeColors = {
+    'Beginner': 'bg-emerald-100 text-emerald-800 dark:bg-emerald-900 dark:text-emerald-100',
+    'Intermediate': 'bg-amber-100 text-amber-800 dark:bg-amber-900 dark:text-amber-100',
+    'Advanced': 'bg-rose-100 text-rose-800 dark:bg-rose-900 dark:text-rose-100',
+    'Open': 'bg-indigo-100 text-indigo-800 dark:bg-indigo-900 dark:text-indigo-100'
+  };
+
+  return (
+    <>
+      <div 
+        className={`group bg-white dark:bg-gray-800 rounded-lg shadow-md overflow-hidden h-full flex flex-col relative cursor-pointer transition-all duration-300 ease-in-out hover:shadow-xl hover:scale-102 border-l-4 ${track.color}`}
+        onClick={() => setIsModalOpen(true)}
+      >
+        <div className="absolute top-3 right-3 text-gray-400 transition-all duration-300 ease-in-out group-hover:text-blue-600">
+          <ArrowUpRight size={28} className="transform transition-transform duration-300 ease-in-out group-hover:translate-x-1 group-hover:-translate-y-1"/>
+        </div>
+        <div className="p-6 flex-grow">
+          <div className="flex items-center mb-4">
+            <div className={`p-2 rounded-full ${track.color} bg-opacity-20 mr-3`}>
+              {track.icon}
+            </div>
+            <h3 className="text-2xl font-bold text-gray-800 dark:text-gray-200">{track.title}</h3>
+          </div>
+          <p className="text-gray-600 dark:text-gray-400 mb-4 line-clamp-4">{track.description}</p>
+          <Badge className={`mb-2 ${badgeColors[track.difficulty]}`}>
+            {track.difficulty}
+          </Badge>
+        </div>
+      </div>
+
+      <Modal isOpen={isModalOpen} onClose={() => setIsModalOpen(false)} track={track} />
+    </>
+  );
+};
+
+export default function HackathonPage() {
+  const tracks: Track[] = [
+    {
+      id: 'build',
+      title: 'Build a Product',
+      description: "This track challenges builders to develop impactful use cases that leverage Avalanche's full tech stack. Participants will create practical applications addressing real-world problems with Avalanche technology.",
+      difficulty: 'Intermediate',
+      color: 'border-blue-500 text-blue-700',
+      icon: <Zap size={24} className="text-blue-500" />,
+      challengeDetails: [
+        'Create practical applications that address real-world problems',
+        'Demonstrate the versatility and power of Avalanche',
+        'Focus on real-world use cases with significant impact potential'
+      ],
+      technologies: {
+        'ICTT and Teleporter': { description: 'Cross-chain communication protocols for data and token transfers across different Avalanche L1s', skills: 'Solidity experience' },
+        'Glacier & Webhooks': { description: 'Create dashboards, enhance data visualization and bring insightful content to your users by reading on-chain indexed data', skills: 'API usage' },
+        'Avalanche L1s': { description: 'Deploy your own Layer 1 blockchain to meet diverse technical requirements and reach scalability', skills: 'Interact with CLI, or using AvaCloud (no code)' },
+        'Custom VMs': { description: 'Innovate with custom virtual machines and EVM-precompiles to enable new types of computations and functionalities on the blockchain', skills: 'Golang, Solidity' },
+        'HyperSDK': { description: 'Create your own Hyper-Performant Virtual Machine', skills: 'Golang, Solidity' }
+      },
+      examples: [
+        'Real World Assets (RWA)',
+        'SocialFi',
+        'DeFi',
+        'Institutional Use Cases',
+        'Supply Chain Management',
+        'Gaming'
+      ],
+      resources: [
+        { name: 'Avalanche Starter Kit', url: 'https://github.com/ava-labs/avalanche-starter-kit' },
+        { name: 'HyperSDK Starter Kit', url: 'https://github.com/ava-labs/hypersdk-starter-kit' },
+        { name: 'BuilderKit', url: 'https://www.npmjs.com/package/@0xstt/builderkit' },
+        { name: 'Faucet', url: 'https://core.app/tools/testnet-faucet/?subnet=c&token=c' }
+      ]
+    },
+    {
+      id: 'interop',
+      title: 'Interoperability',
+      description: "Developers will design seamless, scalable solutions for cross-chain interoperability. Using Avalanche's Interchain Messaging Protocol (ICM) and tools, builders will enable efficient multi-chain data transfers.",
+      difficulty: 'Advanced',
+      color: 'border-green-500 text-green-700',
+      icon: <Link2 size={24} className="text-green-500" />,
+      examples: [
+        'Enable C-chain deployed services in L1s with ICM',
+        'ICM support for the HyperSDK',
+        'Chain abstraction asset transfers, modify the EVM in a way to improve Multichain User Experience',
+        'USDC to L1 via an On-Ramp on the C-Chain and ICTT'
+      ],
+      resources: [
+        { name: 'ICM Course', url: 'https://academy.avax.network/course/interchain-messaging' },
+        { name: 'ICTT Course', url: 'https://academy.avax.network/course/interchain-token-transfer' },
+        { name: 'AWM Relayer Repo', url: 'https://github.com/ava-labs/awm-relayer' }
+      ]
+    },
+    {
+      id: 'advanced',
+      title: 'Advanced Technical Development',
+      description: "This track invites participants to push Avalanche's technical boundaries. Focusing on performance, cryptography, and scalability, developers will explore cutting-edge blockchain solutions without business constraints.",
+      difficulty: 'Advanced',
+      color: 'border-purple-500 text-purple-700',
+      icon: <Code size={24} className="text-purple-500" />,
+      challengeDetails: [
+        'Performance Optimization: Improve the speed and efficiency of blockchain operations, focusing on reducing latency and increasing throughput',
+        'Scalability Solutions: Create innovative solutions to scale the Avalanche network, addressing challenges related to consensus, data storage, and node management',
+        'Developer Tools: Build advanced tools and frameworks to support developers in building, testing, and deploying blockchain applications more efficiently'
+      ],
+      examples: [
+        'Validator manager dashboard (ACP-77): PoA, PoS, dPoS',
+        'Build a DA solution with HyperSDK',
+        'Gas Sponsorship',
+        'Cryptographic enablements such as ZK proofs, etc.'
+      ],
+      resources: [
+        { name: 'HyperSDK Starter Kit', url: 'https://github.com/ava-labs/hypersdk-starter-kit' },
+        { name: 'Validator Manager Contracts', url: 'https://github.com/ava-labs/teleporter/tree/validator-manager/contracts/validator-manager' },
+        { name: 'Faucet', url: 'https://core.app/tools/testnet-faucet/?subnet=c&token=c' }
+      ]
+    },
+    {
+      id: 'innovation',
+      title: 'Open Innovation',
+      description: "This track invites participants to push Avalanche's technical boundaries. Focusing on performance, cryptography, and scalability, developers will explore cutting-edge blockchain solutions without business constraints.",
+      difficulty: 'Open',
+      color: 'border-yellow-500 text-yellow-700',
+      icon: <Lightbulb size={24} className="text-yellow-500" />,
+      technologies: {
+        'Avalanche Stack': { description: 'Free use of all Avalanche technologies' }
+      },
+      challengeDetails: ["Any innovative solution using Avalanche's capabilities to address problems in various industries."]
+    },
+  ];
+
+  return (
+    <main className="container relative py-6">
+      <div className="py-12 sm:py-12">
+        <div className="mx-auto max-w-7xl px-6 lg:px-8">
+          <div className="mx-auto w-full lg:mx-0">
+            <h2 className="text-center text-5xl font-bold tracking-tight sm:text-10xl">Summit LATAM Hackathon</h2>
+            <p className="mt-12 text-center text-lg leading-8 text-muted-foreground">
+              At Avalanche, we believe in the power of technology to transform industries and solve real-world problems.
+              This hackathon aims to harness the potential of Avalanche's robust technology stack to address pressing issues and create scalable, practical solutions. 
+            </p>
+          </div>
+          <div className="flex items-center max-w-xl p-4 mx-auto mt-4 text-sm rounded-lg group" style={{ justifyContent: "center" }}>
+            <Link href="https://avax.typeform.com/to/mUSRGxjh" className={buttonVariants({ size: 'lg', variant: 'default' })}>
+              Click Here to Submit your Project <ArrowUpRight size={20} style={{ color: "inherit" }}/>
+            </Link>
+          </div>
+        </div>
+      </div>
+
+      <div className="py-6 sm:py-6">
+        <div className="mx-auto max-w-7xl px-6 lg:px-8">
+          <Card className="bg-gradient-to-r from-yellow-100 to-yellow-200 dark:from-yellow-800 dark:to-yellow-900">
+            <div className="p-8 text-center">
+              <h3 className="text-3xl font-bold mb-4 flex justify-center items-center gap-2 text-yellow-600 dark:text-yellow-300">
+                <span>🏆</span> Prizes
+              </h3>
+              <div className="text-5xl font-extrabold text-gray-800 dark:text-gray-100 mb-4">
+                $50,000 Prize Pool
+              </div>
+              <p className="text-xl text-gray-700 dark:text-gray-300 mb-6">
+                Distributed across all tracks based on project impact and innovation.
+              </p>
+              <div className="mb-6">
+                <p className="text-lg text-gray-600 dark:text-gray-400">
+                  Top participants may earn a spot in the <strong>Codebase Incubator Program</strong>, gaining access to exclusive resources and mentorship.
+                </p>
+              </div>
+              <Link href="https://codebase.avax.network/" className="inline-block px-6 py-3 bg-yellow-500 text-white rounded-full shadow hover:bg-yellow-600 transition">
+                Learn More About Codebase Incubator →
+              </Link>
+            </div>
+          </Card>
+        </div>
+      </div>
+
+      <div className="py-12 sm:py-12">
+        <div className="mx-auto max-w-7xl px-6 lg:px-8">
+          <h2 className="text-3xl font-bold mb-6 text-gray-800 dark:text-gray-200">Hackathon Tracks</h2>
+          <div className="grid gap-6 md:grid-cols-2">
+            {tracks.map((track) => (
+              <TrackCard key={track.id} track={track} />
+            ))}
+          </div>
+        </div>
+      </div>
+
+      <div className="py-8 sm:py-8">
+        <div className="mx-auto max-w-7xl px-6 lg:px-8">
+          <PartnerTracks />
+        </div>
+      </div>
+
+      <div className="py-4 sm:py-4">
+        <div className="mx-auto max-w-7xl px-6 lg:px-8">
+          <h2 className="text-3xl font-semibold mb-6 text-gray-800 dark:text-gray-200">Resources and Support</h2>
+          <div className="grid gap-6 md:grid-cols-3">
+            <Card>
+              <div className="p-6">
+                <Users className="h-6 w-6 text-blue-500 mb-4" />
+                <h3 className="text-xl font-semibold mb-3 text-gray-800 dark:text-gray-200">Technical Mentorship</h3>
+                <p className="text-gray-600 dark:text-gray-400">The DevRel team at Ava Labs will be available to guide teams on various technologies throughout the hackathon.</p>
+              </div>
+            </Card>
+            <Card>
+              <div className="p-6">
+                <Book className="h-6 w-6 text-green-500 mb-4" />
+                <h3 className="text-xl font-semibold mb-3 text-gray-800 dark:text-gray-200">Workshops</h3>
+                <p className="text-gray-600 dark:text-gray-400">Attend hands-on workshops on Avalanche technologies, cross-chain communication, blockchain customization, and data visualization.</p>
+              </div>
+            </Card>
+            <Card>
+              <div className="p-6">
+                <SquareTerminal className="h-6 w-6 text-green-500 mb-4" />
+                <h3 className="text-xl font-semibold mb-3 text-gray-800 dark:text-gray-200">Developer Resources</h3>
+                <ul className="space-y-3 text-gray-600 dark:text-gray-400">
+                  <li>
+                    <Link href="https://docs.avax.network" className="flex items-center text-blue-600 dark:text-blue-400 hover:underline">
+                      Avalanche Docs
+                    </Link>
+                  </li>
+                  <li>
+                    <Link href="https://academy.avax.network" className="flex items-center text-blue-600 dark:text-blue-400 hover:underline">
+                      Avalanche Academy
+                    </Link>
+                  </li>
+                  <li>
+                    <Link href="https://core.app/tools/testnet-faucet/?subnet=c&token=c" className="flex items-center text-blue-600 dark:text-blue-400 hover:underline">
+                      Avalanche Faucet
+                    </Link>
+                  </li>
+                </ul>
+              </div>
+            </Card>
+          </div>
+        </div>
+      </div>
+    </main>
+  );
+}
\ No newline at end of file
diff --git a/app/hackathon/partners.tsx b/app/hackathon/partners.tsx
new file mode 100644
index 00000000..b5cbd3e3
--- /dev/null
+++ b/app/hackathon/partners.tsx
@@ -0,0 +1,212 @@
+import React, { useState } from 'react';
+import { ArrowUpRight, X } from 'lucide-react';
+
+interface PartnerTrack {
+  id: string;
+  name: string;
+  prize: string;
+  description: string;
+  tracks: {
+    name: string;
+    bounty: string;
+    description: string;
+    examples?: string[];
+  }[];
+  eligibilityRequirements?: string[];
+  resources?: { name: string; url: string }[]; // New field for resources
+}
+
+const Badge = ({ children, className = "" }: { children: React.ReactNode; className?: string }) => (
+  <span className={`inline-block px-2 py-1 text-sm font-semibold rounded-full ${className}`}>
+    {children}
+  </span>
+);
+
+const Section: React.FC<{ title: string; children: React.ReactNode }> = ({ title, children }) => (
+  <div className="mb-6">
+    <h3 className="text-xl font-semibold mb-3 text-gray-800 dark:text-gray-200 border-b pb-2 dark:border-gray-700">{title}</h3>
+    {children}
+  </div>
+);
+
+const renderDescription = (text: string) => {
+  return text.split('\n').map((line, index) => (
+    <React.Fragment key={index}>
+      {line}
+      {index < text.split('\n').length - 1 && <br />}
+    </React.Fragment>
+  ));
+};
+
+const Modal: React.FC<{ isOpen: boolean; onClose: () => void; track: PartnerTrack }> = ({ isOpen, onClose, track }) => {
+  if (!isOpen) return null;
+
+  return (
+    <div className="fixed inset-0 bg-black bg-opacity-50 z-50 flex justify-center items-center p-4">
+      <div className="bg-white dark:bg-gray-800 rounded-lg max-w-3xl w-full max-h-[90vh] overflow-y-auto">
+        <div className="sticky top-0 bg-white dark:bg-gray-800 z-10 flex justify-between items-center p-6 border-b dark:border-gray-700">
+          <h2 className="text-2xl font-bold text-gray-800 dark:text-gray-200">{track.name}</h2>
+          <button onClick={onClose} className="text-gray-500 hover:text-gray-700">
+            <X size={24} />
+          </button>
+        </div>
+        <div className="p-6">
+          <p className="text-gray-600 dark:text-gray-400 mb-6 text-lg whitespace-pre-line">
+            {renderDescription(track.description)}
+          </p>
+          
+          <Section title="Prize">
+            <p className="text-blue-600 font-semibold">{track.prize}</p>
+          </Section>
+          
+          {track.tracks.map((subTrack, index) => (
+            <Section key={index} title={subTrack.name}>
+              <p className="text-blue-600 font-semibold mb-2">Bounty: {subTrack.bounty}</p>
+              <p className="text-gray-600 dark:text-gray-400 mb-4 whitespace-pre-line">
+                {renderDescription(subTrack.description)}
+              </p>
+              {subTrack.examples && subTrack.examples.length > 0 && (
+                <div>
+                  <h4 className="font-semibold text-gray-700 dark:text-gray-300 mb-2">Examples:</h4>
+                  <ul className="list-disc pl-5 space-y-1">
+                    {subTrack.examples.map((example, idx) => (
+                      <li key={idx} className="text-gray-600 dark:text-gray-400 whitespace-pre-line">
+                        {renderDescription(example)}
+                      </li>
+                    ))}
+                  </ul>
+                </div>
+              )}
+            </Section>
+          ))}
+          
+          {track.eligibilityRequirements && track.eligibilityRequirements.length > 0 && (
+            <Section title="Eligibility Requirements">
+              <ul className="list-disc pl-5 space-y-1">
+                {track.eligibilityRequirements.map((req, index) => (
+                  <li key={index} className="text-gray-600 dark:text-gray-400 whitespace-pre-line">
+                    {renderDescription(req)}
+                  </li>
+                ))}
+              </ul>
+            </Section>
+          )}
+
+          {/* New section for resources */}
+          {track.resources && track.resources.length > 0 && (
+            <Section title="Resources">
+              <ul className="list-disc pl-5 space-y-1">
+                {track.resources.map((resource, index) => (
+                  <li key={index} className="text-gray-600 dark:text-gray-400">
+                    <a href={resource.url} target="_blank" rel="noopener noreferrer" className="text-blue-500 hover:underline">
+                      {resource.name}
+                    </a>
+                  </li>
+                ))}
+              </ul>
+            </Section>
+          )}
+        </div>
+      </div>
+    </div>
+  );
+};
+
+const PartnerTrackCard: React.FC<{ track: PartnerTrack }> = ({ track }) => {
+  const [isModalOpen, setIsModalOpen] = useState(false);
+
+  return (
+    <>
+      <div 
+        className="group bg-white dark:bg-gray-800 rounded-lg shadow-md overflow-hidden h-full flex flex-col relative cursor-pointer transition-all duration-300 ease-in-out hover:shadow-xl hover:scale-102"
+        onClick={() => setIsModalOpen(true)}
+      >
+        <div className="absolute top-3 right-3 text-gray-400 transition-all duration-300 ease-in-out group-hover:text-blue-600">
+          <ArrowUpRight 
+            size={28}
+            className="transform transition-transform duration-300 ease-in-out group-hover:translate-x-1 group-hover:-translate-y-1"
+          />
+        </div>
+        <div className="p-6 flex-grow">
+          <h3 className="text-2xl font-bold text-gray-800 dark:text-gray-200 mb-4">{track.name}</h3>
+          <Badge className="mb-4 bg-indigo-100 text-indigo-800 dark:bg-indigo-900 dark:text-indigo-100">{track.prize}</Badge>
+          <p className="text-gray-600 dark:text-gray-400 mb-4 line-clamp-3">{track.description}</p>
+        </div>
+      </div>
+
+      <Modal isOpen={isModalOpen} onClose={() => setIsModalOpen(false)} track={track} />
+    </>
+  );
+};
+
+const PartnerTracks: React.FC = () => {
+  const partnerTracks: PartnerTrack[] = [
+    {
+      id: 'chainlink',
+      name: 'Chainlink',
+      prize: '$20,000 in Prizes',
+      description: "Two tracks focused on Chainlink enabled Avalanche L1s and On-chain Finance on Avalanche. Leverage Chainlink's powerful oracle network to build innovative solutions on Avalanche.",
+      tracks: [
+        {
+          name: '1: Chainlink-enabled Avalanche L1s',
+          bounty: '$10,000 ($2,000 to the 5 best projects)',
+          description: "Build a decentralized application on an Avalanche L1 that makes use of a Chainlink service on Fuji, which is then brought onto the L1 using Avalanche Teleporter. Explore the possibilities of cross-chain communication and data transfer using Chainlink's advanced protocols.",
+          examples: [
+            'Deploy a game on an Avalanche L1 that stores its native assets as NFTs on Ethereum Sepolia for maximum censorship resistance. Use Chainlink CCIP to facilitate communications between Ethereum and Avalanche Fuji. Implement Teleporter for communication between Fuji and Avalanche L1.',
+            'Develop a DeFi protocol that combines liquidity across multiple blockchain ecosystems into an Avalanche L1. Utilize Chainlink CCIP for secure cross-chain data and asset transfers. Implement Teleporter for efficient communication between chains.',
+            'Create a SocialFi app on an Avalanche L1 that integrates with Web2 social platforms. Use Chainlink Functions on Fuji to connect to platforms like TikTok and Instagram. Fetch and analyze social metrics and analytic data to provide valuable insights to users.'
+          ]
+        },
+        {
+          name: '2: Onchain Finance on Avalanche',
+          bounty: '$10,000 ($2,000 to the 5 best projects)',
+          description: "Build innovative financial products and services that leverage the strengths of both Avalanche and Chainlink.\n\n 1. Tokenization or RWA protocol: Develop a protocol that brings real-world assets on-chain to the Avalanche ecosystem. Utilize Chainlink products like Functions and CCIP for secure and efficient data transfer and asset representation.\n\n2. Advanced financial instruments: Create cutting-edge perpetuals, options, or prediction markets on Avalanche. Combine Chainlink's high-speed Data Streams with Avalanche's rapid 1-second finality for ultra-responsive financial products."
+        }
+      ],
+      eligibilityRequirements: [
+        'Chainlink integration: Projects must use Chainlink in some form to make a state change on a blockchain. Simply reading from Chainlink data feeds is not sufficient.',
+        'Code visibility: All project code must be publicly viewable in a repository for judging purposes.',
+        'Documentation: Clearly document how Chainlink is used in your project description.',
+        'Verifiable implementation: Ensure that judges can easily locate and verify the Chainlink integration in your code. Merely stating an intention to use Chainlink is not valid.'
+      ],
+      resources: [
+        { name: 'Chainlink Documentation', url: 'https://docs.chain.link/' },
+        { name: 'Chainlink CCIP', url: 'https://chain.link/cross-chain' },
+        { name: 'Chainlink Functions', url: 'https://chain.link/functions' }
+      ]
+    },
+    {
+      id: 'thirdweb',
+      name: 'ThirdWeb',
+      prize: 'Credits worth $600 for Developers',
+      description: "Leverage ThirdWeb toolings to create Web3 solutions that make blockchain technology accessible and practical for everyone. Receive credits worth $600 for different ThirdWeb services.",
+      tracks: [
+        {
+          name: 'Web3 Solutions for Everyone',
+          bounty: '3 months Growth ($300) and Engine ($300) credit coupons',
+          description: "This track invites developers to build innovative Web3 applications or games utilizing ThirdWeb's cutting-edge tools. Participants will explore wallet integration and backend infrastructure to create seamless blockchain experiences that are accessible to all.\n\n1. Build an app or game with In-App Wallets for easy user onboarding.\n2. Implement Smart Wallets (Account Abstraction) to enhance user experience and security.\n3. Utilize ThirdWeb Engine to ensure scalable backend infrastructure for your application.\n\nBuild apps to onboard the next generation of users with seamless wallets experiences using In-App and Smart Wallets and scalable backends with Engine. "
+        }
+      ],
+      resources: [
+        { name: 'ThirdWeb Portal', url: 'https://portal.thirdweb.com/' },
+        { name: 'In-App Wallet', url: 'https://portal.thirdweb.com/connect/in-app-wallet/overview' },
+        { name: 'Account Abstraction', url: 'https://portal.thirdweb.com/connect/account-abstraction/overview' },
+        { name: 'Engine', url: 'https://portal.thirdweb.com/engine' },
+        { name: 'YouTube Videos', url: 'https://www.youtube.com/@thirdweb_' }
+      ]
+    }
+  ];
+
+  return (
+    <div className="mb-12">
+      <h2 className="text-3xl font-bold mb-6 text-gray-800 dark:text-gray-200">Partner Tracks</h2>
+      <div className="grid gap-6 md:grid-cols-2">
+        {partnerTracks.map((track) => (
+          <PartnerTrackCard key={track.id} track={track} />
+        ))}
+      </div>
+    </div>
+  );
+};
+
+export default PartnerTracks;
\ No newline at end of file
diff --git a/app/layout.config.tsx b/app/layout.config.tsx
index 594da185..6577b336 100644
--- a/app/layout.config.tsx
+++ b/app/layout.config.tsx
@@ -27,6 +27,10 @@ export const baseOptions: BaseLayoutProps = {
       text: 'Contribute',
       url: '/contribute',
     },
+    {
+      text: 'Hackathons',
+      url: '/hackathon',
+    },
   ],
 };
 
diff --git a/components/quizzes/courses/l1-tokenomics.json b/components/quizzes/courses/l1-tokenomics.json
deleted file mode 100644
index 35626a4d..00000000
--- a/components/quizzes/courses/l1-tokenomics.json
+++ /dev/null
@@ -1,137 +0,0 @@
-{
-    "201": {
-        "question": "Which function is used to allow another account to transfer tokens on your behalf?",
-        "options": [
-            "transfer()",
-            "approve()",
-            "transferFrom()",
-            "allowance()"
-        ],
-        "correctAnswers": [
-            1
-        ],
-        "hint": "This function sets an approval limit for token transfers by a third party.",
-        "explanation": "The approve() function allows another account to spend tokens on your behalf up to a specified amount.",
-        "chapter": "ERC-20 Tokens"
-    },
-    "202": {
-        "question": "What is the primary purpose of wrapping a native token into an ERC-20 token?",
-        "options": [
-            "To increase its supply",
-            "To burn the native token",
-            "To make the native token compatible with the ERC-20 standard",
-            "To mint more native tokens"
-        ],
-        "correctAnswers": [
-            2
-        ],
-        "hint": "Wrapping allows the native token to be used in decentralized applications that require ERC-20 tokens.",
-        "explanation": "The wrapping process makes native tokens (like ETH, AVAX) compatible with the ERC-20 standard, enabling their use in dApps and DeFi protocols.",
-        "chapter": "Wrapped Native Tokens"
-    },
-    "203": {
-        "question": "What is the primary advantage of using a custom native token in a blockchain?",
-        "options": [
-            "It automatically increases in value over time",
-            "It can only be used for test environments",
-            "It eliminates the need for validators",
-            "It allows for more control over transaction fees and tokenomics"
-        ],
-        "correctAnswers": [
-            3
-        ],
-        "hint": "Custom native tokens give developers flexibility in managing blockchain economics.",
-        "explanation": "A custom native token allows developers to control transaction fees, design tokenomics, and tailor the blockchain’s fee structure to meet specific needs.",
-        "chapter": "Custom Native Tokens"
-    },
-    "204": {
-        "question": "What is the AllowList used for when configuring the Native Minter Precompile?",
-        "options": [
-            "To set transaction fees for using the native token",
-            "To control which addresses are allowed to mint native tokens",
-            "To limit the total number of native tokens that can be minted",
-            "To freeze minting of native tokens"
-        ],
-        "correctAnswers": [
-            1
-        ],
-        "hint": "The allow list determines which addresses have permission to interact with the precompiled contract.",
-        "explanation": "The AllowList is used to specify which addresses have the permission to mint native tokens or manage the minting process.",
-        "chapter": "Activating Native Minter Precompile"
-    },
-    "205": {
-        "question": "What is the main advantage of a multi-chain ecosystem?",
-        "options": [
-            "It reduces the security of the blockchain.",
-            "It increases the gas fees.",
-            "It enables tokens and assets to be transferred across multiple blockchains.",
-            "It restricts interoperability between different blockchains."
-        ],
-        "correctAnswers": [
-            2
-        ],
-        "hint": "Think about the ability of assets and tokens to move freely across multiple chains.",
-        "explanation": "The key benefit of a multi-chain ecosystem is that it allows tokens, assets, and data to be transferred between different blockchains, promoting interoperability.",
-        "chapter": "Cross-Chain Ecosystems"
-    },
-    "206": {
-        "question": "What role does Avalanche play in enabling multi-chain ecosystems?",
-        "options": [
-            "It provides a single-chain environment for transactions.",
-            "It limits token usage to the native chain.",
-            "It supports seamless cross-chain communication with tools like L1s and ICTT.",
-            "It prevents interoperability between its L1s and other chains."
-        ],
-        "correctAnswers": [
-            2
-        ],
-        "hint": "Avalanche is known for its ability to support cross-chain communication and interoperability through its architecture.",
-        "explanation": "Avalanche's architecture, including its L1s and Interchain Token Transfers (ICTT), is designed to support seamless cross-chain communication and interoperability between different blockchain networks.",
-        "chapter": "Cross-Chain Ecosystems"
-    },
-    "207": {
-        "question": "Which contract must be granted minting rights for the ERC-20 token to be used as a native token on a new L1 chain?",
-        "options": [
-            "NativeTokenRemote contract",
-            "ERC-20 Home contract",
-            "ERC-712 contract",
-            "L1 governance contract"
-        ],
-        "correctAnswers": [
-            0
-        ],
-        "hint": "This contract mints native tokens on the destination chain after ERC-20 tokens are transferred.",
-        "explanation": "The NativeTokenRemote contract must be granted minting rights to allow the native token to be minted on the new L1 after ERC-20 tokens are transferred from the source chain.",
-        "chapter": "Use ERC-20 as Native Token"
-    },
-    "208": {
-        "question": "Why is collateralization important in transferring native tokens between L1 chains?",
-        "options": [
-            "It increases the supply of tokens on the C-Chain.",
-            "It ensures the total supply of tokens remains balanced across both chains.",
-            "It burns the tokens on the remote chain.",
-            "It locks the token permanently on the C-Chain."
-        ],
-        "correctAnswers": [
-            1
-        ],
-        "hint": "Collateralization ensures balance across chains during token transfers.",
-        "explanation": "Collateralization locks the transferred tokens on the source chain, ensuring that the minted tokens on the destination chain have an equivalent backing.",
-        "chapter": "Use ERC-20 as Native Token"
-    },
-    "209": {
-        "question": "What is the purpose of wrapping a native token on the C-Chain before transferring it to a new L1?",
-        "options": [
-            "To convert it into an ERC-721 token.",
-            "To prepare it for cross-chain transfer as an ERC-20 token.",
-            "To lock it in a smart contract and mint its representation on the new L1.",
-            "To burn the token and reduce its total supply."
-        ],
-        "correctAnswers": [
-            2
-        ],
-        "hint": "Wrapping a token creates a compatible version of it for cross-chain transfers.",
-        "explanation": "Wrapping the native token locks it on the C-Chain, allowing a compatible version of the token to be minted on the new L1, ensuring the cross-chain token transfer process.",
-        "chapter": "Use ERC-20 as Native Token"
-    }
-}
\ No newline at end of file
diff --git a/components/quizzes/quiz.tsx b/components/quizzes/quiz.tsx
index a3e1f84c..57bef300 100644
--- a/components/quizzes/quiz.tsx
+++ b/components/quizzes/quiz.tsx
@@ -6,7 +6,6 @@ import Image from 'next/image';
 import { cn } from '@/utils/cn';
 import { buttonVariants } from '@/components/ui/button';
 import quizData from './quizData.json';
-import l1TokenomicsQuestions from './courses/l1-tokenomics.json';
 
 interface QuizProps {
   quizId: string;
@@ -31,7 +30,6 @@ const Quiz: React.FC<QuizProps> = ({ quizId }) => {
     setIsClient(true);
     const all = {
       ...quizData.quizzes,
-      ...l1TokenomicsQuestions
     };
     const fetchedQuizInfo = all[quizId as keyof typeof quizData.quizzes];
     if (fetchedQuizInfo) {
diff --git a/components/quizzes/quizData.json b/components/quizzes/quizData.json
index 35793a51..5965501d 100644
--- a/components/quizzes/quizData.json
+++ b/components/quizzes/quizData.json
@@ -6,14 +6,22 @@
     },
     "l1-tokenomics": {
       "title": "L1 Tokenomics",
-      "quizzes": ["201", "202", "203", "204", "205", "206", "207", "208", "209"]
+      "quizzes": ["201", "202", "203", "204", "205", "206", "207", "208", "209", "210", "211", "212", "213", "214", "215"]
     },
     "interchain-token-transfer": {
       "title": "Interchain Token Transfer",
       "quizzes": ["118", "119", "120", "121", "122", "123", "124", "125", "126", "127"]
+    },
+    "interchain-messaging": {
+      "title": "Interchain Messaging",
+      "quizzes": ["301", "302", "303", "304", "305", "306", "307", "308", "309", "310", "311", "312", "313", "314", "315", "316"]
+    },
+    "multichain-architecture": {
+      "title": "Multichain Architecture",
+      "quizzes": ["401", "402", "403", "404", "405", "406", "407", "408", "409", "410"]
     }
-  },
-  "quizzes": {
+    },
+    "quizzes": {
     "101": {
       "question": "What is the underlying principle of the Avalanche Consensus family?",
       "options": [
@@ -353,6 +361,621 @@
       "correctAnswers": [0],
       "explanation": "Yes, there can be multiple TokenRemotes for a single TokenHome. This allows the same token to be bridged to multiple chains, enabling cross-chain interoperability and use cases across different blockchain networks.",
       "chapter": "Interchain Token Transfer"
+    },
+    "201": {
+      "question": "Which function is used to allow another account to transfer tokens on your behalf?",
+      "options": [
+          "transfer()",
+          "approve()",
+          "transferFrom()",
+          "allowance()"
+      ],
+      "correctAnswers": [
+          1
+      ],
+      "hint": "This function sets an approval limit for token transfers by a third party.",
+      "explanation": "The approve() function allows another account to spend tokens on your behalf up to a specified amount.",
+      "chapter": "ERC-20 Tokens"
+  },
+  "202": {
+      "question": "What is the primary purpose of wrapping a native token into an ERC-20 token?",
+      "options": [
+          "To increase its supply",
+          "To burn the native token",
+          "To make the native token compatible with the ERC-20 standard",
+          "To mint more native tokens"
+      ],
+      "correctAnswers": [
+          2
+      ],
+      "hint": "Wrapping allows the native token to be used in decentralized applications that require ERC-20 tokens.",
+      "explanation": "The wrapping process makes native tokens (like ETH, AVAX) compatible with the ERC-20 standard, enabling their use in dApps and DeFi protocols.",
+      "chapter": "Wrapped Native Tokens"
+  },
+  "203": {
+      "question": "What is the primary advantage of using a custom native token in a blockchain?",
+      "options": [
+          "It automatically increases in value over time",
+          "It can only be used for test environments",
+          "It eliminates the need for validators",
+          "It allows for more control over transaction fees and tokenomics"
+      ],
+      "correctAnswers": [
+          3
+      ],
+      "hint": "Custom native tokens give developers flexibility in managing blockchain economics.",
+      "explanation": "A custom native token allows developers to control transaction fees, design tokenomics, and tailor the blockchain’s fee structure to meet specific needs.",
+      "chapter": "Custom Native Tokens"
+  },
+  "204": {
+      "question": "What is the AllowList used for when configuring the Native Minter Precompile?",
+      "options": [
+          "To set transaction fees for using the native token",
+          "To control which addresses are allowed to mint native tokens",
+          "To limit the total number of native tokens that can be minted",
+          "To freeze minting of native tokens"
+      ],
+      "correctAnswers": [
+          1
+      ],
+      "hint": "The allow list determines which addresses have permission to interact with the precompiled contract.",
+      "explanation": "The AllowList is used to specify which addresses have the permission to mint native tokens or manage the minting process.",
+      "chapter": "Activating Native Minter Precompile"
+  },
+  "205": {
+      "question": "What is the main advantage of a multi-chain ecosystem?",
+      "options": [
+          "It reduces the security of the blockchain.",
+          "It increases the gas fees.",
+          "It enables tokens and assets to be transferred across multiple blockchains.",
+          "It restricts interoperability between different blockchains."
+      ],
+      "correctAnswers": [
+          2
+      ],
+      "hint": "Think about the ability of assets and tokens to move freely across multiple chains.",
+      "explanation": "The key benefit of a multi-chain ecosystem is that it allows tokens, assets, and data to be transferred between different blockchains, promoting interoperability.",
+      "chapter": "Cross-Chain Ecosystems"
+  },
+  "206": {
+      "question": "What role does Avalanche play in enabling multi-chain ecosystems?",
+      "options": [
+          "It provides a single-chain environment for transactions.",
+          "It limits token usage to the native chain.",
+          "It supports seamless cross-chain communication with tools like L1s and ICTT.",
+          "It prevents interoperability between its L1s and other chains."
+      ],
+      "correctAnswers": [
+          2
+      ],
+      "hint": "Avalanche is known for its ability to support cross-chain communication and interoperability through its architecture.",
+      "explanation": "Avalanche's architecture, including its L1s and Interchain Token Transfers (ICTT), is designed to support seamless cross-chain communication and interoperability between different blockchain networks.",
+      "chapter": "Cross-Chain Ecosystems"
+  },
+  "207": {
+      "question": "Which contract must be granted minting rights for the ERC-20 token to be used as a native token on a new L1 chain?",
+      "options": [
+          "NativeTokenRemote contract",
+          "ERC-20 Home contract",
+          "ERC-712 contract",
+          "L1 governance contract"
+      ],
+      "correctAnswers": [
+          0
+      ],
+      "hint": "This contract mints native tokens on the destination chain after ERC-20 tokens are transferred.",
+      "explanation": "The NativeTokenRemote contract must be granted minting rights to allow the native token to be minted on the new L1 after ERC-20 tokens are transferred from the source chain.",
+      "chapter": "Use ERC-20 as Native Token"
+  },
+  "208": {
+      "question": "Why is collateralization important in transferring native tokens between L1 chains?",
+      "options": [
+          "It increases the supply of tokens on the C-Chain.",
+          "It ensures the total supply of tokens remains balanced across both chains.",
+          "It burns the tokens on the remote chain.",
+          "It locks the token permanently on the C-Chain."
+      ],
+      "correctAnswers": [
+          1
+      ],
+      "hint": "Collateralization ensures balance across chains during token transfers.",
+      "explanation": "Collateralization locks the transferred tokens on the source chain, ensuring that the minted tokens on the destination chain have an equivalent backing.",
+      "chapter": "Use ERC-20 as Native Token"
+  },
+  "209": {
+      "question": "What is the purpose of wrapping a native token on the C-Chain before transferring it to a new L1?",
+      "options": [
+          "To convert it into an ERC-721 token.",
+          "To prepare it for cross-chain transfer as an ERC-20 token.",
+          "To lock it in a smart contract and mint its representation on the new L1.",
+          "To burn the token and reduce its total supply."
+      ],
+      "correctAnswers": [
+          2
+      ],
+      "hint": "Wrapping a token creates a compatible version of it for cross-chain transfers.",
+      "explanation": "Wrapping the native token locks it on the C-Chain, allowing a compatible version of the token to be minted on the new L1, ensuring the cross-chain token transfer process.",
+      "chapter": "Use ERC-20 as Native Token"
+    },
+  "210": {
+    "question": "Which function is used to initialize the Validator set in the ValidatorManager contract?",
+    "options": [
+        "initializeValidatorRegistration()",
+        "deployProxyContract()",
+        "initializeValidatorSet()",
+        "setSubnetValidator()"
+    ],
+    "correctAnswers": [
+        2
+    ],
+    "hint": "Initialization of the Validator set is a critical step in setting up the ValidatorManager.",
+    "explanation": "The function `initializeValidatorSet` is called to initialize the Validator set in the ValidatorManager contract, setting up the starting Validators for the L1.",
+    "chapter": "Staking"
+  },
+  "211": {
+      "question": "Which configuration parameter sets the target rate of block production in seconds?",
+      "options": [
+          "minBaseFee",
+          "targetBlockRate",
+          "blockGasCostStep",
+          "baseFeeChangeDenominator"
+      ],
+      "correctAnswers": [
+          1
+      ],
+      "hint": "This parameter defines how frequently blocks should be produced.",
+      "explanation": "The `targetBlockRate` specifies the target rate of block production in seconds. For example, a target of 2 aims to produce a block every 2 seconds.",
+      "chapter": "Transaction Fees"
+    },
+  "212": {
+    "question": "Which allocation method ensures widespread ownership and participation in the network?",
+      "options": [
+          "Founders and Development Team",
+          "Early Investors and Backers",
+          "Community through token sales and airdrops",
+          "Reserve or Treasury"
+      ],
+      "correctAnswers": [
+          2
+      ],
+      "hint": "This allocation focuses on distributing tokens to a broad group of network participants.",
+      "explanation": "Allocating tokens to the community through mechanisms such as token sales and airdrops ensures widespread ownership and participation in the network, fostering decentralization and security.",
+      "chapter": "Token Distribution"
+  },
+  "213": {
+      "question": "What is the primary function of a bonding curve in token economics?",
+      "options": [
+          "To manage the governance of decentralized organizations.",
+          "To set a fixed price for tokens regardless of supply.",
+          "To define the relationship between a token's price and its supply, enabling automated price discovery and liquidity.",
+          "To create a voting mechanism for token holders."
+      ],
+      "correctAnswers": [
+          2
+      ],
+      "hint": "Bonding curves automate the price based on token supply.",
+      "explanation": "A bonding curve defines the relationship between a token's price and its supply, enabling automated price discovery and liquidity without relying on traditional market makers or exchanges.",
+      "chapter": "Token Distribution"
+    },
+  "214": {
+      "question": "Which governance model combines both on-chain and off-chain elements to balance flexibility and automation?",
+      "options": [
+          "On-Chain Governance",
+          "Off-Chain Governance",
+          "Hybrid Governance",
+          "DAO-Based Governance"
+      ],
+      "correctAnswers": [
+          2
+      ],
+      "hint": "This model integrates decision-making processes both on and off the blockchain.",
+      "explanation": "Hybrid governance combines on-chain and off-chain elements, aiming to balance the transparency and automation of on-chain governance with the flexibility and qualitative considerations of off-chain governance.",
+      "chapter": "Governance Models"
+  },
+  "215": {
+      "question": "Which of the following is a primary benefit of DAOs in blockchain governance?",
+      "options": [
+          "Centralized decision-making",
+          "Enhanced transparency through blockchain recording",
+          "Reduced need for community participation",
+          "Elimination of smart contracts"
+      ],
+      "correctAnswers": [
+          1
+      ],
+      "hint": "DAOs leverage blockchain technology to ensure openness and accountability.",
+      "explanation": "DAOs enhance transparency by recording all proposals, votes, and decisions on the blockchain, ensuring an immutable and transparent governance process that fosters trust and encourages active participation.",
+      "chapter": "Governance Models"
+    },
+    "301": {
+      "question": "What is the role of a message in cross-blockchain communication?",
+      "options": [
+          "To process the data on the destination chain.",
+          "To contain source, destination, and encoded data with a signature.",
+          "To originate communication from the source chain.",
+          "To validate the message authenticity on the source chain."
+      ],
+      "correctAnswers": [
+          1
+      ],
+      "hint": "Messages carry essential information between chains, including source and destination details.",
+      "explanation": "A message in cross-blockchain communication contains the source, destination, and encoded data along with a signature that guarantees its authenticity. This ensures that the information being transferred is accurate and can be trusted by the destination chain.",
+      "chapter": "Interchain Messaging"
+    },
+    "302": {
+      "question": "How does a multi-chain system achieve greater scalability compared to single-chain networks?",
+      "options": [
+          "By increasing the gas limit on a single chain.",
+          "By running independent chains in parallel, allowing for combined throughput.",
+          "By implementing more complex smart contracts on a single chain.",
+          "By reducing the number of validators in the network."
+      ],
+      "correctAnswers": [
+          1
+      ],
+      "hint": "Multi-chain systems utilize parallelism to enhance overall network performance.",
+      "explanation": "A multi-chain system achieves greater scalability by running independent chains in parallel. This parallelism allows the network to handle a higher combined throughput of transactions, as each chain can process its own set of transactions simultaneously without being bottlenecked by a single chain's limitations.",
+      "chapter": "Interchain Messaging"
+    },
+    "303": {
+      "question": "Which Solidity functions are used for encoding and decoding data?",
+      "options": [
+          "serializeData() and deserializeData()",
+          "encodeData() and decodeData()",
+          "abi.encode() and abi.decode()",
+          "bytes.encode() and bytes.decode()"
+      ],
+      "correctAnswers": [
+          2
+      ],
+      "hint": "These functions are part of Solidity's ABI encoding and decoding utilities.",
+      "explanation": "In Solidity, `abi.encode()` is used to encode data into a bytes array, and `abi.decode()` is used to decode a bytes array back into its original types. These functions are essential for handling complex data structures in smart contracts.",
+      "chapter": "Encoding & Decoding"
+    },
+    "304": {
+      "question": "What is the name of the function used by a dApp to send a cross-chain message in the Interchain Messaging contract?",
+      "options": [
+          "sendCrossChainMessage()",
+          "sendCrossMessage()",
+          "initiateCrossChainCommunication()",
+          "sendMessageCrossChain()"
+      ],
+      "correctAnswers": [
+          0
+      ],
+      "hint": "This function is part of the ITeleporterMessenger interface used for sending messages between chains.",
+      "explanation": "The `sendCrossChainMessage()` function is used by dApps to send cross-chain messages through the Interchain Messaging contract. It takes a `TeleporterMessageInput` struct as input, which includes details such as the destination chain ID, destination address, fee information, required gas limit, allowed relayers, and the encoded message.",
+      "chapter": "Sending a Message"
+    },
+    "305": {
+      "question": "Which interface must a contract implement to receive messages from the Interchain Messaging contract?",
+      "options": [
+          "ITeleporterMessenger",
+          "ITeleporterReceiver",
+          "ITeleporterSender",
+          "IMessageHandler"
+      ],
+      "correctAnswers": [
+          1
+      ],
+      "hint": "This interface defines the necessary function for receiving cross-chain messages.",
+      "explanation": "To receive messages from the Interchain Messaging contract, a contract must implement the `ITeleporterReceiver` interface. This interface requires the implementation of the `receiveTeleporterMessage` function, which handles incoming messages.",
+      "chapter": "Receiving a Message"
+    },
+    "306": {
+      "question": "After encoding multiple values into a byte array using `abi.encode()`, what must you know to correctly decode the byte array in Solidity?",
+      "options": [
+          "The length of the byte array",
+          "The contract's address",
+          "The types and order of the encoded values",
+          "The encoding algorithm used"
+      ],
+      "correctAnswers": [
+          2
+      ],
+      "hint": "Decoding requires knowledge of the original data structure used during encoding.",
+      "explanation": "To accurately decode a byte array in Solidity using `abi.decode()`, you must know the exact types and the order in which the values were encoded. This ensures that each segment of the byte array is interpreted correctly back into its original form.",
+      "chapter": "Encoding & Decoding"
+    },
+    "307": {
+      "question": "Why are `abi.encode()` functions called twice when encoding a function call with multiple parameters in a cross-chain message?",
+      "options": [
+          "To increase the security of the message.",
+          "To pack the function name and its parameters into a single bytes array.",
+          "To separate the message into two distinct byte arrays.",
+          "To comply with the Teleporter contract requirements."
+      ],
+      "correctAnswers": [
+          1
+      ],
+      "hint": "Encoding the function name alongside its parameters ensures proper identification and handling on the receiving end.",
+      "explanation": "Calling `abi.encode()` twice allows you to first encode the function parameters and then encode the function name along with the encoded parameters. This ensures that the receiving contract can decode the function name to determine which internal function to execute with the provided parameters.",
+      "chapter": "Encoding the Function Name and Parameters"
+    },
+    "308": {
+      "question": "How does the TeleporterRegistry contract track different versions of the TeleporterMessenger contracts?",
+      "options": [
+          "By maintaining an array of contract addresses.",
+          "By using separate variables for each version.",
+          "By maintaining a mapping of version numbers to contract addresses.",
+          "By storing all contract addresses in a single bytes array."
+      ],
+      "correctAnswers": [
+          2
+      ],
+      "hint": "The registry uses a key-value structure to associate versions with their corresponding contract addresses.",
+      "explanation": "The TeleporterRegistry contract tracks different versions of the TeleporterMessenger contracts by maintaining a mapping of version numbers to their respective contract addresses. This allows cross-Avalanche L1 dApps to request either the latest version or a specific version of the TeleporterMessenger as needed.",
+      "chapter": "How the ICM Registry works"
+    },
+   "309": {
+      "question": "What is the purpose of the `Recover` algorithm in some signature schemes?",
+      "options": [
+          "To generate a key pair.",
+          "To sign a message using the private key.",
+          "To recover the public key from a message and its signature.",
+          "To verify the integrity of a message."
+      ],
+      "correctAnswers": [
+          2
+      ],
+      "hint": "The `Recover` algorithm helps to retrieve the public key used to create a signature.",
+      "explanation": "The `Recover` algorithm is used to retrieve the public key that corresponds to the private key used to create the signature for a given message. This allows for verification of the signature by matching the recovered public key with the sender's public key, ensuring the authenticity and integrity of the message.",
+      "chapter": "Signature Schemes"
+    },
+    "310": {
+      "question": "What is a key advantage of the BLS multi-signature scheme in blockchain applications?",
+      "options": [
+          "It requires only one private key for all participants.",
+          "It eliminates the need for public keys.",
+          "It uses symmetric cryptography for enhanced security.",
+          "It supports signature and public key aggregation, resulting in compact signatures."
+      ],
+      "correctAnswers": [
+          3
+      ],
+      "hint": "The BLS scheme is known for its ability to aggregate multiple signatures into one.",
+      "explanation": "The BLS (Boneh-Lynn-Shacham) multi-signature scheme is highly efficient for blockchain applications due to its support for both signature and public key aggregation. This means multiple signatures can be compressed into a single short signature, and multiple public keys can be aggregated into one, reducing the storage and transmission overhead while maintaining security and integrity.",
+      "chapter": "Signature Schemes"
+    },
+    "311": {
+      "question": "What is the primary responsibility of the P-Chain in the Avalanche Network?",
+      "options": [
+          "Overseeing validator registration and staking operations for Avalanche L1s.",
+          "Managing the execution of smart contracts.",
+          "Handling transactions on the X-Chain.",
+          "Facilitating the transfer of assets between different chains."
+      ],
+      "correctAnswers": [
+          0
+      ],
+      "hint": "The P-Chain is responsible for validator and staking operations.",
+      "explanation": "In the Avalanche Network, the P-Chain is responsible for validator and Avalanche L1-level operations. This includes the creation of new blockchains and Avalanche L1s, the addition of validators to Avalanche L1s, staking operations, and other platform-level operations. By registering BLS public keys and managing staking, the P-Chain ensures the security and functionality of the network.",
+      "chapter": "P-Chain"
+    },
+    "312": {
+      "question": "Which component is responsible for relaying interchain messages to the destination chain in the Avalanche Network?",
+      "options": [
+          "Warp Precompile",
+          "Signature Verification",
+          "AWM Relayer",
+          "Message Initialization"
+      ],
+      "correctAnswers": [
+          2
+      ],
+      "hint": "This component checks outgoing messages and delivers them to the destination chain.",
+      "explanation": "The **AWM Relayer** is responsible for relaying interchain messages to the destination chain. It periodically checks the source Avalanche L1 for outgoing messages and delivers these by calling the Interchain Messaging contract on the destination Avalanche L1. This ensures that messages are efficiently transmitted between chains.",
+      "chapter": "Data Flow of an Interchain Message"
+    },
+    "313": {
+      "question": "How does the AWM Relayer in the Avalanche Network detect new outgoing messages?",
+      "options": [
+        "By periodically polling the source chain or being triggered by notifications.",
+          "By receiving real-time alerts from validators.",
+          "By scanning transaction receipts on the destination chain.",
+          "By querying the latest block headers exclusively."
+      ],
+      "correctAnswers": [
+          0
+      ],
+      "hint": "The AWM Relayer uses either a regular checking mechanism or event-based triggers.",
+      "explanation": "The AWM Relayer detects new outgoing messages by either polling the source Avalanche L1 periodically for new messages or being triggered by notifications whenever a new outgoing message is detected by a node. This dual approach ensures that messages are efficiently picked up and relayed to the destination chain.",
+      "chapter": "Message Pickup"
+    },
+    "314": {
+      "question": "Why does the AWM Relayer not aggregate the BLS Public Keys off-chain and attach them to the message?",
+      "options": [
+          "Because aggregating off-chain would increase the message size significantly.",
+          "To prevent the AWM Relayer from creating fraudulent public keys and signatures, ensuring security.",
+          "Because the destination chain does not support off-chain aggregation.",
+          "To reduce the computational load on the AWM Relayer."
+      ],
+      "correctAnswers": [
+          1
+      ],
+      "hint": "Aggregating public keys off-chain could allow the relayer to fabricate signatures.",
+      "explanation": "The AWM Relayer does not aggregate the BLS Public Keys off-chain and attach them to the message to prevent security vulnerabilities. If aggregation were done off-chain, the relayer could create fake public keys and signatures, compromising the authenticity and integrity of the messages. By requiring each validator on the destination chain to perform the aggregation, the system ensures that the aggregated public key accurately represents the signing validators, maintaining trust and security in the cross-chain communication process.",
+      "chapter": "Signature Schemes"
+    },
+    "315": {
+      "question": "What is the primary purpose of depositing ERC-20 tokens into the Interchain Messaging contract in the Avalanche Network?",
+      "options": [
+          "To pay for gas fees associated with transactions.",
+          "To serve as collateral for staking operations.",
+          "To incentivize the AWM Relayer by providing a reward for delivering messages.",
+          "To lock tokens and prevent them from being transferred."
+      ],
+      "correctAnswers": [
+          2
+      ],
+      "hint": "Depositing tokens serves as a financial incentive for relayers to perform their duties.",
+      "explanation": "Depositing ERC-20 tokens into the Interchain Messaging contract acts as a reward mechanism for the AWM Relayer. When a relayer successfully delivers a message, they can claim the deposited tokens as compensation for their efforts in ensuring reliable cross-chain communication. This incentivization helps maintain the efficiency and security of the messaging system.",
+      "chapter": "Fee Data Flow"
+    },
+    "316": {
+      "question": "According to the Avalanche Network's fee incentivization model, how should the minimum fee amount be calculated to ensure that a Relayer makes at least a 10% profit?",
+      "options": [
+          "Fee = requiredGasLimit * gas_price_in_native_token",
+          "Fee = (requiredGasLimit * gas_price_in_native_token) / 1.1",
+          "Fee = requiredGasLimit + gas_price_in_native_token + native_token_price",
+          "Fee = 1.1 * (requiredGasLimit * gas_price_in_native_token * native_token_price)"
+      ],
+      "correctAnswers": [
+          3
+      ],
+      "hint": "The fee should cover the costs and provide additional profit to the Relayer.",
+      "explanation": "To ensure the Relayer makes at least a 10% profit, the fee amount should be calculated as 1.1 times the cost. The cost is determined by multiplying the requiredGasLimit by the gas price in native tokens and the native token price. Therefore, the minimum fee should be 1.1 * (requiredGasLimit * gas_price_in_native_token * native_token_price).",
+      "chapter": "Determining the Fee"
+    },
+    "401": {
+      "question": "What advantage do custom blockchains on Avalanche offer in terms of gas tokens compared to the C-Chain?",
+      "options": [
+          "They use a fixed gas token similar to ETH on the C-Chain.",
+          "They eliminate the need for gas tokens altogether.",
+          "They allow developers to use any ERC-20 token as the gas token.",
+          "They automatically adjust gas fees based on network demand."
+      ],
+      "correctAnswers": [
+          2
+      ],
+      "hint": "Custom blockchains offer flexibility in defining their gas tokens, unlike the C-Chain's fixed system.",
+      "explanation": "Custom blockchains on Avalanche provide the flexibility to define their economic models, including the ability to use any ERC-20 token as their gas token. This differs from the C-Chain, which has a fixed gas token system (ETH). This flexibility allows developers to tailor the economic incentives and stability of their networks according to their specific needs.",
+      "chapter": "Customizable Tokenomics"
+    },
+    "402": {
+      "question": "How do Avalanche Custom Blockchains differ from Layer 2 rollups in terms of security and decentralization?",
+      "options": [
+          "Avalanche Custom Blockchains delegate security to the Ethereum mainnet, while Layer 2 rollups maintain independent security.",
+          "Avalanche Custom Blockchains maintain their own security as part of the Avalanche base layer, whereas Layer 2 rollups delegate security to the Ethereum mainnet.",
+          "Both Avalanche Custom Blockchains and Layer 2 rollups rely solely on the security of their respective base layers.",
+          "Layer 2 rollups offer independent security for each blockchain, while Avalanche Custom Blockchains share a unified security model."
+      ],
+      "correctAnswers": [
+          1
+      ],
+      "hint": "Avalanche Custom Blockchains are part of the base layer, while Layer 2 rollups rely on another mainnet for security.",
+      "explanation": "Avalanche Custom Blockchains maintain their own security as part of the Avalanche base layer, ensuring that a compromise in one blockchain does not affect others. In contrast, Layer 2 rollups delegate their security to the Ethereum mainnet, meaning that if the Ethereum mainnet experiences a security breach, it can potentially impact all Layer 2 solutions relying on it.",
+      "chapter": "Decentralization and Security"
+    },
+    "403": {
+      "question": "What is the primary purpose of implementing dynamic transaction fees (gas fees) in the Ethereum network?",
+      "options": [
+          "To regulate access to limited processing resources and prevent network congestion.",
+          "To reward developers for maintaining the network.",
+          "To fund protocol upgrades and improvements.",
+          "To incentivize liquidity providers."
+      ],
+      "correctAnswers": [
+          0
+      ],
+      "hint": "Dynamic fees help manage the flow of transactions and avoid network overload.",
+      "explanation": "Dynamic transaction fees, also known as gas fees, are implemented in the Ethereum network to regulate access to its limited processing resources. By adjusting fees based on network demand, Ethereum ensures that the blockchain remains efficient and prevents congestion, much like a flexible toll system on a highway manages traffic flow during peak hours.",
+      "chapter": "Transaction Fees and Gas Fees"
+    },
+    "404": {
+      "question": "Which interoperability use case on Avalanche allows users to transfer tokens like USDC across different Layer 1 blockchains without using centralized exchanges?",
+      "options": [
+          "Decentralized Data Feeds (Chainlink Price Feeds)",
+          "Cross-Chain Token Transfers",
+          "Cross-Chain NFTs",
+          "Interoperable DeFi Protocols"
+      ],
+      "correctAnswers": [
+          1
+      ],
+      "hint": "This use case focuses on moving tokens seamlessly between different blockchain networks.",
+      "explanation": "Cross-Chain Token Transfers enable users to move tokens such as USDC from one Layer 1 blockchain to another without the need for centralized exchanges or third-party intermediaries. This facilitates seamless transactions with minimal fees and fast processing times, enhancing liquidity access and maintaining decentralization by keeping users in control of their assets during the transfer.",
+      "chapter": "Interoperability Use Cases"
+    },
+    "405": {
+      "question": "What is the primary role of Avalanche's Interchain Messaging Protocol (ICM Protocol)?",
+      "options": [
+          "To facilitate the rapid transfer of assets between different Layer 1 blockchains.",
+          "To manage validator sets and staking operations on Avalanche.",
+          "To handle the creation of new blockchains and Avalanche L1s.",
+          "To enable smart contracts on different chains to interact directly without intermediaries."
+      ],
+      "correctAnswers": [
+          3
+      ],
+      "hint": "The ICM Protocol allows direct interaction between smart contracts on different chains.",
+      "explanation": "The primary role of Avalanche's Interchain Messaging Protocol (ICM Protocol) is to enable smart contracts on different chains within the Avalanche network to interact with each other directly, without relying on third-party intermediaries. This facilitates complex cross-chain operations, enhancing the interoperability and functionality of the Avalanche ecosystem.",
+      "chapter": "Interchain Messaging & the Interchain Messaging Protocol"
+    },
+    "406": {
+      "question": "What is one of the primary benefits of implementing permissioning on an Avalanche L1 blockchain?",
+      "options": [
+          "Enhancing the decentralization by allowing anyone to participate.",
+          "Increasing transaction speeds by reducing the number of validators.",
+          "Ensuring data privacy and confidentiality by restricting access to authorized parties.",
+          "Automatically adjusting gas fees based on network demand."
+      ],
+      "correctAnswers": [
+          2
+      ],
+      "hint": "Permissioning helps in controlling who can access sensitive information on the blockchain.",
+      "explanation": "One of the primary benefits of implementing permissioning on an Avalanche L1 blockchain is ensuring data privacy and confidentiality. By restricting access to authorized parties, permissioned blockchains protect sensitive information from unauthorized access, which is crucial in industries like finance and healthcare where data privacy is paramount.",
+      "chapter": "Permissioning Your Avalanche L1"
+    },
+    "407": {
+      "question": "How does permissioning on an Avalanche L1 blockchain help institutions comply with regulatory requirements?",
+      "options": [
+          "By allowing anyone to deploy contracts and initiate transactions.",
+          "By enabling only pre-approved users to deploy contracts or initiate transactions.",
+          "By automatically adjusting transaction fees based on user activity.",
+          "By decentralizing control over smart contract deployments."
+      ],
+      "correctAnswers": [
+          1
+      ],
+      "hint": "Permissioning restricts actions to authorized users to ensure compliance.",
+      "explanation": "Permissioning on an Avalanche L1 blockchain allows institutions to enforce regulatory compliance by enabling only pre-approved users to deploy contracts or initiate transactions. This control ensures that only vetted and authorized parties can interact with the blockchain, thereby preventing unauthorized or potentially illicit activities. By restricting access, institutions can implement necessary measures such as KYC (Know Your Customer) and AML (Anti-Money Laundering) protocols, thereby adhering to industry-specific regulations and maintaining the integrity and security of their blockchain systems.",
+      "chapter": "Compliance"
+    },
+    "408": {
+      "question": "What is a primary benefit of implementing a permissioned validator set on an Avalanche L1 blockchain?",
+      "options": [
+          "It allows anyone to participate in the validation process, enhancing decentralization.",
+          "It automatically adjusts transaction fees based on validator performance.",
+          "It eliminates the need for validators by using a centralized authority.",
+          "It restricts validation to pre-approved validators, ensuring compliance and security."
+      ],
+      "correctAnswers": [
+          3
+      ],
+      "hint": "Permissioned validator sets provide control over who can validate transactions.",
+      "explanation": "Implementing a permissioned validator set on an Avalanche L1 blockchain restricts the validation process to pre-approved validators. This enhances compliance with regulatory requirements, ensures higher security by limiting participation to trusted entities, and allows for better control over the network's governance and operations. Such a setup is particularly beneficial for enterprises, consortiums, government agencies, and financial institutions that require strict adherence to compliance and data privacy standards.",
+      "chapter": "Permissioning Validators"
+    },
+    "409": {
+      "question": "How can Avalanche L1 validators configure their blockchain to restrict data visibility only to validators?",
+      "options": [
+          "By setting their node to public mode.",
+          "By enabling data encryption on the blockchain.",
+          "By setting `validatorOnly` to true.",
+          "By increasing gas fees."
+      ],
+      "correctAnswers": [
+          2
+      ],
+      "hint": "Permissioned blockchains can limit data visibility to a select group.",
+      "explanation": "Avalanche L1 validators can restrict data visibility by setting the `validatorOnly` flag to true on their nodes. This configuration ensures that only validators can exchange messages with the blockchain, preventing other peers from accessing the blockchain's data. This is essential for maintaining privacy and confidentiality in permissioned blockchains, especially in enterprise or regulated environments where data protection is paramount.",
+      "chapter": "Private Blockchains"
+    },
+    "410": {
+      "question": "How can a community running an Avalanche L1 blockchain maintain a hard cap on the native token supply?",
+      "options": [
+          "By keeping the Native Minter Precompile deactivated, preventing additional minting.",
+          "By activating the Native Minter Precompile to allow unlimited minting.",
+          "By setting the initial supply to 720 million AVAX and allowing periodic increases.",
+          "By delegating minting rights to a centralized authority."
+      ],
+      "correctAnswers": [
+          0
+      ],
+      "hint": "Maintaining a hard cap involves restricting the ability to mint new tokens.",
+      "explanation": "To maintain a hard cap on the native token supply, a community running an Avalanche L1 blockchain should keep the Native Minter Precompile deactivated. By doing so, they prevent the creation of additional native tokens beyond the predefined limit. This ensures that the total supply remains fixed, which is essential for scenarios where a valueless gas token or a specific tokenomics structure is required. The Native Minter Precompile is deactivated by default, allowing blockchain creators to choose whether to enable or disable minting based on their economic models and requirements.",
+      "chapter": "Native Token Minting Rights"
     }
   }
 }
\ No newline at end of file
diff --git a/content/common/avalanche-starter-kit/pause-and-resume.mdx b/content/common/avalanche-starter-kit/pause-and-resume.mdx
new file mode 100644
index 00000000..32d6923e
--- /dev/null
+++ b/content/common/avalanche-starter-kit/pause-and-resume.mdx
@@ -0,0 +1,103 @@
+import { Step, Steps } from 'fumadocs-ui/components/steps';
+
+In this section, you’ll learn how to pause and resume your deployed Avalanche L1 using GitHub Codespaces. This will allow you to preserve the state of your blockchains and easily restore them when you return to development.
+
+### Restarting the Network After Codespace Pauses
+
+With **GitHub Codespaces**, you can easily spin up and manage your Avalanche L1 blockchains. However, after a period of inactivity, Codespace instances will automatically pause, or you can stop them manually.
+
+When you want to resume your work, start the Codespace instance again and follow these steps to restore your network.
+
+<Steps>
+<Step>
+### Start the Avalanche Network
+After restarting your Codespace instance, use the following command to restart your Avalanche network:
+
+```bash
+avalanche network start
+```
+
+Here’s what the output of this command looks like:
+
+```bash
+$ avalanche network start
+Backend controller started, pid: 1781, output at: /home/vscode/.avalanche-cli/runs/server_20241007_035854/avalanche-cli-backend.log
+Starting previously deployed and stopped snapshot
+Booting Network. Wait until healthy...
+Node logs directory: /home/vscode/.avalanche-cli/runs/network_20241007_035856/node<i>/logs
+
+Network ready to use.
+
++------------------------------------------------------------------------------------------------------------------------------------+
+|                                                          TESTEXP RPC URLS                                                          |
++-----------+------------------------------------------------------------------------------------------------------------------------+
+| Localhost | http://127.0.0.1:9650/ext/bc/testexp/rpc                                                                               |
+|           +------------------------------------------------------------------------------------------------------------------------+
+|           | http://127.0.0.1:9650/ext/bc/ZJ3iFLF2DJo31Koq7Ah2F7EwSmSCpXBG2LLX1bFhsdEfmxkWD/rpc                                     |
++-----------+------------------------------------------------------------------------------------------------------------------------+
+| Codespace | https://musical-lamp-5rgwvggj75xh777g-9650.app.github.dev/ext/bc/testexp/rpc                                           |
+|           +------------------------------------------------------------------------------------------------------------------------+
+|           | https://musical-lamp-5rgwvggj75xh777g-9650.app.github.dev/ext/bc/ZJ3iFLF2DJo31Koq7Ah2F7EwSmSCpXBG2LLX1bFhsdEfmxkWD/rpc |
++-----------+------------------------------------------------------------------------------------------------------------------------+
+
++--------------------------------------------------------------------------------------------------------------------------------------+
+|                                                                 NODES                                                                |
++-------+------------------------------------------+-----------------------+-----------------------------------------------------------+
+| NAME  | NODE ID                                  | LOCALHOST ENDPOINT    | CODESPACE ENDPOINT                                        |
++-------+------------------------------------------+-----------------------+-----------------------------------------------------------+
+| node1 | NodeID-7Xhw2mDxuDS44j42TCB6U5579esbSt3Lg | http://127.0.0.1:9650 | https://musical-lamp-5rgwvggj75xh777g-9650.app.github.dev |
++-------+------------------------------------------+-----------------------+-----------------------------------------------------------+
+| node2 | NodeID-MFrZFVCXPv5iCn6M9K6XduxGTYp891xXZ | http://127.0.0.1:9652 | https://musical-lamp-5rgwvggj75xh777g-9652.app.github.dev |
++-------+------------------------------------------+-----------------------+-----------------------------------------------------------+
+| node3 | NodeID-NFBbbJ4qCmNaCzeW7sxErhvWqvEQMnYcN | http://127.0.0.1:9654 | https://musical-lamp-5rgwvggj75xh777g-9654.app.github.dev |
++-------+------------------------------------------+-----------------------+-----------------------------------------------------------+
+| node4 | NodeID-GWPcbFJZFfZreETSoWjPimr846mXEKCtu | http://127.0.0.1:9656 | https://musical-lamp-5rgwvggj75xh777g-9656.app.github.dev |
++-------+------------------------------------------+-----------------------+-----------------------------------------------------------+
+| node5 | NodeID-P7oB2McjBGgW2NXXWVYjV8JEDFoW9xDE5 | http://127.0.0.1:9658 | https://musical-lamp-5rgwvggj75xh777g-9658.app.github.dev |
++-------+------------------------------------------+-----------------------+-----------------------------------------------------------+
+
+using awm-relayer version (v1.4.0)
+Executing AWM-Relayer...
+```
+</Step>
+
+<Step>
+### Make Ports Public Again
+After the network starts, all ports are closed by default in Codespaces. You need to make the necessary ports public, like port `9650` for RPC access:
+
+- Open the Codespace settings.
+- Go to Ports.
+- Select the row with the port 9650.
+- Right Click > Port Visibility > Public.
+
+![](/common-images/codespaces/ports-publish.png)
+</Step>
+
+<Step> 
+### Changing Timeout Duration for Codespaces
+By default, Codespaces will pause after 30 minutes of inactivity. You can extend this period to up to 4 hours to avoid frequent pauses during development.
+
+To configure the timeout duration:
+
+1. In the upper-right corner of any page on GitHub, click your profile photo, then click **"Settings"**.
+2. In the **"Code, planning, and automation"** section of the sidebar, click **"Codespaces"**.
+3. Under **"Default idle timeout"**, enter the time that you want, then click Save. The time must be between 5 minutes and 240 minutes (4 hours).
+
+![](/common-images/codespaces/specify-idle-timeout.png)
+
+This will help keep your blockchain running for longer periods without interruption. 
+</Step>
+
+<Step> 
+### Fee Considerations for Paid Users
+If you're a paid user, be cautious about the costs associated with running long-running Codespaces. It's important to avoid undesired fees, especially if you're keeping instances alive for extended periods but also the resource usage. Memory, storage, traffic, and bandwidth usage can significantly impact costs if not managed properly.
+
+You can manage these settings in GitHub:
+
+1. In the upper-right corner of any page on GitHub, click your profile photo, then click **"Settings"**.
+2. In the **"Access"** section of the sidebar, click **"Billing and Plans"**, and click **"Spending Limits"**.
+3. Set a budget or limitation on Codespace usage to prevent unexpected fees. Leaving it at $0.00 will avoid any extra expenses.
+
+![](/common-images/codespaces/specify-spending-limit.png)
+</Step>
+</Steps>
\ No newline at end of file
diff --git a/content/common/core-wallet/faucet.mdx b/content/common/core-wallet/faucet.mdx
index 984cfb19..a9d587ec 100644
--- a/content/common/core-wallet/faucet.mdx
+++ b/content/common/core-wallet/faucet.mdx
@@ -1,4 +1,4 @@
-Head to the Faucet and grab some free testnet AVAX, ALOT, and USDC: [Avalanche Testnet Faucet](https://core.app/tools/testnet-faucet/?token=C)
+Head to the Faucet and grab some free testnet AVAX, ALOT, and USDC: [Avalanche Testnet Faucet](https://test.core.app/tools/testnet-faucet/?token=C)
 
 Use the coupon code: **avalanche-academy**
 
@@ -6,4 +6,4 @@ If you are not able to claim Testnet Tokens in the faucet, please reach out in t
     href="https://t.me/avalancheacademy"
     target='_blank' >
     Avalanche Academy Telegram Chat
-</a>, so our Developer Relations team can send you some Fuji AVAX.
\ No newline at end of file
+</a>, so our Developer Relations team can send you some Fuji AVAX.
diff --git a/content/course/interchain-messaging/02-interoperability/02-source-message-destination.mdx b/content/course/interchain-messaging/02-interoperability/02-source-message-destination.mdx
index ff06e0e8..367faaaa 100644
--- a/content/course/interchain-messaging/02-interoperability/02-source-message-destination.mdx
+++ b/content/course/interchain-messaging/02-interoperability/02-source-message-destination.mdx
@@ -39,4 +39,6 @@ The message is the data structure that will be sent to to the destination chain.
 
 ## Destination Chain
 
-Conversely, the destination chain is the recipient blockchain where the communicated data, assets, or instructions will be received and processed. Validators, nodes, or protocols associated with the cross-blockchain communication system on the destination chain receive and authenticate the information relayed from the source chain. Once validated, the destination chain processes the data or executes the specified instructions.
\ No newline at end of file
+Conversely, the destination chain is the recipient blockchain where the communicated data, assets, or instructions will be received and processed. Validators, nodes, or protocols associated with the cross-blockchain communication system on the destination chain receive and authenticate the information relayed from the source chain. Once validated, the destination chain processes the data or executes the specified instructions.
+
+<Quiz quizId="301"/>
diff --git a/content/course/interchain-messaging/02-interoperability/03-multi-chain-networks.mdx b/content/course/interchain-messaging/02-interoperability/03-multi-chain-networks.mdx
index 6fcece5b..02fd8d2e 100644
--- a/content/course/interchain-messaging/02-interoperability/03-multi-chain-networks.mdx
+++ b/content/course/interchain-messaging/02-interoperability/03-multi-chain-networks.mdx
@@ -28,4 +28,6 @@ Different blockchain networks use different scaling approaches, such as Layer 2s
 
 ![](/common-images/multi-chain-architecture/combined-throughput.png)
 
-While roll-ups may enable a very high-throughput of a single chain, they can never outcompete the combined throughput of a multi-chain system. This is because there's no limit to the number of chains that can run in parallel.
\ No newline at end of file
+While roll-ups may enable a very high-throughput of a single chain, they can never outcompete the combined throughput of a multi-chain system. This is because there's no limit to the number of chains that can run in parallel.
+
+<Quiz quizId="302"/>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/03-avalanche-starter-kit/06-pause-and-resume.mdx b/content/course/interchain-messaging/03-avalanche-starter-kit/06-pause-and-resume.mdx
new file mode 100644
index 00000000..c734a718
--- /dev/null
+++ b/content/course/interchain-messaging/03-avalanche-starter-kit/06-pause-and-resume.mdx
@@ -0,0 +1,11 @@
+---
+title: Pause and Resume
+description: If you've deployed an Avalanche L1, you can preserve and restore the state of your deployed Avalanche L1s.
+updated: 2024-10-07
+authors: [0xstt]
+icon: BookOpen
+---
+
+import PauseAndResume from "@/content/common/avalanche-starter-kit/pause-and-resume.mdx";
+
+<PauseAndResume />
diff --git a/content/course/interchain-messaging/04-icm-basics/02-recap-bytes-encoding-decoding.mdx b/content/course/interchain-messaging/04-icm-basics/02-recap-bytes-encoding-decoding.mdx
index 15df3606..3b06b068 100644
--- a/content/course/interchain-messaging/04-icm-basics/02-recap-bytes-encoding-decoding.mdx
+++ b/content/course/interchain-messaging/04-icm-basics/02-recap-bytes-encoding-decoding.mdx
@@ -49,4 +49,6 @@ When we decode data, we convert it from a byte array back into its original form
 ) = abi.decode(message, (string, uint));
 ```
 
-This will give us back the original values that we encoded before. Note that we do need to know the types of the values and their order that we encoded to decode them correctly.
\ No newline at end of file
+This will give us back the original values that we encoded before. Note that we do need to know the types of the values and their order that we encoded to decode them correctly.
+
+<Quiz quizId="303"/>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/04-icm-basics/03-sending-a-message.mdx b/content/course/interchain-messaging/04-icm-basics/03-sending-a-message.mdx
index 555b1e4a..e2372964 100644
--- a/content/course/interchain-messaging/04-icm-basics/03-sending-a-message.mdx
+++ b/content/course/interchain-messaging/04-icm-basics/03-sending-a-message.mdx
@@ -61,3 +61,5 @@ The `sendCrossChainMessage` function takes `TeleporterMessageInput` struct as an
 - **`requiredGasLimit`:** The amount of gas the delivery of the message requires. If the relayer provides the required gas, the message will be considered delivered whether or not its execution succeeds, such that the relayer can claim their fee reward.
 - **`allowedRelayerAddresses`:** An array of addresses of allowed relayers. An empty allowed relayers list means anyone is allowed to deliver the message. We will look at this later in more detail.
 - **`message`:** The message to be sent as bytes. The message can contain multiple encoded values. DApps using Interchain Messaging are responsible for defining the exact format of this payload in a way that can be decoded on the receiving end. The message can hold multiple values that be encoded in a single bytes object. For example, applications may encode multiple method parameters on the sending side, then decode this data in the contract implementing the receiveTeleporterMessage function and call another contract with the parameters from there.
+
+<Quiz quizId="304"/>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/04-icm-basics/05-receiving-a-message.mdx b/content/course/interchain-messaging/04-icm-basics/05-receiving-a-message.mdx
index 757256c8..4d624d6b 100644
--- a/content/course/interchain-messaging/04-icm-basics/05-receiving-a-message.mdx
+++ b/content/course/interchain-messaging/04-icm-basics/05-receiving-a-message.mdx
@@ -89,3 +89,5 @@ contract MessageReceiver is ITeleporterReceiver {
 ```
 
 This contract stores the last `Message` and it's sender of each chain it has received. When it is instantiated, the address of the Interchain Messaging contract is supplied to the constructor. The contract implements the `ITelepoterReceiver` interface and therefore we also implement the `receiveTeleporterMessage` function. 
+
+<Quiz quizId="305"/>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/06-invoking-functions/02-encoding-multiple-values.mdx b/content/course/interchain-messaging/06-invoking-functions/02-encoding-multiple-values.mdx
index 16346e0a..dd35e793 100644
--- a/content/course/interchain-messaging/06-invoking-functions/02-encoding-multiple-values.mdx
+++ b/content/course/interchain-messaging/06-invoking-functions/02-encoding-multiple-values.mdx
@@ -90,3 +90,4 @@ Here we are using `abi.decode()` to unpack the three values `(someString, someNu
   address someAddress
 ) = abi.decode(message, (string, uint, address));  // [!code highlight]
 ``` 
+<Quiz quizId="306"/>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/06-invoking-functions/06-encoding-function-name.mdx b/content/course/interchain-messaging/06-invoking-functions/06-encoding-function-name.mdx
index 7687e6c7..37f666fb 100644
--- a/content/course/interchain-messaging/06-invoking-functions/06-encoding-function-name.mdx
+++ b/content/course/interchain-messaging/06-invoking-functions/06-encoding-function-name.mdx
@@ -248,3 +248,5 @@ cast call --rpc-url myblockchain $RECEIVER_ADDRESS "result_num()(uint)"
 
 </Step>
 </Steps>
+
+<Quiz quizId="307"/>
diff --git a/content/course/interchain-messaging/07-icm-registry/02-how-the-icm-registry-works.mdx b/content/course/interchain-messaging/07-icm-registry/02-how-the-icm-registry-works.mdx
index b5b71d1e..d669d7a3 100644
--- a/content/course/interchain-messaging/07-icm-registry/02-how-the-icm-registry-works.mdx
+++ b/content/course/interchain-messaging/07-icm-registry/02-how-the-icm-registry-works.mdx
@@ -79,3 +79,5 @@ contract TeleporterRegistry {
 ```
 
 If you are interested in the entire implementation, check it out [here](https://github.com/ava-labs/teleporter/blob/main/contracts/teleporter/registry/TeleporterRegistry.sol).
+
+<Quiz quizId="308"/>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/08-securing-cross-chain-communication/02-signature-schemes.mdx b/content/course/interchain-messaging/08-securing-cross-chain-communication/02-signature-schemes.mdx
index 30a571d2..5b7c6747 100644
--- a/content/course/interchain-messaging/08-securing-cross-chain-communication/02-signature-schemes.mdx
+++ b/content/course/interchain-messaging/08-securing-cross-chain-communication/02-signature-schemes.mdx
@@ -8,4 +8,6 @@ icon: BookOpen
 
 import SignatureSchemes from "@/content/common/cryptography/signature-schemes.mdx"
 
-<SignatureSchemes />
\ No newline at end of file
+<SignatureSchemes />
+
+<Quiz quizId="309"/>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/08-securing-cross-chain-communication/04-multi-signature-schemes.mdx b/content/course/interchain-messaging/08-securing-cross-chain-communication/04-multi-signature-schemes.mdx
index b5aa4f18..fbdf9922 100644
--- a/content/course/interchain-messaging/08-securing-cross-chain-communication/04-multi-signature-schemes.mdx
+++ b/content/course/interchain-messaging/08-securing-cross-chain-communication/04-multi-signature-schemes.mdx
@@ -8,4 +8,6 @@ icon: BookOpen
 
 import MultiSignatureSchemes from "@/content/common/cryptography/multi-signature-schemes.mdx"
 
-<MultiSignatureSchemes />
\ No newline at end of file
+<MultiSignatureSchemes />
+
+<Quiz quizId="310"/>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/09-avalanche-warp-messaging/02-p-chain.mdx b/content/course/interchain-messaging/09-avalanche-warp-messaging/02-p-chain.mdx
index 18e7efc8..08045813 100644
--- a/content/course/interchain-messaging/09-avalanche-warp-messaging/02-p-chain.mdx
+++ b/content/course/interchain-messaging/09-avalanche-warp-messaging/02-p-chain.mdx
@@ -9,3 +9,5 @@ icon: BookOpen
 import PChain from "@/content/common/primary-network/p-chain.mdx";
 
 <PChain />
+
+<Quiz quizId="311"/>
diff --git a/content/course/interchain-messaging/09-avalanche-warp-messaging/05-dataflow.mdx b/content/course/interchain-messaging/09-avalanche-warp-messaging/05-dataflow.mdx
index 658fdaf5..26798003 100644
--- a/content/course/interchain-messaging/09-avalanche-warp-messaging/05-dataflow.mdx
+++ b/content/course/interchain-messaging/09-avalanche-warp-messaging/05-dataflow.mdx
@@ -61,3 +61,5 @@ As you noticed in the `Teleporter Basics` chapter most of the cross-chain commun
 - **Receiving a message:** Being able to be called by the Interchain Messaging on the destination chain
 
 To start, we will assume there is always an AWM Relayer to deliver our messages without any incentives. Let's dive deeper into the sending and receiving of messages in the next sections.
+
+<Quiz quizId="312"/>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/09-avalanche-warp-messaging/06-message-pickup.mdx b/content/course/interchain-messaging/09-avalanche-warp-messaging/06-message-pickup.mdx
index 39562fe2..df1625ad 100644
--- a/content/course/interchain-messaging/09-avalanche-warp-messaging/06-message-pickup.mdx
+++ b/content/course/interchain-messaging/09-avalanche-warp-messaging/06-message-pickup.mdx
@@ -55,4 +55,6 @@ For the source Avalanche L1s, the AWM Relayer offers the following configuration
 - **message-contracts:** A map with the address of the Interchain Messaging contract as key and the following config parameters as values:
     - **message-format:** A string specifying the format. Currently, only the format "teleporter" exists, but this field has been added in anticipation of multiple formats in the future
     - **settings:** A dictionary with settings for this Interchain Messaging contract 
-    - **reward-address:** The address rewards are paid out to
\ No newline at end of file
+    - **reward-address:** The address rewards are paid out to
+
+<Quiz quizId="313"/>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/09-avalanche-warp-messaging/07-message-delivery.mdx b/content/course/interchain-messaging/09-avalanche-warp-messaging/07-message-delivery.mdx
index 52524e63..d59dad42 100644
--- a/content/course/interchain-messaging/09-avalanche-warp-messaging/07-message-delivery.mdx
+++ b/content/course/interchain-messaging/09-avalanche-warp-messaging/07-message-delivery.mdx
@@ -61,4 +61,6 @@ The BLS public key aggregation has to be done by every validator of the destinat
 
 Even though this would make the verification much faster, there is a security issue here. How can we be sure that the aggregated public key actually represents the public keys of the signing validators? How do we know that the AWM Relayer did not just create a bunch of public keys and an aggregated signature of these?
 
-The only way to verify that is to aggregate the public keys of the signing validators and compare it to the one sent by the AWM Relayer. Therefore, it is pointless to attach it to the message.
\ No newline at end of file
+The only way to verify that is to aggregate the public keys of the signing validators and compare it to the one sent by the AWM Relayer. Therefore, it is pointless to attach it to the message.
+
+<Quiz quizId="314"/>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/12-incentivizing-a-relayer/02-fee-data-flow.mdx b/content/course/interchain-messaging/12-incentivizing-a-relayer/02-fee-data-flow.mdx
index fa0477d4..c68e95b8 100644
--- a/content/course/interchain-messaging/12-incentivizing-a-relayer/02-fee-data-flow.mdx
+++ b/content/course/interchain-messaging/12-incentivizing-a-relayer/02-fee-data-flow.mdx
@@ -49,4 +49,6 @@ We are using the following emoji guide to show the actors of each action:
 
 As you can see, there are just a few actions you as a cross-chain dApp developer need to implement so dApp works smoothly with fees, everything else is being done by the Interchain Messaging contract and the Relayer.
 
-If you run your own relayer, you don't have to attach any fees.
\ No newline at end of file
+If you run your own relayer, you don't have to attach any fees.
+
+<Quiz quizId="315"/>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/12-incentivizing-a-relayer/03-determining-the-fee-amount.mdx b/content/course/interchain-messaging/12-incentivizing-a-relayer/03-determining-the-fee-amount.mdx
index f9980a28..9cc34044 100644
--- a/content/course/interchain-messaging/12-incentivizing-a-relayer/03-determining-the-fee-amount.mdx
+++ b/content/course/interchain-messaging/12-incentivizing-a-relayer/03-determining-the-fee-amount.mdx
@@ -59,3 +59,5 @@ Then:
 *Amount = 550,000,000,000,000 weiTLP*
 
 All amounts in Solidity need to be declared in wei, so use a unit converter to convert from nTLP to wei (10^-18).
+
+<Quiz quizId="316"/>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/certificate.mdx b/content/course/interchain-messaging/certificate.mdx
new file mode 100644
index 00000000..c2c1726d
--- /dev/null
+++ b/content/course/interchain-messaging/certificate.mdx
@@ -0,0 +1,14 @@
+---
+title: Course Completion Certificate
+updated: 2024-10-11
+authors: [owenwahlgren]
+icon: BadgeCheck
+---
+
+import CertificatePage from '@/components/certificates';
+
+You've made it to the end of the course. Let's check your progress and get your certificate.
+
+<CertificatePage courseId="interchain-messaging"/>
+
+Thank you for participating in this course. We hope you found it informative and enjoyable!
\ No newline at end of file
diff --git a/content/course/interchain-messaging/meta.json b/content/course/interchain-messaging/meta.json
index 02ba750e..66273d73 100644
--- a/content/course/interchain-messaging/meta.json
+++ b/content/course/interchain-messaging/meta.json
@@ -24,6 +24,8 @@
     "---Restricting-the-relayer---",
     "...11-restricting-the-relayer",
     "---Incentivizing a Relayer---",
-    "...12-incentivizing-a-relayer"
+    "...12-incentivizing-a-relayer",
+    "---Conclusion---",
+    "certificate"
   ]
 }
diff --git a/content/course/interchain-token-transfer/02-avalanche-starter-kit/06-pause-and-resume.mdx b/content/course/interchain-token-transfer/02-avalanche-starter-kit/06-pause-and-resume.mdx
new file mode 100644
index 00000000..c734a718
--- /dev/null
+++ b/content/course/interchain-token-transfer/02-avalanche-starter-kit/06-pause-and-resume.mdx
@@ -0,0 +1,11 @@
+---
+title: Pause and Resume
+description: If you've deployed an Avalanche L1, you can preserve and restore the state of your deployed Avalanche L1s.
+updated: 2024-10-07
+authors: [0xstt]
+icon: BookOpen
+---
+
+import PauseAndResume from "@/content/common/avalanche-starter-kit/pause-and-resume.mdx";
+
+<PauseAndResume />
diff --git a/content/course/interchain-token-transfer/index.mdx b/content/course/interchain-token-transfer/index.mdx
index 35a2ec58..dd407036 100644
--- a/content/course/interchain-token-transfer/index.mdx
+++ b/content/course/interchain-token-transfer/index.mdx
@@ -14,6 +14,8 @@ A significant innovation in blockchain is the development of multi-chain systems
 
 Cross-chain communication is a crucial building block of multi-chain systems. Utilizing Avalanche Interchain Messaging and Interchain Token Transfer is an incredibly easy way to build cross-Avalanche L1 dApps, since developers can build on top of an extensive, audited development framework. 
 
+Transfering tokens between multiple chains is a common use case in multi-chain systems. This course will help you understand how to transfer assets between multiple Avalanche blockchains using the Avalanche Interchain Token Transfer protocol.
+
 ## Course Content
 
 ### Avalanche Starter Kit
diff --git a/content/course/l1-tokenomics/04-staking/03-staking-contract-post-etna.mdx b/content/course/l1-tokenomics/04-staking/03-staking-contract-post-etna.mdx
index 41f5d22a..1863e1f2 100644
--- a/content/course/l1-tokenomics/04-staking/03-staking-contract-post-etna.mdx
+++ b/content/course/l1-tokenomics/04-staking/03-staking-contract-post-etna.mdx
@@ -146,4 +146,6 @@ Delegation rewards are distributed in the call to `completeEndDelegation`.
 
 #### Delegation Fees
 
-Delegation fees owed to Validators are _not_ distributed when the Validation ends as to bound the amount of gas consumed in the call to `completeEndValidation`. Instead, `claimDelegationFees` may be called after the Validation is completed.
\ No newline at end of file
+Delegation fees owed to Validators are _not_ distributed when the Validation ends as to bound the amount of gas consumed in the call to `completeEndValidation`. Instead, `claimDelegationFees` may be called after the Validation is completed.
+
+<Quiz quizId="210" />
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/05-transaction-fees/02-transaction-fee-configuration.mdx b/content/course/l1-tokenomics/05-transaction-fees/02-transaction-fee-configuration.mdx
index 704ca72f..9e24335c 100644
--- a/content/course/l1-tokenomics/05-transaction-fees/02-transaction-fee-configuration.mdx
+++ b/content/course/l1-tokenomics/05-transaction-fees/02-transaction-fee-configuration.mdx
@@ -72,3 +72,4 @@ Specifies the maximum amount of gas charged for the production of a block.
 
 Defines how much to increase or decrease the block gas cost based on the time elapsed since the previous block. If a block is produced at the target rate, the block gas cost remains the same as the parent block. If the production rate deviates from the target, the block gas cost is adjusted by the `blockGasCostStep` value for each second faster or slower than the target block rate.
 
+<Quiz quizId="211" />
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/06-distribution/01-initial-allocation.mdx b/content/course/l1-tokenomics/06-distribution/01-initial-allocation.mdx
index cc2b6def..8d6e86fa 100644
--- a/content/course/l1-tokenomics/06-distribution/01-initial-allocation.mdx
+++ b/content/course/l1-tokenomics/06-distribution/01-initial-allocation.mdx
@@ -31,3 +31,5 @@ A significant portion of tokens may be allocated to the community through mechan
 Some tokens may be allocated to a reserve or treasury to fund ongoing development, marketing, and ecosystem growth initiatives. This reserve can be managed by a DAO or another entity tasked with allocating funds for the network's benefit.
 
 > **Tip:** Transparent and equitable token allocation mechanisms are essential for fostering trust and confidence in the network among its stakeholders.
+
+<Quiz quizId="212" />
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/06-distribution/03-bonding-curves.mdx b/content/course/l1-tokenomics/06-distribution/03-bonding-curves.mdx
index fa7b8f8e..5588cb29 100644
--- a/content/course/l1-tokenomics/06-distribution/03-bonding-curves.mdx
+++ b/content/course/l1-tokenomics/06-distribution/03-bonding-curves.mdx
@@ -163,4 +163,5 @@ Explanation
 
 Bonding curves offer a powerful tool for automated price discovery and token issuance in decentralized networks like Avalanche. They enable projects to create self-sustaining economies with built-in liquidity and dynamic pricing. Understanding bonding curves is essential for developers and stakeholders involved in tokenomics and decentralized finance.
 
-By carefully designing bonding curve parameters and smart contracts, projects can align incentives, promote fair participation, and foster sustainable growth within their ecosystems.
\ No newline at end of file
+By carefully designing bonding curve parameters and smart contracts, projects can align incentives, promote fair participation, and foster sustainable growth within their ecosystems.
+<Quiz quizId="213"/>
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/07-governance/02-governance-models.mdx b/content/course/l1-tokenomics/07-governance/02-governance-models.mdx
index 4dc9de50..be187803 100644
--- a/content/course/l1-tokenomics/07-governance/02-governance-models.mdx
+++ b/content/course/l1-tokenomics/07-governance/02-governance-models.mdx
@@ -161,4 +161,6 @@ Governance models are continually evolving to address new challenges and integra
 
 Governance models are foundational to the success of blockchain networks like Avalanche. They shape decision-making processes, power distribution, and the network’s ability to adapt over time. By designing and implementing effective governance structures, the community can ensure the network remains secure, innovative, and aligned with participant interests.
 
-Understanding these models enables stakeholders to contribute meaningfully to the network’s evolution. As the ecosystem grows, collaborative and well-structured governance will be key to navigating challenges and seizing opportunities in the decentralized landscape.
\ No newline at end of file
+Understanding these models enables stakeholders to contribute meaningfully to the network’s evolution. As the ecosystem grows, collaborative and well-structured governance will be key to navigating challenges and seizing opportunities in the decentralized landscape.
+
+<Quiz quizId="214"/>
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/07-governance/03-daos.mdx b/content/course/l1-tokenomics/07-governance/03-daos.mdx
index 25649af1..bf6aea20 100644
--- a/content/course/l1-tokenomics/07-governance/03-daos.mdx
+++ b/content/course/l1-tokenomics/07-governance/03-daos.mdx
@@ -47,3 +47,5 @@ As the Avalanche network grows, DAOs will likely become increasingly important i
 
 In the context of Avalanche Layer 1 (L1) tokenomics, DAOs exemplify how decentralized governance models can effectively manage resources, drive innovation, and align diverse stakeholder interests. Understanding and participating in DAOs allows individuals to influence the network’s evolution and contribute to its long-term success.
 
+
+<Quiz quizId="215"/>
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/certificate.mdx b/content/course/l1-tokenomics/certificate.mdx
new file mode 100644
index 00000000..1c1dd067
--- /dev/null
+++ b/content/course/l1-tokenomics/certificate.mdx
@@ -0,0 +1,14 @@
+---
+title: Course Completion Certificate
+updated: 2024-10-15
+authors: [owenwahlgren]
+icon: BadgeCheck
+---
+
+import CertificatePage from '@/components/certificates';
+
+You've made it to the end of the course! Let's check your progress and get your certificate.
+
+<CertificatePage courseId="l1-tokenomics"/>
+
+Thank you for participating in this course. We hope you found it informative and enjoyable!
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/meta.json b/content/course/l1-tokenomics/meta.json
index 932108a1..9d3f642d 100644
--- a/content/course/l1-tokenomics/meta.json
+++ b/content/course/l1-tokenomics/meta.json
@@ -17,6 +17,8 @@
     "---Token Distribution---",
     "...06-distribution",
     "---Governance---",
-    "...07-governance"
+    "...07-governance",
+    "---Conclusion---",
+    "certificate"
   ]
 }
diff --git a/content/course/multi-chain-architecture/02-custom-blockchains/01-custom-blockchains.mdx b/content/course/multi-chain-architecture/02-custom-blockchains/01-custom-blockchains.mdx
index 2b48c4ce..916b14c5 100644
--- a/content/course/multi-chain-architecture/02-custom-blockchains/01-custom-blockchains.mdx
+++ b/content/course/multi-chain-architecture/02-custom-blockchains/01-custom-blockchains.mdx
@@ -6,19 +6,19 @@ authors: [usmaneth]
 icon: Book
 ---
 
-An Avalanche Custom Blockchain is a sovereign network that defines its own rules for membership and token economics. It's validated by a dynamic subset of Avalanche validators working together to achieve consensus on the blockchain's state.
+An Avalanche L1 is a sovereign network that defines its own rules for membership and token economics. It's validated by a dynamic subset of Avalanche validators working together to achieve consensus on the blockchain's state.
 
 ## Key Concepts
 
 - Custom Blockchain: A unique blockchain within the Avalanche ecosystem.
-- Validator Subset: A group of validators responsible for a specific blockchain or set of blockchains.
-- Custom Blockchain Network: A subset of validators united to validate one or more blockchains.
+- Validator Set: A group of validators responsible for a specific blockchain or set of blockchains.
+- Custom Blockchain Network: A set of validators united to validate one or more blockchains.
 
 ## Relationship Between Blockchains and Avalanche L1s
 
-- Each blockchain is validated by exactly one custom network.
+- Each blockchain is validated by exactly one Custom Network.
 - A Custom Network can validate multiple blockchains.
-- A validator may participate in multiple custom networks.
+- A validator may participate in multiple Custom Networks.
 
 ## The Primary Network
 
diff --git a/content/course/multi-chain-architecture/02-custom-blockchains/02-benefits-of-custom-blockchains.mdx b/content/course/multi-chain-architecture/02-custom-blockchains/02-benefits-of-custom-blockchains.mdx
index e9301ee8..f3529c28 100644
--- a/content/course/multi-chain-architecture/02-custom-blockchains/02-benefits-of-custom-blockchains.mdx
+++ b/content/course/multi-chain-architecture/02-custom-blockchains/02-benefits-of-custom-blockchains.mdx
@@ -52,3 +52,4 @@ Custom blockchains, especially within the Avalanche ecosystem, can be designed w
 - Cross-Chain Communication: Facilitate seamless interaction between different custom blockchains in the Avalanche network leverage Avalanche Warp Messaging.
 - Asset Bridges: Create efficient bridges for asset transfers between your custom blockchain and other networks such as the Avalanche Interchain Token Transfer. 
 
+<Quiz quizId="401"/>
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/02-custom-blockchains/03-custom-blockchains-vs-layer-2.mdx b/content/course/multi-chain-architecture/02-custom-blockchains/03-custom-blockchains-vs-layer-2.mdx
index 0fc35d4a..a6039f30 100644
--- a/content/course/multi-chain-architecture/02-custom-blockchains/03-custom-blockchains-vs-layer-2.mdx
+++ b/content/course/multi-chain-architecture/02-custom-blockchains/03-custom-blockchains-vs-layer-2.mdx
@@ -21,3 +21,5 @@ Avalanche's multi-chain structure offers great interoperability and flexibility,
 ## Performance and Cost
 
 Both approaches aim to offer higher transaction throughput and lower fees compared to traditional single-chain systems. Avalanche achieves this through parallel processing across its Avalanche L1s, while rollups offload computation off-chain. However, users of Layer 2 solutions might experience delays when transferring assets back to Layer 1. Furthermore, since Layer 2 systems need to checkpoint their activity to the L1, which effectively sets a price floor and couples the prices of the L1 gas token to the L2 gas token. In Avalanche, the gas tokens of an Avalanche L1 are completely independent from AVAX.
+
+<Quiz quizId="402"/>
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/03-avalanche-starter-kit/07-pause-and-resume.mdx b/content/course/multi-chain-architecture/03-avalanche-starter-kit/07-pause-and-resume.mdx
new file mode 100644
index 00000000..c734a718
--- /dev/null
+++ b/content/course/multi-chain-architecture/03-avalanche-starter-kit/07-pause-and-resume.mdx
@@ -0,0 +1,11 @@
+---
+title: Pause and Resume
+description: If you've deployed an Avalanche L1, you can preserve and restore the state of your deployed Avalanche L1s.
+updated: 2024-10-07
+authors: [0xstt]
+icon: BookOpen
+---
+
+import PauseAndResume from "@/content/common/avalanche-starter-kit/pause-and-resume.mdx";
+
+<PauseAndResume />
diff --git a/content/course/multi-chain-architecture/04-independent-tokenomics/02-transaction-fees.mdx b/content/course/multi-chain-architecture/04-independent-tokenomics/02-transaction-fees.mdx
index 06d3d161..8709b2d8 100644
--- a/content/course/multi-chain-architecture/04-independent-tokenomics/02-transaction-fees.mdx
+++ b/content/course/multi-chain-architecture/04-independent-tokenomics/02-transaction-fees.mdx
@@ -8,4 +8,5 @@ icon: BookOpen
 
 import TransactionFees from '@/content/common/multi-chain-architecture/transaction-fees.mdx';
 
-<TransactionFees />
\ No newline at end of file
+<TransactionFees />
+<Quiz quizId="403"/>
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/04-independent-tokenomics/07-native-token-minting-rights.mdx b/content/course/multi-chain-architecture/04-independent-tokenomics/07-native-token-minting-rights.mdx
index 29e92022..654c5b75 100644
--- a/content/course/multi-chain-architecture/04-independent-tokenomics/07-native-token-minting-rights.mdx
+++ b/content/course/multi-chain-architecture/04-independent-tokenomics/07-native-token-minting-rights.mdx
@@ -14,4 +14,6 @@ import NativeMinter from "@/content/common/evm-precompiles/native-minter.mdx";
 
 <NativeMinter />
 
-In the upcoming chapter, we will only use an admin address in order to keep the exercise simple.
\ No newline at end of file
+In the upcoming chapter, we will only use an admin address in order to keep the exercise simple.
+
+<Quiz quizId="410"/>
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/05-interoperability/02-interoperability-use-cases.mdx b/content/course/multi-chain-architecture/05-interoperability/02-interoperability-use-cases.mdx
index fa9ec12a..95aaed99 100644
--- a/content/course/multi-chain-architecture/05-interoperability/02-interoperability-use-cases.mdx
+++ b/content/course/multi-chain-architecture/05-interoperability/02-interoperability-use-cases.mdx
@@ -59,3 +59,5 @@ Interoperability enables decentralized governance processes that span multiple b
 ## Conclusion
 
 Interoperability on Avalanche unlocks a multitude of use cases, enhancing the flexibility, utility, and security of blockchain interactions. By facilitating seamless cross-chain operations, Avalanche is at the forefront of creating a more connected and interoperable blockchain ecosystem.
+
+<Quiz quizId="404"/>
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/05-interoperability/03-icm-and-icm-protocol.mdx b/content/course/multi-chain-architecture/05-interoperability/03-icm-and-icm-protocol.mdx
index e193b9da..ef2c1ece 100644
--- a/content/course/multi-chain-architecture/05-interoperability/03-icm-and-icm-protocol.mdx
+++ b/content/course/multi-chain-architecture/05-interoperability/03-icm-and-icm-protocol.mdx
@@ -55,3 +55,5 @@ The ICM Protocol leverages Avalanche’s unique consensus mechanism to securely
 ## Conclusion
 
 Interchain Messaging and the Interchain Messaging Protocol are fundamental components of Avalanche's interoperability framework. They empower developers to build sophisticated cross-chain applications and provide users with seamless experiences across multiple blockchains. By enabling secure and efficient asset transfers and inter-chain communication, Avalanche continues to push the boundaries of what’s possible in a decentralized, interoperable blockchain ecosystem.
+
+<Quiz quizId="405"/>
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/06-permissioning-users/01-permissioning.mdx b/content/course/multi-chain-architecture/06-permissioning-users/01-permissioning.mdx
index 6394832e..16dd7f03 100644
--- a/content/course/multi-chain-architecture/06-permissioning-users/01-permissioning.mdx
+++ b/content/course/multi-chain-architecture/06-permissioning-users/01-permissioning.mdx
@@ -14,4 +14,6 @@ Permissioning your Avalanche L1 is an optional feature of having your own L1 blo
 
 These permissions don't necessarily have to be administered by a centralized entity. There could also be a DAO in charge of determining who should be allowed to use the blockchain. 
 
-In the upcoming lessons, you will learn about the different levels of Permissions and how they can be configured for your Avalanche L1.
\ No newline at end of file
+In the upcoming lessons, you will learn about the different levels of Permissions and how they can be configured for your Avalanche L1.
+
+<Quiz quizId="406"/>
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/06-permissioning-users/02-compliance.mdx b/content/course/multi-chain-architecture/06-permissioning-users/02-compliance.mdx
index 9b11bc83..c9692e1a 100644
--- a/content/course/multi-chain-architecture/06-permissioning-users/02-compliance.mdx
+++ b/content/course/multi-chain-architecture/06-permissioning-users/02-compliance.mdx
@@ -24,4 +24,6 @@ An additional risk to consider is that businesses may operate within an environm
 
 Avalanche L1s can limit who deploys smart contracts on the blockchain. Consequently, those involved in the creation of contracts can be held accountable. This level of control reassures institutions, ensuring that all protocols they engage with are fully compliant with existing laws. 
 
-Beyond compliance advantages, this approach helps to maintain a blockchain free from an excess of smart contracts that could otherwise congest the system.
\ No newline at end of file
+Beyond compliance advantages, this approach helps to maintain a blockchain free from an excess of smart contracts that could otherwise congest the system.
+
+<Quiz quizId="407"/>
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/07-permissioning-validators/01-permissioning-validators.mdx b/content/course/multi-chain-architecture/07-permissioning-validators/01-permissioning-validators.mdx
index e7aa8ce8..9ea56954 100644
--- a/content/course/multi-chain-architecture/07-permissioning-validators/01-permissioning-validators.mdx
+++ b/content/course/multi-chain-architecture/07-permissioning-validators/01-permissioning-validators.mdx
@@ -27,4 +27,6 @@ Government entities may find value in launching a blockchain with a permissioned
 
 ## Financial Institutions: 
 
-Banks, payment processors, and other financial institutions could be interested in a permissioned validator set for blockchain solutions related to payments, remittances, or settlement systems. These institutions often require a level of control over the network to maintain regulatory compliance, prevent money laundering, and ensure adherence to Anti-Money Laundering (AML) regulations.
\ No newline at end of file
+Banks, payment processors, and other financial institutions could be interested in a permissioned validator set for blockchain solutions related to payments, remittances, or settlement systems. These institutions often require a level of control over the network to maintain regulatory compliance, prevent money laundering, and ensure adherence to Anti-Money Laundering (AML) regulations.
+
+<Quiz quizId="408"/>
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/07-permissioning-validators/02-private-blockchains.mdx b/content/course/multi-chain-architecture/07-permissioning-validators/02-private-blockchains.mdx
index f7e4b632..c0f42444 100644
--- a/content/course/multi-chain-architecture/07-permissioning-validators/02-private-blockchains.mdx
+++ b/content/course/multi-chain-architecture/07-permissioning-validators/02-private-blockchains.mdx
@@ -22,4 +22,6 @@ This has made private, permissioned blockchains an attractive option for busines
 
 The data of Avalanche L1s, by default, are publicly available. This means that every node can sync and listen to ongoing transactions/blocks in these blockchains, even if they're not validating the network. Nodes may do this for indexing purposes or just having access to the current state of the blockchain without relying on third-parties.
 
-Avalanche L1 validators can choose not to publish data from their blockchains. If a node sets `validatorOnly` to true, the node exchanges messages only with the blockchain's validators. Other peers won't be able to learn contents of this blockchain from their nodes.
\ No newline at end of file
+Avalanche L1 validators can choose not to publish data from their blockchains. If a node sets `validatorOnly` to true, the node exchanges messages only with the blockchain's validators. Other peers won't be able to learn contents of this blockchain from their nodes.
+
+<Quiz quizId="409"/>
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/certificate.mdx b/content/course/multi-chain-architecture/certificate.mdx
new file mode 100644
index 00000000..bfeb6036
--- /dev/null
+++ b/content/course/multi-chain-architecture/certificate.mdx
@@ -0,0 +1,14 @@
+---
+title: Course Completion Certificate
+updated: 2024-10-11
+authors: [owenwahlgren]
+icon: BadgeCheck
+---
+
+import CertificatePage from '@/components/certificates';
+
+You've made it to the end of the course. Let's check your progress and get your certificate.
+
+<CertificatePage courseId="multichain-architecture"/>
+
+Thank you for participating in this course. We hope you found it informative and enjoyable!
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/meta.json b/content/course/multi-chain-architecture/meta.json
index 037540e1..de559ed4 100644
--- a/content/course/multi-chain-architecture/meta.json
+++ b/content/course/multi-chain-architecture/meta.json
@@ -16,6 +16,8 @@
     "---Permissioning Validators---",
     "...07-permissioning-validators",
     "---Customizability---",
-    "...08-customizability"
+    "...08-customizability",
+    "---Conclusion---",
+    "certificate"
   ]
 }
diff --git a/public/common-images/codespaces/specify-idle-timeout.png b/public/common-images/codespaces/specify-idle-timeout.png
new file mode 100644
index 00000000..d8cdaa3e
Binary files /dev/null and b/public/common-images/codespaces/specify-idle-timeout.png differ
diff --git a/public/common-images/codespaces/specify-spending-limit.png b/public/common-images/codespaces/specify-spending-limit.png
new file mode 100644
index 00000000..29ce644e
Binary files /dev/null and b/public/common-images/codespaces/specify-spending-limit.png differ