diff --git a/app/(home)/icons.tsx b/app/(home)/icons.tsx
deleted file mode 100644
index 07ee9030..00000000
--- a/app/(home)/icons.tsx
+++ /dev/null
@@ -1,455 +0,0 @@
-import type { SVGProps } from 'react';
-
-export function NextSVG(props: SVGProps<SVGSVGElement>): React.ReactElement {
-  return (
-    <svg
-      aria-label="Next.js logomark"
-      data-theme="dark"
-      height="80"
-      role="img"
-      viewBox="0 0 180 180"
-      width="80"
-      {...props}
-    >
-      <mask
-        height="180"
-        id=":R0:mask0_408_134"
-        maskUnits="userSpaceOnUse"
-        style={{ maskType: 'alpha' }}
-        width="180"
-        x="0"
-        y="0"
-      >
-        <circle cx="90" cy="90" fill="black" r="90" />
-      </mask>
-      <g mask="url(#:R0:mask0_408_134)">
-        <circle
-          cx="90"
-          cy="90"
-          data-circle="true"
-          fill="black"
-          r="90"
-          stroke="white"
-          strokeWidth="6px"
-        />
-        <path
-          d="M149.508 157.52L69.142 54H54V125.97H66.1136V69.3836L139.999 164.845C143.333 162.614 146.509 160.165 149.508 157.52Z"
-          fill="url(#:R0:paint0_linear_408_134)"
-        />
-        <rect
-          fill="url(#:R0:paint1_linear_408_134)"
-          height="72"
-          width="12"
-          x="115"
-          y="54"
-        />
-      </g>
-      <defs>
-        <linearGradient
-          gradientUnits="userSpaceOnUse"
-          id=":R0:paint0_linear_408_134"
-          x1="109"
-          x2="144.5"
-          y1="116.5"
-          y2="160.5"
-        >
-          <stop stopColor="white" />
-          <stop offset="1" stopColor="white" stopOpacity="0" />
-        </linearGradient>
-        <linearGradient
-          gradientUnits="userSpaceOnUse"
-          id=":R0:paint1_linear_408_134"
-          x1="121"
-          x2="120.799"
-          y1="54"
-          y2="106.875"
-        >
-          <stop stopColor="white" />
-          <stop offset="1" stopColor="white" stopOpacity="0" />
-        </linearGradient>
-      </defs>
-    </svg>
-  );
-}
-
-export function SourceSVG(props: SVGProps<SVGSVGElement>): React.ReactElement {
-  return (
-    <svg
-      width="1320"
-      height="800"
-      viewBox="0 0 1320 800"
-      fill="none"
-      {...props}
-    >
-      <path
-        d="M1308 599C1308 681.843 1240.84 749 1158 749C1075.16 749 1008 681.843 1008 599C1008 516.157 1075.16 449 1158 449C1240.84 449 1308 516.157 1308 599Z"
-        fill="url(#paint0_radial_31_18)"
-      />
-      <rect
-        x="1076.5"
-        y="513.5"
-        width="164"
-        height="173.545"
-        rx="82"
-        fill="#1D1A3F"
-      />
-      <path
-        fillRule="evenodd"
-        clipRule="evenodd"
-        d="M1155.78 547.404C1159.18 544.9 1163.83 544.945 1167.19 547.514L1201.42 573.746C1206.35 577.527 1206.35 584.941 1201.42 588.722L1188.36 598.727L1201.64 609.359C1206.46 613.226 1206.33 620.592 1201.37 624.287L1166.23 650.459C1162.62 653.149 1157.61 652.931 1154.25 649.939L1126.75 625.474L1122.91 622.181C1105.75 607.486 1107.86 580.423 1127.06 568.544L1155.78 547.404ZM1183.3 594.667L1167.34 581.882C1163.93 579.151 1159.09 579.099 1155.62 581.755L1143.81 590.804C1138.88 594.586 1138.88 602 1143.81 605.781L1155.71 614.896C1159.12 617.506 1163.86 617.506 1167.26 614.896L1183.21 602.676L1197.68 614.266C1199.29 615.556 1199.24 618.011 1197.59 619.243L1162.45 645.416C1161.25 646.312 1159.58 646.239 1158.45 645.242L1130.94 620.756L1127.02 617.405C1113.08 605.46 1114.83 583.441 1130.49 573.836L1130.6 573.766L1159.53 552.469C1160.67 551.635 1162.22 551.649 1163.34 552.506L1197.57 578.738C1199.21 579.998 1199.21 582.47 1197.57 583.73L1183.3 594.667ZM1178.14 598.617L1163.41 609.904C1162.28 610.774 1160.7 610.774 1159.56 609.904L1147.67 600.789C1146.02 599.528 1146.02 597.057 1147.67 595.796L1159.47 586.748C1160.63 585.862 1162.24 585.88 1163.38 586.79L1178.14 598.617Z"
-        fill="#7C3AED"
-      />
-      <path
-        d="M1142 264C1142 379.98 1047.98 474 932 474C816.02 474 722 379.98 722 264C722 148.02 816.02 54 932 54C1047.98 54 1142 148.02 1142 264Z"
-        fill="url(#paint1_radial_31_18)"
-      />
-      <path
-        d="M1051.18 230.402H812.815C808.169 230.402 804.402 234.169 804.402 238.815V325.75C804.402 330.396 808.169 334.163 812.815 334.163H1051.18C1055.83 334.163 1059.6 330.396 1059.6 325.75V238.815C1059.6 234.169 1055.83 230.402 1051.18 230.402Z"
-        fill="#FF774C"
-      />
-      <path
-        d="M833.848 311.261V264.522L859.554 290.228L885.728 264.054V310.794"
-        stroke="black"
-        strokeWidth="9"
-      />
-      <path d="M934.804 303.783V249.098" stroke="black" strokeWidth="9" />
-      <path
-        d="M909.565 279.946L934.804 305.185L960.044 279.946"
-        stroke="black"
-        strokeWidth="9"
-      />
-      <path
-        d="M1032.02 306.101L977.337 251.435M977.804 306.12L1032.49 251.435"
-        stroke="black"
-        strokeWidth="9"
-      />
-      <g>
-        <path
-          d="M454.859 332.277H534.826V347.036H503.104V424.685H487.242V347.036H454.859V332.277Z"
-          fill="currentColor"
-        />
-        <path
-          d="M323.344 332.277V347.036H259.246V370.78H310.794V385.54H259.246V409.925H323.344V424.685H243.385V347.036H243.378V332.277H323.344Z"
-          fill="currentColor"
-        />
-        <path
-          d="M363.274 332.315H342.517L416.865 424.724H437.682L400.504 378.551L437.623 332.386L416.865 332.418L390.111 365.644L363.274 332.315Z"
-          fill="currentColor"
-        />
-        <path
-          d="M384.574 398.323L374.179 385.398L342.458 424.794H363.274L384.574 398.323Z"
-          fill="currentColor"
-        />
-        <path
-          fillRule="evenodd"
-          clipRule="evenodd"
-          d="M243.941 424.685L169.493 332.238H149.667V424.647H165.528V351.99L224.015 424.685H243.941Z"
-          fill="currentColor"
-        />
-        <path
-          d="M538.391 424.121C537.229 424.121 536.241 423.718 535.414 422.913C534.586 422.109 534.177 421.134 534.188 419.98C534.177 418.857 534.586 417.894 535.414 417.089C536.241 416.284 537.229 415.882 538.391 415.882C539.508 415.882 540.486 416.284 541.313 417.089C542.152 417.894 542.571 418.857 542.582 419.98C542.571 420.742 542.377 421.441 541.99 422.066C541.593 422.702 541.088 423.199 540.453 423.559C539.83 423.93 539.142 424.121 538.391 424.121Z"
-          fill="currentColor"
-        />
-        <path
-          d="M565.462 385.192H572.491V412.27C572.481 414.759 571.942 416.888 570.89 418.678C569.826 420.467 568.353 421.833 566.462 422.797C564.582 423.75 562.378 424.237 559.874 424.237C557.584 424.237 555.532 423.824 553.705 423.019C551.878 422.215 550.428 421.007 549.364 419.419C548.288 417.83 547.762 415.85 547.762 413.478H554.802C554.812 414.516 555.049 415.416 555.5 416.168C555.951 416.919 556.574 417.491 557.37 417.894C558.175 418.296 559.1 418.497 560.142 418.497C561.271 418.497 562.238 418.264 563.022 417.788C563.807 417.322 564.409 416.623 564.829 415.691C565.236 414.77 565.452 413.626 565.462 412.27V385.192Z"
-          fill="currentColor"
-        />
-        <path
-          d="M601.411 395.782C601.239 394.14 600.486 392.859 599.176 391.948C597.853 391.027 596.145 390.572 594.049 390.572C592.577 390.572 591.309 390.794 590.256 391.228C589.203 391.673 588.386 392.266 587.826 393.018C587.268 393.77 586.989 394.628 586.966 395.591C586.966 396.396 587.16 397.095 587.536 397.677C587.913 398.27 588.417 398.768 589.073 399.171C589.718 399.584 590.438 399.922 591.223 400.198C592.018 400.473 592.814 400.706 593.608 400.897L597.273 401.797C598.746 402.136 600.175 402.591 601.54 403.174C602.904 403.746 604.141 404.476 605.225 405.355C606.311 406.234 607.171 407.293 607.805 408.532C608.439 409.771 608.762 411.222 608.762 412.895C608.762 415.151 608.182 417.131 607.009 418.847C605.838 420.552 604.151 421.886 601.937 422.85C599.734 423.803 597.069 424.29 593.931 424.29C590.9 424.29 588.256 423.824 586.032 422.892C583.797 421.971 582.055 420.615 580.798 418.836C579.541 417.057 578.864 414.886 578.767 412.334H585.731C585.828 413.668 586.258 414.78 586.989 415.681C587.73 416.57 588.697 417.227 589.88 417.671C591.073 418.106 592.405 418.328 593.877 418.328C595.414 418.328 596.768 418.095 597.939 417.64C599.1 417.184 600.013 416.549 600.669 415.723C601.336 414.907 601.669 413.944 601.68 412.842C601.669 411.836 601.367 411 600.787 410.343C600.196 409.687 599.38 409.136 598.337 408.691C597.284 408.246 596.059 407.844 594.662 407.494L590.213 406.372C586.999 405.556 584.452 404.317 582.592 402.655C580.723 400.992 579.798 398.789 579.798 396.025C579.798 393.759 580.421 391.768 581.68 390.063C582.926 388.358 584.635 387.035 586.795 386.092C588.966 385.139 591.416 384.673 594.145 384.673C596.919 384.673 599.347 385.139 601.443 386.092C603.538 387.035 605.183 388.348 606.375 390.021C607.569 391.694 608.192 393.611 608.225 395.782H601.411Z"
-          fill="currentColor"
-        />
-      </g>
-      <path
-        d="M687 378C687 549.208 548.208 688 377 688C205.792 688 67 549.208 67 378C67 206.792 205.792 68 377 68C548.208 68 687 206.792 687 378Z"
-        fill="url(#paint2_radial_31_18)"
-      />
-      <defs>
-        <radialGradient
-          id="paint0_radial_31_18"
-          cx="0"
-          cy="0"
-          r="1"
-          gradientUnits="userSpaceOnUse"
-          gradientTransform="translate(1158 599) rotate(90) scale(150)"
-        >
-          <stop offset="0.749" stopOpacity="0" />
-          <stop offset="1" stopColor="#7C3AED" stopOpacity="0.3" />
-        </radialGradient>
-        <radialGradient
-          id="paint1_radial_31_18"
-          cx="0"
-          cy="0"
-          r="1"
-          gradientUnits="userSpaceOnUse"
-          gradientTransform="translate(932 264) rotate(90) scale(210)"
-        >
-          <stop offset="0.749" stopOpacity="0" />
-          <stop offset="1" stopColor="#FF774C" stopOpacity="0.3" />
-        </radialGradient>
-        <radialGradient
-          id="paint2_radial_31_18"
-          cx="0"
-          cy="0"
-          r="1"
-          gradientUnits="userSpaceOnUse"
-          gradientTransform="translate(377 378) rotate(90) scale(310)"
-        >
-          <stop offset="0.749" stopOpacity="0" />
-          <stop offset="1" stopColor="currentColor" stopOpacity="0.3" />
-        </radialGradient>
-      </defs>
-    </svg>
-  );
-}
-
-export function VercelLogo(props: SVGProps<SVGSVGElement>): React.ReactElement {
-  return (
-    <svg
-      aria-label="Vercel logotype"
-      height="64"
-      role="img"
-      viewBox="0 0 283 64"
-      width="283"
-      {...props}
-    >
-      <path
-        d="M141.68 16.25c-11.04 0-19 7.2-19 18s8.96 18 20 18c6.67 0 12.55-2.64 16.19-7.09l-7.65-4.42c-2.02 2.21-5.09 3.5-8.54 3.5-4.79 0-8.86-2.5-10.37-6.5h28.02c.22-1.12.35-2.28.35-3.5 0-10.79-7.96-17.99-19-17.99zm-9.46 14.5c1.25-3.99 4.67-6.5 9.45-6.5 4.79 0 8.21 2.51 9.45 6.5h-18.9zm117.14-14.5c-11.04 0-19 7.2-19 18s8.96 18 20 18c6.67 0 12.55-2.64 16.19-7.09l-7.65-4.42c-2.02 2.21-5.09 3.5-8.54 3.5-4.79 0-8.86-2.5-10.37-6.5h28.02c.22-1.12.35-2.28.35-3.5 0-10.79-7.96-17.99-19-17.99zm-9.45 14.5c1.25-3.99 4.67-6.5 9.45-6.5 4.79 0 8.21 2.51 9.45 6.5h-18.9zm-39.03 3.5c0 6 3.92 10 10 10 4.12 0 7.21-1.87 8.8-4.92l7.68 4.43c-3.18 5.3-9.14 8.49-16.48 8.49-11.05 0-19-7.2-19-18s7.96-18 19-18c7.34 0 13.29 3.19 16.48 8.49l-7.68 4.43c-1.59-3.05-4.68-4.92-8.8-4.92-6.07 0-10 4-10 10zm82.48-29v46h-9v-46h9zM37.59.25l36.95 64H.64l36.95-64zm92.38 5l-27.71 48-27.71-48h10.39l17.32 30 17.32-30h10.39zm58.91 12v9.69c-1-.29-2.06-.49-3.2-.49-5.81 0-10 4-10 10v14.8h-9v-34h9v9.2c0-5.08 5.91-9.2 13.2-9.2z"
-        fill="currentColor"
-      />
-    </svg>
-  );
-}
-
-export function NetlifyLogo(
-  props: SVGProps<SVGSVGElement>,
-): React.ReactElement {
-  return (
-    <svg
-      aria-label="Netlify"
-      width="512"
-      height="209"
-      viewBox="0 0 512 209"
-      {...props}
-    >
-      <g>
-        <path
-          d="M117.436 207.036V154.604L118.529 153.51H129.452L130.545 154.604V207.036L129.452 208.13H118.529L117.436 207.036Z"
-          fill="currentColor"
-        />
-        <path
-          d="M117.436 53.5225V1.09339L118.529 0H129.452L130.545 1.09339V53.5225L129.452 54.6159H118.529L117.436 53.5225Z"
-          fill="currentColor"
-        />
-        <path
-          d="M69.9539 169.238H68.4094L60.6869 161.512V159.967L78.7201 141.938L86.8976 141.942L87.9948 143.031V151.209L69.9539 169.238Z"
-          fill="currentColor"
-        />
-        <path
-          d="M69.9462 38.8917H68.4017L60.6792 46.6181V48.1626L78.7124 66.192L86.8899 66.1882L87.9871 65.0986V56.9212L69.9462 38.8917Z"
-          fill="currentColor"
-        />
-        <path
-          d="M1.09339 97.5104H75.3711L76.4645 98.6038V109.526L75.3711 110.62H1.09339L0 109.526V98.6038L1.09339 97.5104Z"
-          fill="currentColor"
-        />
-        <path
-          d="M440.999 97.5104H510.91L512.004 98.6038V109.526L510.91 110.62H436.633L435.539 109.526L439.905 98.6038L440.999 97.5104Z"
-          fill="currentColor"
-        />
-        <path
-          d="M212.056 108.727L210.963 109.821H177.079L175.986 110.914C175.986 113.101 178.173 119.657 186.916 119.657C190.196 119.657 193.472 118.564 194.566 116.377L195.659 115.284H208.776L209.869 116.377C208.776 122.934 203.313 132.774 186.916 132.774C168.336 132.774 159.589 119.657 159.589 104.357C159.589 89.0576 168.332 75.9408 185.822 75.9408C203.313 75.9408 212.056 89.0576 212.056 104.357V108.731V108.727ZM195.659 97.7971C195.659 96.7037 194.566 89.0538 185.822 89.0538C177.079 89.0538 175.986 96.7037 175.986 97.7971L177.079 98.8905H194.566L195.659 97.7971Z"
-          fill="currentColor"
-        />
-        <path
-          d="M242.66 115.284C242.66 117.47 243.753 118.564 245.94 118.564H255.776L256.87 119.657V130.587L255.776 131.681H245.94C236.103 131.681 227.36 127.307 227.36 115.284V91.2368L226.266 90.1434H218.617L217.523 89.05V78.1199L218.617 77.0265H226.266L227.36 75.9332V66.0965L228.453 65.0031H241.57L242.663 66.0965V75.9332L243.757 77.0265H255.78L256.874 78.1199V89.05L255.78 90.1434H243.757L242.663 91.2368V115.284H242.66Z"
-          fill="currentColor"
-        />
-        <path
-          d="M283.1 131.681H269.983L268.889 130.587V56.2636L269.983 55.1702H283.1L284.193 56.2636V130.587L283.1 131.681Z"
-          fill="currentColor"
-        />
-        <path
-          d="M312.61 68.2871H299.493L298.399 67.1937V56.2636L299.493 55.1702H312.61L313.703 56.2636V67.1937L312.61 68.2871ZM312.61 131.681H299.493L298.399 130.587V78.1237L299.493 77.0304H312.61L313.703 78.1237V130.587L312.61 131.681Z"
-          fill="currentColor"
-        />
-        <path
-          d="M363.98 56.2636V67.1937L362.886 68.2871H353.05C350.863 68.2871 349.769 69.3805 349.769 71.5672V75.9408L350.863 77.0342H361.793L362.886 78.1276V89.0576L361.793 90.151H350.863L349.769 91.2444V130.591L348.676 131.684H335.559L334.466 130.591V91.2444L333.372 90.151H325.723L324.629 89.0576V78.1276L325.723 77.0342H333.372L334.466 75.9408V71.5672C334.466 59.5438 343.209 55.1702 353.046 55.1702H362.882L363.976 56.2636H363.98Z"
-          fill="currentColor"
-        />
-        <path
-          d="M404.42 132.774C400.046 143.704 395.677 150.261 380.373 150.261H374.906L373.813 149.167V138.237L374.906 137.144H380.373C385.836 137.144 386.929 136.05 388.023 132.77V131.677L370.536 89.05V78.1199L371.63 77.0265H381.466L382.56 78.1199L395.677 115.284H396.77L409.887 78.1199L410.98 77.0265H420.817L421.91 78.1199V89.05L404.424 132.77L404.42 132.774Z"
-          fill="currentColor"
-        />
-        <path
-          d="M135.454 131.681L134.361 130.587L134.368 98.9172C134.368 93.4541 132.22 89.2182 125.625 89.0806C122.234 88.9926 118.354 89.0729 114.209 89.2488L113.59 89.8834L113.598 130.587L112.504 131.681H99.3913L98.2979 130.587V77.5388L99.3913 76.4454L128.901 76.1778C143.685 76.1778 149.668 86.3356 149.668 97.8009V130.587L148.575 131.681H135.454Z"
-          fill="currentColor"
-        />
-      </g>
-    </svg>
-  );
-}
-
-export function ContentlayerIcon(
-  props: SVGProps<SVGSVGElement>,
-): React.ReactElement {
-  return (
-    <svg
-      aria-label="Contentlayer Icon"
-      width="22"
-      height="24"
-      viewBox="0 0 22 24"
-      fill="none"
-      {...props}
-    >
-      <path
-        fillRule="evenodd"
-        clipRule="evenodd"
-        d="M10.43 0.92268C11.1426 0.398115 12.1177 0.407491 12.82 0.945665L19.9928 6.44198C21.0266 7.23419 21.0266 8.78771 19.9928 9.57992L17.2573 11.6761L20.0379 13.9037C21.0493 14.7139 21.022 16.2574 19.9826 17.0315L12.62 22.5153C11.8634 23.0788 10.8134 23.0332 10.1089 22.4063L4.34789 17.2802L3.54224 16.5903C-0.0530112 13.5114 0.390183 7.84094 4.41274 5.35212L10.43 0.92268ZM16.1955 10.8254L12.8515 8.14659C12.1375 7.57457 11.1235 7.56365 10.3972 8.12017L7.92298 10.0161C6.88913 10.8084 6.88913 12.3619 7.92298 13.1541L10.4154 15.064C11.129 15.6108 12.1224 15.6108 12.836 15.064L16.1773 12.5036L19.2086 14.932C19.5457 15.2021 19.5366 15.7166 19.1901 15.9747L11.8275 21.4585C11.5753 21.6463 11.2253 21.6311 10.9905 21.4221L5.2248 16.2918L4.40495 15.5895C1.48255 13.0869 1.84941 8.47338 5.13088 6.46078L5.15471 6.44617L11.2165 1.98398C11.454 1.80913 11.779 1.81225 12.0132 1.99164L19.1859 7.48796C19.5305 7.75203 19.5305 8.26987 19.1859 8.53394L16.1955 10.8254ZM15.1155 11.653L12.0291 14.018C11.7913 14.2003 11.4601 14.2003 11.2223 14.018L8.72984 12.1081C8.38523 11.844 8.38523 11.3262 8.72984 11.0621L11.2041 9.16615C11.4462 8.98065 11.7842 8.98429 12.0222 9.17496L15.1155 11.653Z"
-        fill="currentColor"
-      />
-    </svg>
-  );
-}
-
-export function OpenAPIIcon(
-  props: SVGProps<SVGSVGElement>,
-): React.ReactElement {
-  return (
-    <svg fill="currentColor" viewBox="0 0 512 512" {...props}>
-      <path d="m.2041784 294.3757629 135.0729218-.0019836c1.0510101 10.3673706 3.8841248 20.5690308 8.4522095 30.170166l-115.790062 69.7536621c-15.1902405-26.1945495-24.7731477-59.514801-27.7350693-99.9218445zm131.8023066 196.8029786 51.4067841-124.8407288c-5.2182617-2.7826233-10.2264862-6.0957642-14.9382172-9.9553528l-95.4706802 95.4720459c19.4898223 17.5570679 39.5628662 30.7094116 59.0021133 39.3240357zm-65.6047211-45.6471253 95.2843628-95.2860413c-4.9330902-4.9628906-9.4824219-10.8501282-13.6674042-17.6151123l-115.5066642 69.5827027c10.4910965 17.068634 22.1482162 31.8469848 33.8897056 43.3184509zm313.9973145 6.3275757-95.5295105-95.5253601c-1.0485229.8474121-2.1081848 1.671936-3.184845 2.4666138l69.7098999 115.7191772c9.7306824-6.0542297 19.3898926-13.8226013 29.0044556-22.6604309zm-36.7403565 27.5314331-69.5648804-115.4782104c-25.9638519 14.4993591-53.3182526 17.5528564-82.4063263 6.3365173l-51.3009338 124.5834045c70.200531 28.4663086 142.9616852 20.3123169 203.2721405-15.4417114zm-171.9461059-267.7199554-69.7079392-115.7203217c-10.1640396 6.5237503-19.8186493 14.1064529-29.0061646 22.6601715l95.5275803 95.5278625c1.0482636-.8363342 2.1095887-1.6597595 3.1865235-2.4677123zm-171.712616 73.5650482 134.7621918-.0019531c.291153-23.8374939 8.7095032-45.6818237 26.9275513-65.005722l-95.2863083-95.2865982c-43.9871293 46.6117019-65.8919295 100.1147994-66.4034348 160.2942733zm226.6937714-91.9374695.0058594-134.7585754c-44.7272644.2738724-84.0045013 12.32621-116.959053 32.5391159l69.5626297 115.4798889c13.0764617-7.6767197 28.6641692-12.980278 47.3905639-13.2604294zm186.4042816-37.1177979-99.4490967 99.4510498c2.2626953 6.6661987 3.7337646 13.5315552 4.4528503 20.4605103h135.0907898c-.8839111-40.9807434-14.4047241-80.9386597-40.0945434-119.9115601zm40.2803039 129.0516358h-134.747406c-.4680481 25.240448-9.8990479 48.2441101-26.923645 65.0134888l95.2901917 95.2860413c43.8191833-43.1222535 65.1218261-96.9472352 66.3808593-160.2995301zm-217.5386657-226.4921341-.0058594 135.0865784c7.082489.8026276 13.8835602 2.3424988 20.4658203 4.4556732l99.4153442-99.4150772c-35.131958-24.5753861-76.5397338-38.3618508-119.8753051-40.1271744zm195.1100769-56.1426528c-39.1646423 11.456749-55.5329285 55.1829491-38.7815857 88.6712189l-137.3599701 137.3618682c-32.4068756-16.1573944-74.9024811-1.5699463-87.7949829 36.0340729-15.7162628 45.8401489 24.2427673 91.8019104 71.7535858 82.5325317 42.0110779-8.1963196 62.3093567-54.1882019 44.4657593-90.0109253l137.4894714-137.4859314c34.6590576 17.2256775 79.5329285-1.0651627 89.3959961-41.653656 11.4301758-47.0377617-32.6579895-89.0548125-79.1682739-75.449179z" />
-    </svg>
-  );
-}
-
-export function EarthIcon(props: SVGProps<SVGSVGElement>): React.ReactElement {
-  return (
-    <svg width="900" height="900" viewBox="0 0 900 900" fill="none" {...props}>
-      <circle cx="450" cy="450" r="450" fill="url(#paint0_linear_26_28)" />
-      <g opacity={0.3}>
-        <path
-          d="M449.5 450C449.5 572.589 441.666 683.562 429.004 763.878C422.672 804.039 415.136 836.512 406.779 858.934C402.599 870.147 398.224 878.817 393.711 884.674C389.191 890.541 384.602 893.5 380 893.5C375.398 893.5 370.809 890.541 366.289 884.674C361.776 878.817 357.401 870.147 353.221 858.934C344.864 836.512 337.328 804.039 330.996 763.878C318.334 683.562 310.5 572.589 310.5 450C310.5 327.411 318.334 216.438 330.996 136.122C337.328 95.9608 344.864 63.4878 353.221 41.0664C357.401 29.8528 361.776 21.183 366.289 15.3257C370.809 9.45855 375.398 6.5 380 6.5C384.602 6.5 389.191 9.45855 393.711 15.3257C398.224 21.183 402.599 29.8528 406.779 41.0664C415.136 63.4878 422.672 95.9608 429.004 136.122C441.666 216.438 449.5 327.411 449.5 450Z"
-          stroke="currentColor"
-        />
-        <path
-          d="M449.5 450C449.5 567.875 433.834 674.57 408.52 751.779C395.862 790.386 380.8 821.593 364.099 843.138C347.393 864.689 329.107 876.5 310 876.5C290.893 876.5 272.607 864.689 255.901 843.138C239.2 821.593 224.138 790.386 211.48 751.779C186.166 674.57 170.5 567.875 170.5 450C170.5 332.125 186.166 225.43 211.48 148.221C224.138 109.614 239.2 78.4069 255.901 56.8621C272.607 35.3107 290.893 23.5 310 23.5C329.107 23.5 347.393 35.3107 364.099 56.8621C380.8 78.4069 395.862 109.614 408.52 148.221C433.834 225.43 449.5 332.125 449.5 450Z"
-          stroke="currentColor"
-        />
-        <path
-          d="M449.5 449.5C449.5 554.228 426.009 649.016 388.055 717.605C350.091 786.211 297.725 828.5 240 828.5C182.275 828.5 129.909 786.211 91.9451 717.605C53.9908 649.016 30.5 554.228 30.5 449.5C30.5 344.772 53.9908 249.984 91.9451 181.395C129.909 112.789 182.275 70.5 240 70.5C297.725 70.5 350.091 112.789 388.055 181.395C426.009 249.984 449.5 344.772 449.5 449.5Z"
-          stroke="currentColor"
-        />
-        <path
-          d="M450.5 450C450.5 572.589 458.334 683.562 470.996 763.878C477.328 804.039 484.864 836.512 493.221 858.934C497.401 870.147 501.776 878.817 506.289 884.674C510.809 890.541 515.398 893.5 520 893.5C524.602 893.5 529.191 890.541 533.711 884.674C538.224 878.817 542.599 870.147 546.779 858.934C555.136 836.512 562.672 804.039 569.004 763.878C581.666 683.562 589.5 572.589 589.5 450C589.5 327.411 581.666 216.438 569.004 136.122C562.672 95.9608 555.136 63.4878 546.779 41.0664C542.599 29.8528 538.224 21.183 533.711 15.3257C529.191 9.45855 524.602 6.5 520 6.5C515.398 6.5 510.809 9.45855 506.289 15.3257C501.776 21.183 497.401 29.8528 493.221 41.0664C484.864 63.4878 477.328 95.9608 470.996 136.122C458.334 216.438 450.5 327.411 450.5 450Z"
-          stroke="currentColor"
-        />
-        <path
-          d="M450.5 450C450.5 567.875 466.166 674.57 491.48 751.779C504.138 790.386 519.2 821.593 535.901 843.138C552.607 864.689 570.893 876.5 590 876.5C609.107 876.5 627.393 864.689 644.099 843.138C660.8 821.593 675.862 790.386 688.52 751.779C713.834 674.57 729.5 567.875 729.5 450C729.5 332.125 713.834 225.43 688.52 148.221C675.862 109.614 660.8 78.4069 644.099 56.8621C627.393 35.3107 609.107 23.5 590 23.5C570.893 23.5 552.607 35.3107 535.901 56.8621C519.2 78.4069 504.138 109.614 491.48 148.221C466.166 225.43 450.5 332.125 450.5 450Z"
-          stroke="currentColor"
-        />
-        <path
-          d="M450.5 449.5C450.5 554.228 473.991 649.016 511.945 717.605C549.909 786.211 602.275 828.5 660 828.5C717.725 828.5 770.091 786.211 808.055 717.605C846.009 649.016 869.5 554.228 869.5 449.5C869.5 344.772 846.009 249.984 808.055 181.395C770.091 112.789 717.725 70.5 660 70.5C602.275 70.5 549.909 112.789 511.945 181.395C473.991 249.984 450.5 344.772 450.5 449.5Z"
-          stroke="currentColor"
-        />
-        <path
-          d="M450 450.5C572.589 450.5 683.562 458.334 763.878 470.996C804.039 477.328 836.512 484.864 858.934 493.221C870.147 497.401 878.817 501.776 884.674 506.289C890.541 510.809 893.5 515.398 893.5 520C893.5 524.602 890.541 529.191 884.674 533.711C878.817 538.224 870.147 542.599 858.934 546.779C836.512 555.136 804.039 562.672 763.878 569.004C683.562 581.666 572.589 589.5 450 589.5C327.411 589.5 216.438 581.666 136.122 569.004C95.9608 562.672 63.4878 555.136 41.0664 546.779C29.8528 542.599 21.183 538.224 15.3257 533.711C9.45855 529.191 6.5 524.602 6.5 520C6.5 515.398 9.45855 510.809 15.3257 506.289C21.183 501.776 29.8528 497.401 41.0664 493.221C63.4878 484.864 95.9608 477.328 136.122 470.996C216.438 458.334 327.411 450.5 450 450.5Z"
-          stroke="currentColor"
-        />
-        <path
-          d="M450 450.5C567.875 450.5 674.57 466.166 751.779 491.48C790.386 504.138 821.593 519.2 843.138 535.901C864.689 552.607 876.5 570.893 876.5 590C876.5 609.107 864.689 627.393 843.138 644.099C821.593 660.8 790.386 675.862 751.779 688.52C674.57 713.834 567.875 729.5 450 729.5C332.125 729.5 225.43 713.834 148.221 688.52C109.614 675.862 78.4069 660.8 56.8621 644.099C35.3107 627.393 23.5 609.107 23.5 590C23.5 570.893 35.3107 552.607 56.8621 535.901C78.4069 519.2 109.614 504.138 148.221 491.48C225.43 466.166 332.125 450.5 450 450.5Z"
-          stroke="currentColor"
-        />
-        <path
-          d="M449.5 450.5C554.228 450.5 649.016 473.991 717.605 511.945C786.211 549.909 828.5 602.275 828.5 660C828.5 717.725 786.211 770.091 717.605 808.055C649.016 846.009 554.228 869.5 449.5 869.5C344.772 869.5 249.984 846.009 181.395 808.055C112.789 770.091 70.5 717.725 70.5 660C70.5 602.275 112.789 549.909 181.395 511.945C249.984 473.991 344.772 450.5 449.5 450.5Z"
-          stroke="currentColor"
-        />
-        <path
-          d="M450 449.5C572.589 449.5 683.562 441.666 763.878 429.004C804.039 422.672 836.512 415.136 858.934 406.779C870.147 402.599 878.817 398.224 884.674 393.711C890.541 389.191 893.5 384.602 893.5 380C893.5 375.398 890.541 370.809 884.674 366.289C878.817 361.776 870.147 357.401 858.934 353.221C836.512 344.864 804.039 337.328 763.878 330.996C683.562 318.334 572.589 310.5 450 310.5C327.411 310.5 216.438 318.334 136.122 330.996C95.9608 337.328 63.4878 344.864 41.0664 353.221C29.8528 357.401 21.183 361.776 15.3257 366.289C9.45855 370.809 6.5 375.398 6.5 380C6.5 384.602 9.45855 389.191 15.3257 393.711C21.183 398.224 29.8528 402.599 41.0664 406.779C63.4878 415.136 95.9608 422.672 136.122 429.004C216.438 441.666 327.411 449.5 450 449.5Z"
-          stroke="currentColor"
-        />
-        <path
-          d="M450 449.5C567.875 449.5 674.57 433.834 751.779 408.52C790.386 395.862 821.593 380.8 843.138 364.099C864.689 347.393 876.5 329.107 876.5 310C876.5 290.893 864.689 272.607 843.138 255.901C821.593 239.2 790.386 224.138 751.779 211.48C674.57 186.166 567.875 170.5 450 170.5C332.125 170.5 225.43 186.166 148.221 211.48C109.614 224.138 78.4069 239.2 56.8621 255.901C35.3107 272.607 23.5 290.893 23.5 310C23.5 329.107 35.3107 347.393 56.8621 364.099C78.4069 380.8 109.614 395.862 148.221 408.52C225.43 433.834 332.125 449.5 450 449.5Z"
-          stroke="currentColor"
-        />
-        <path
-          d="M449.5 449.5C554.228 449.5 649.016 426.009 717.605 388.055C786.211 350.091 828.5 297.725 828.5 240C828.5 182.275 786.211 129.909 717.605 91.9451C649.016 53.9908 554.228 30.5 449.5 30.5C344.772 30.5 249.984 53.9908 181.395 91.9451C112.789 129.909 70.5 182.275 70.5 240C70.5 297.725 112.789 350.091 181.395 388.055C249.984 426.009 344.772 449.5 449.5 449.5Z"
-          stroke="currentColor"
-        />
-      </g>
-
-      <path
-        d="M449.5 450C449.5 572.589 441.666 683.562 429.004 763.878C422.672 804.039 415.136 836.512 406.779 858.934C402.599 870.147 398.224 878.817 393.711 884.674C389.191 890.541 384.602 893.5 380 893.5C375.398 893.5 370.809 890.541 366.289 884.674C361.776 878.817 357.401 870.147 353.221 858.934C344.864 836.512 337.328 804.039 330.996 763.878C318.334 683.562 310.5 572.589 310.5 450C310.5 327.411 318.334 216.438 330.996 136.122C337.328 95.9608 344.864 63.4878 353.221 41.0664C357.401 29.8528 361.776 21.183 366.289 15.3257C370.809 9.45855 375.398 6.5 380 6.5C384.602 6.5 389.191 9.45855 393.711 15.3257C398.224 21.183 402.599 29.8528 406.779 41.0664C415.136 63.4878 422.672 95.9608 429.004 136.122C441.666 216.438 449.5 327.411 449.5 450Z"
-        stroke="currentColor"
-        className="animate-stroke"
-      />
-      <path
-        d="M449.5 450C449.5 567.875 433.834 674.57 408.52 751.779C395.862 790.386 380.8 821.593 364.099 843.138C347.393 864.689 329.107 876.5 310 876.5C290.893 876.5 272.607 864.689 255.901 843.138C239.2 821.593 224.138 790.386 211.48 751.779C186.166 674.57 170.5 567.875 170.5 450C170.5 332.125 186.166 225.43 211.48 148.221C224.138 109.614 239.2 78.4069 255.901 56.8621C272.607 35.3107 290.893 23.5 310 23.5C329.107 23.5 347.393 35.3107 364.099 56.8621C380.8 78.4069 395.862 109.614 408.52 148.221C433.834 225.43 449.5 332.125 449.5 450Z"
-        stroke="currentColor"
-        className="animate-stroke"
-      />
-      <path
-        d="M449.5 449.5C449.5 554.228 426.009 649.016 388.055 717.605C350.091 786.211 297.725 828.5 240 828.5C182.275 828.5 129.909 786.211 91.9451 717.605C53.9908 649.016 30.5 554.228 30.5 449.5C30.5 344.772 53.9908 249.984 91.9451 181.395C129.909 112.789 182.275 70.5 240 70.5C297.725 70.5 350.091 112.789 388.055 181.395C426.009 249.984 449.5 344.772 449.5 449.5Z"
-        stroke="currentColor"
-        className="animate-stroke"
-      />
-      <path
-        d="M450.5 450C450.5 572.589 458.334 683.562 470.996 763.878C477.328 804.039 484.864 836.512 493.221 858.934C497.401 870.147 501.776 878.817 506.289 884.674C510.809 890.541 515.398 893.5 520 893.5C524.602 893.5 529.191 890.541 533.711 884.674C538.224 878.817 542.599 870.147 546.779 858.934C555.136 836.512 562.672 804.039 569.004 763.878C581.666 683.562 589.5 572.589 589.5 450C589.5 327.411 581.666 216.438 569.004 136.122C562.672 95.9608 555.136 63.4878 546.779 41.0664C542.599 29.8528 538.224 21.183 533.711 15.3257C529.191 9.45855 524.602 6.5 520 6.5C515.398 6.5 510.809 9.45855 506.289 15.3257C501.776 21.183 497.401 29.8528 493.221 41.0664C484.864 63.4878 477.328 95.9608 470.996 136.122C458.334 216.438 450.5 327.411 450.5 450Z"
-        stroke="currentColor"
-        className="animate-stroke"
-      />
-      <path
-        d="M450.5 450C450.5 567.875 466.166 674.57 491.48 751.779C504.138 790.386 519.2 821.593 535.901 843.138C552.607 864.689 570.893 876.5 590 876.5C609.107 876.5 627.393 864.689 644.099 843.138C660.8 821.593 675.862 790.386 688.52 751.779C713.834 674.57 729.5 567.875 729.5 450C729.5 332.125 713.834 225.43 688.52 148.221C675.862 109.614 660.8 78.4069 644.099 56.8621C627.393 35.3107 609.107 23.5 590 23.5C570.893 23.5 552.607 35.3107 535.901 56.8621C519.2 78.4069 504.138 109.614 491.48 148.221C466.166 225.43 450.5 332.125 450.5 450Z"
-        stroke="currentColor"
-        className="animate-stroke"
-      />
-      <path
-        d="M450.5 449.5C450.5 554.228 473.991 649.016 511.945 717.605C549.909 786.211 602.275 828.5 660 828.5C717.725 828.5 770.091 786.211 808.055 717.605C846.009 649.016 869.5 554.228 869.5 449.5C869.5 344.772 846.009 249.984 808.055 181.395C770.091 112.789 717.725 70.5 660 70.5C602.275 70.5 549.909 112.789 511.945 181.395C473.991 249.984 450.5 344.772 450.5 449.5Z"
-        stroke="currentColor"
-        className="animate-stroke"
-      />
-      <path
-        d="M450 450.5C572.589 450.5 683.562 458.334 763.878 470.996C804.039 477.328 836.512 484.864 858.934 493.221C870.147 497.401 878.817 501.776 884.674 506.289C890.541 510.809 893.5 515.398 893.5 520C893.5 524.602 890.541 529.191 884.674 533.711C878.817 538.224 870.147 542.599 858.934 546.779C836.512 555.136 804.039 562.672 763.878 569.004C683.562 581.666 572.589 589.5 450 589.5C327.411 589.5 216.438 581.666 136.122 569.004C95.9608 562.672 63.4878 555.136 41.0664 546.779C29.8528 542.599 21.183 538.224 15.3257 533.711C9.45855 529.191 6.5 524.602 6.5 520C6.5 515.398 9.45855 510.809 15.3257 506.289C21.183 501.776 29.8528 497.401 41.0664 493.221C63.4878 484.864 95.9608 477.328 136.122 470.996C216.438 458.334 327.411 450.5 450 450.5Z"
-        stroke="currentColor"
-        className="animate-stroke"
-      />
-      <path
-        d="M450 450.5C567.875 450.5 674.57 466.166 751.779 491.48C790.386 504.138 821.593 519.2 843.138 535.901C864.689 552.607 876.5 570.893 876.5 590C876.5 609.107 864.689 627.393 843.138 644.099C821.593 660.8 790.386 675.862 751.779 688.52C674.57 713.834 567.875 729.5 450 729.5C332.125 729.5 225.43 713.834 148.221 688.52C109.614 675.862 78.4069 660.8 56.8621 644.099C35.3107 627.393 23.5 609.107 23.5 590C23.5 570.893 35.3107 552.607 56.8621 535.901C78.4069 519.2 109.614 504.138 148.221 491.48C225.43 466.166 332.125 450.5 450 450.5Z"
-        stroke="currentColor"
-        className="animate-stroke"
-      />
-      <path
-        d="M449.5 450.5C554.228 450.5 649.016 473.991 717.605 511.945C786.211 549.909 828.5 602.275 828.5 660C828.5 717.725 786.211 770.091 717.605 808.055C649.016 846.009 554.228 869.5 449.5 869.5C344.772 869.5 249.984 846.009 181.395 808.055C112.789 770.091 70.5 717.725 70.5 660C70.5 602.275 112.789 549.909 181.395 511.945C249.984 473.991 344.772 450.5 449.5 450.5Z"
-        stroke="currentColor"
-        className="animate-stroke"
-      />
-      <path
-        d="M450 449.5C572.589 449.5 683.562 441.666 763.878 429.004C804.039 422.672 836.512 415.136 858.934 406.779C870.147 402.599 878.817 398.224 884.674 393.711C890.541 389.191 893.5 384.602 893.5 380C893.5 375.398 890.541 370.809 884.674 366.289C878.817 361.776 870.147 357.401 858.934 353.221C836.512 344.864 804.039 337.328 763.878 330.996C683.562 318.334 572.589 310.5 450 310.5C327.411 310.5 216.438 318.334 136.122 330.996C95.9608 337.328 63.4878 344.864 41.0664 353.221C29.8528 357.401 21.183 361.776 15.3257 366.289C9.45855 370.809 6.5 375.398 6.5 380C6.5 384.602 9.45855 389.191 15.3257 393.711C21.183 398.224 29.8528 402.599 41.0664 406.779C63.4878 415.136 95.9608 422.672 136.122 429.004C216.438 441.666 327.411 449.5 450 449.5Z"
-        stroke="currentColor"
-        className="animate-stroke"
-      />
-      <path
-        d="M450 449.5C567.875 449.5 674.57 433.834 751.779 408.52C790.386 395.862 821.593 380.8 843.138 364.099C864.689 347.393 876.5 329.107 876.5 310C876.5 290.893 864.689 272.607 843.138 255.901C821.593 239.2 790.386 224.138 751.779 211.48C674.57 186.166 567.875 170.5 450 170.5C332.125 170.5 225.43 186.166 148.221 211.48C109.614 224.138 78.4069 239.2 56.8621 255.901C35.3107 272.607 23.5 290.893 23.5 310C23.5 329.107 35.3107 347.393 56.8621 364.099C78.4069 380.8 109.614 395.862 148.221 408.52C225.43 433.834 332.125 449.5 450 449.5Z"
-        stroke="currentColor"
-        className="animate-stroke"
-      />
-      <path
-        d="M449.5 449.5C554.228 449.5 649.016 426.009 717.605 388.055C786.211 350.091 828.5 297.725 828.5 240C828.5 182.275 786.211 129.909 717.605 91.9451C649.016 53.9908 554.228 30.5 449.5 30.5C344.772 30.5 249.984 53.9908 181.395 91.9451C112.789 129.909 70.5 182.275 70.5 240C70.5 297.725 112.789 350.091 181.395 388.055C249.984 426.009 344.772 449.5 449.5 449.5Z"
-        stroke="currentColor"
-        className="animate-stroke"
-      />
-      <defs>
-        <linearGradient
-          id="paint0_linear_26_28"
-          x1="450"
-          y1="0"
-          x2="450"
-          y2="900"
-          gradientUnits="userSpaceOnUse"
-        >
-          <stop stopColor="rgba(255,255,255,0)" />
-          <stop offset="0.5" stopColor="rgba(200,200,255,0.2)" />
-          <stop offset="1" stopColor="rgba(255,255,255,0)" />
-        </linearGradient>
-      </defs>
-    </svg>
-  );
-}
diff --git a/app/(home)/layout.tsx b/app/(home)/layout.tsx
deleted file mode 100644
index a15489ac..00000000
--- a/app/(home)/layout.tsx
+++ /dev/null
@@ -1,15 +0,0 @@
-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/(home)/page.tsx b/app/(home)/page.tsx
deleted file mode 100644
index b16ca8c4..00000000
--- a/app/(home)/page.tsx
+++ /dev/null
@@ -1,70 +0,0 @@
-import COURSES from '@/content/courses';
-import Link from 'next/link';
-
-export default function HomePage(): React.ReactElement {
-  return (
-    <>
-      <main className="container relative">
-        <Hero />
-        <Courses title="Explore our Courses" description="We offer fundamental courses specifically designed for individuals who are new to the Avalanche ecosystem, and advanced courses for those who wish to master the art of configuring, modifying, or even creating entirely new Virtual Machines from scratch." courses={COURSES.official_featured} />
-
-        {COURSES.ecosystem.length > 0 && <Courses title="Ecosystem Courses" description="Check out the courses provided by our ecosystem partners." courses={COURSES.ecosystem} />}
-
-      </main>
-    </>
-  );
-}
-
-function Hero(): React.ReactElement {
-
-  return (
-<>  </>
-  );
-}
-
-
-function Courses(props: { title: string, description: string, courses: any[] }): React.ReactElement {
-  return (
-    <div className="py-12 sm:py-24">
-      <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">{props.title}</h2>
-          <p className="mt-12 text-center text-lg leading-8 text-muted-foreground">
-            {props.description}
-          </p>
-        </div>
-        <Link href="/course/blockchain-fundamentals" className="block max-w-xl p-4 mx-auto mt-8 text-sm rounded-lg bg-muted border border-b " role="alert">
-          <span className="font-medium">Are you new to Blockchain?</span> Start with out Blockchain Fundamentals course <span className='underline'>here</span>.
-        </Link>
-        <div className="mx-auto mt-2 grid max-w-2xl grid-cols-1 gap-x-8 gap-y-16 border-gray-200 pt-7 sm:mt-12 sm:pt-0 lg:mx-0 lg:max-w-none lg:grid-cols-3">
-          {props.courses.map((course) => (
-            <Link href={`/course/${course.slug}`} key={course.slug} className="flex max-w-xl flex-col items-start space-y-2">
-              <img src={`/course-banner/${course.slug}.jpg`} alt="" className="w-full aspect-[3/2] object-cover rounded-lg mb-5" />
-              <div className="flex flex-wrap items-center gap-4 text-xs">
-                <span className="text-gray-500">
-                  {course.duration}
-                </span>
-                {[...course.tools, ...course.languages].map((item) => (
-                  <span key={item}
-                    className="relative z-10 rounded-full bg-accent px-3 py-1.5 font-medium text-muted-foreground"
-                  >
-                    {item}
-                  </span>
-                ))}
-
-              </div>
-              <div className="group">
-                <h3 className="mt-3 text-lg font-semibold leading-6 group-hover:text-gray-600">
-                  <span>
-                    {course.name}
-                  </span>
-                </h3>
-                <p className="mt-5 line-clamp-3 text-sm leading-6 text-muted-foreground">{course.description}</p>
-              </div>
-            </Link>
-          ))}
-        </div>
-      </div>
-    </div>
-  )
-}
\ No newline at end of file
diff --git a/app/[...path]/page.tsx b/app/[...path]/page.tsx
new file mode 100644
index 00000000..2e6091d0
--- /dev/null
+++ b/app/[...path]/page.tsx
@@ -0,0 +1,55 @@
+import { permanentRedirect } from 'next/navigation';
+import { Metadata } from 'next';
+
+type RedirectMap = {
+  [key: string]: string;
+};
+
+const staticRedirects: RedirectMap = {
+  '/course/subnet-architecture': '/academy/multi-chain-architecture',
+  '/course/teleporter': '/academy/interchain-messaging',
+  '/start': '/',
+};
+
+function getDestinationUrl(currentPath: string): string {
+  if (currentPath in staticRedirects) {
+    return `https://build.avax.network${staticRedirects[currentPath]}`;
+  }
+  
+  if (currentPath.startsWith('/course/')) {
+    const newPath = currentPath.replace('/course/', '/academy/');
+    return `https://build.avax.network${newPath}`;
+  }
+
+  const cleanPath = currentPath.startsWith('/') ? currentPath.slice(1) : currentPath;
+  return `https://build.avax.network/${cleanPath}`;
+}
+
+export async function generateMetadata({ 
+  params 
+}: { 
+  params: { path: string[] } 
+}): Promise<Metadata> {
+  const currentPath = `/${params.path.join('/')}`;
+  const destinationUrl = getDestinationUrl(currentPath);
+
+  return {
+    robots: {
+      index: false,
+      follow: true
+    },
+    alternates: {
+      canonical: destinationUrl
+    }
+  };
+}
+
+export default function CatchAllRoute({
+  params,
+}: {
+  params: { path: string[] };
+}) {
+  const currentPath = `/${params.path.join('/')}`;
+  const destinationUrl = getDestinationUrl(currentPath);
+  permanentRedirect(destinationUrl);
+}
diff --git a/app/api/generate-certificate/route.ts b/app/api/generate-certificate/route.ts
deleted file mode 100644
index 66916e68..00000000
--- a/app/api/generate-certificate/route.ts
+++ /dev/null
@@ -1,54 +0,0 @@
-import { NextRequest, NextResponse } from 'next/server';
-import { PDFDocument } from 'pdf-lib';
-
-const courseMapping: Record<string, string> = {
-  'avalanche-fundamentals': 'Avalanche Fundamentals',
-};
-
-function getCourseName(courseId: string): string {
-  return courseMapping[courseId] || courseId;
-}
-
-export async function POST(req: NextRequest) {
-  try {
-    const { courseId, userName } = await req.json();
-    if (!courseId || !userName) { return NextResponse.json({ error: 'Missing required fields' }, { status: 400 }); }
-    const courseName = getCourseName(courseId);
-    const protocol = req.headers.get('x-forwarded-proto') || 'http';
-    const host = req.headers.get('host') || 'localhost:3000';
-    const serverUrl = `${protocol}://${host}`;
-    const templateUrl = `${serverUrl}/certificates/AvalancheAcademy_Certificate.pdf`;
-    const templateResponse = await fetch(templateUrl);
-
-    if (!templateResponse.ok) { throw new Error(`Failed to fetch template`); }
-
-    const templateArrayBuffer = await templateResponse.arrayBuffer();
-    const pdfDoc = await PDFDocument.load(templateArrayBuffer);
-    const form = pdfDoc.getForm();
-
-    try {
-      // fills the form fields in our certificate template
-      form.getTextField('FullName').setText(userName);
-      form.getTextField('Class').setText(courseName);
-      form.getTextField('Awarded').setText(new Date().toLocaleDateString('en-US', { day: 'numeric', month: 'short', year: 'numeric' }));
-      form.getTextField('Id').setText(Math.random().toString(36).substring(2, 15) + Math.random().toString(36).substring(2, 15));
-    } catch (error) {
-      throw new Error('Failed to fill form fields');
-    }
-    
-    form.flatten();
-    const pdfBytes = await pdfDoc.save();
-    return new NextResponse(pdfBytes, {
-      status: 200,
-      headers: {
-        'Content-Type': 'application/pdf',
-        'Content-Disposition': `attachment; filename=${courseId}_certificate.pdf`,
-      },
-    });
-  } catch (error) {
-    return NextResponse.json(
-      { error: 'Failed to generate certificate, contact the Avalanche team.', details: (error as Error).message },
-      { status: 500 }
-    );
-  }
-}
\ No newline at end of file
diff --git a/app/api/og/course/[slug]/inter-bold.woff b/app/api/og/course/[slug]/inter-bold.woff
deleted file mode 100644
index eaf3d4bf..00000000
Binary files a/app/api/og/course/[slug]/inter-bold.woff and /dev/null differ
diff --git a/app/api/og/course/[slug]/route.tsx b/app/api/og/course/[slug]/route.tsx
deleted file mode 100644
index 0af9c3d1..00000000
--- a/app/api/og/course/[slug]/route.tsx
+++ /dev/null
@@ -1,106 +0,0 @@
-/* eslint-disable react/no-unknown-property -- Tailwind CSS `tw` property */
-import { ImageResponse } from 'next/og';
-import type { NextRequest } from 'next/server';
-import COURSES, { Course } from '@/content/courses';
-
-
-export const runtime = 'edge';
-
-const bold = fetch(new URL('./inter-bold.woff', import.meta.url)).then((res) =>
-  res.arrayBuffer(),
-);
-
-export async function GET(
-  request: NextRequest,
-  { params }: { params: { slug: string } },
-): Promise<ImageResponse> {
-  const { searchParams } = request.nextUrl;
-  const title = searchParams.get('title'),
-    description = searchParams.get('description');
-
-  return new ImageResponse(
-    OG({
-      title: title ?? 'Avalanche Academy',
-      description: description ?? 'The Learning Platform for Avalanche Ecosystem',
-      course: COURSES.official.find((course) => course.slug === params.slug) ?? COURSES.official[0],
-    }),
-    {
-      width: 767,
-      height: 414,
-      fonts: [{ name: 'Inter', data: await bold, weight: 700 }],
-    },
-  );
-}
-
-function OG({
-  title,
-  description,
-  course,
-}: {
-  title: string;
-  description: string;
-  course: Course;
-}): React.ReactElement {
-  const truncateText: React.CSSProperties = {
-    overflow: 'hidden',
-    textOverflow: 'ellipsis',
-    display: '-webkit-box',
-    WebkitBoxOrient: 'vertical',
-  };
-  
-  return (
-    <div
-      style={{
-        display: 'flex',
-        height: '100%',
-        width: '100%',
-        alignItems: 'center',
-        justifyContent: 'center',
-        letterSpacing: '-.02em',
-        fontWeight: 700,
-        backgroundColor: 'white',
-        backgroundImage: 'radial-gradient(circle at 25px 25px, lightgray 2%, transparent 0%), radial-gradient(circle at 75px 75px, lightgray 2%, transparent 0%)',
-        backgroundSize: '100px 100px',
-      }}
-    >
-      <div
-        style={{
-          left: 42,
-          top: 42,
-          position: 'absolute',
-          display: 'flex',
-          alignItems: 'center',
-        }}
-      >
-        <svg width="28" height="28" viewBox="0 0 1503 1504" fill="currentColor" xmlns="http://www.w3.org/2000/svg"><path d="M0 0 C2.55732537 0.00564458 5.11464409 0.00846231 7.67197418 0.0110817 C31.3592901 0.04635241 54.92104633 0.28871882 78.47373199 3.06482315 C80.7705047 3.33292967 83.06858053 3.58655283 85.36722565 3.83807755 C109.66314072 6.5211589 133.6968403 10.42576206 157.64310455 15.31805801 C158.37490936 15.46738785 159.10671417 15.61671768 159.86069489 15.77057266 C218.98163151 27.9141184 276.38459945 47.96549604 330.64310455 74.31805801 C331.81163971 74.88379532 332.98017487 75.44953262 334.18412018 76.03241348 C350.34077955 83.87648725 366.16576987 92.20338682 381.64310455 101.31805801 C382.57928619 101.86929337 383.51546783 102.42052872 384.48001862 102.98846817 C419.01024535 123.43880915 451.78167702 146.67417983 482.64310455 172.31805801 C483.51636383 173.04267227 483.51636383 173.04267227 484.40726471 173.7819252 C491.05401877 179.31241611 497.55453841 184.9708905 503.9126358 190.83368301 C506.07588096 192.80195757 508.26003215 194.73209803 510.4673233 196.65008926 C520.76353245 205.63556429 530.58846549 215.17615857 540.26810455 224.81805801 C540.90619049 225.45155167 541.54427643 226.08504532 542.2016983 226.73773575 C545.93239064 230.4807001 549.46089235 234.34619793 552.91507721 238.34491348 C555.69678407 241.52119985 558.61417067 244.56647173 561.51810455 247.63055801 C566.35163922 252.77040759 570.96873402 258.00101235 575.3735733 263.51727676 C577.54278581 266.19425674 579.77159736 268.80328033 582.02933502 271.40521622 C587.71712009 277.96040194 593.13468835 284.65803968 598.34818268 291.59784317 C599.70458566 293.39973145 601.07172479 295.19312503 602.43997955 296.98602676 C620.72843957 321.04142134 637.37835779 346.24599566 652.64310455 372.31805801 C653.3391983 373.49392471 653.3391983 373.49392471 654.04935455 374.6935463 C694.16011587 442.53365685 721.67382109 516.89619057 753.64310455 704.31805801 C753.70505508 705.38395157 753.70505508 705.38395157 753.76825714 706.47137833 C754.60910919 721.13103218 754.84518159 735.76101499 754.83060455 750.44305801 C754.83000031 751.57801712 754.82939606 752.71297623 754.8287735 753.88232803 C754.80070878 773.42461409 754.31192905 792.84529499 752.64310455 812.31805801 C752.57994049 813.05852371 752.51677643 813.79898941 752.4516983 814.56189346 C745.36375757 896.48363489 725.924643 978.10392554 684.17240143 1070.14764786 C682.63026007 1073.34468611 681.12486713 1076.55687428 679.62747955 1079.77508926 C673.38510235 1093.11885836 666.51855489 1105.96211078 659.13773346 1118.70770645 C657.34049597 1121.8465603 655.61350385 1125.01993289 653.89090729 1128.20013809 C627.39808864 1176.93491942 592.02614237 1222.19908964 554.20413971 1262.64374161 C552.57651377 1264.38948116 550.95878421 1266.14400991 549.3423233 1267.90008926 C543.10355175 1274.65972301 536.76021547 1281.30086048 530.26810455 1287.81805801 C529.62647369 1288.46428116 528.98484283 1289.1105043 528.32376862 1289.77630997 C524.55590553 1293.53201552 520.66891858 1297.08651347 516.64310455 1300.5631752 C513.28296844 1303.51149776 510.06855382 1306.61203489 506.83060455 1309.69305801 C501.48947737 1314.7370097 496.07660821 1319.58238497 490.3266983 1324.16180801 C487.88203872 1326.12607597 485.4953918 1328.14567454 483.11917877 1330.19183731 C475.57189222 1336.67918929 467.7201772 1342.72658201 459.7720108 1348.71258926 C457.74488376 1350.24130342 455.72450018 1351.77849777 453.70560455 1353.31805801 C417.69931756 1380.68283613 378.93590702 1403.86809322 338.64310455 1424.31805801 C337.50244537 1424.89716934 336.36178619 1425.47628067 335.18656158 1426.07294083 C261.44954122 1463.32931488 180.64727685 1486.6449528 87.64310455 1498.56805801 C86.35960114 1498.71920059 85.07609772 1498.87034317 83.75370026 1499.02606583 C79.38693792 1499.5076081 75.01910823 1499.93072472 70.64310455 1500.31805801 C69.17692688 1500.44886261 69.17692688 1500.44886261 67.68112946 1500.58230972 C47.2058317 1502.34569631 26.8242881 1502.6821709 6.28620911 1502.63611603 C3.72888374 1502.63047144 1.17156501 1502.62765372 -1.38576508 1502.62503433 C-25.073081 1502.58976362 -48.63483722 1502.3473972 -72.18752289 1499.57129288 C-74.4842956 1499.30318636 -76.78237143 1499.0495632 -79.08101654 1498.79803848 C-103.37693161 1496.11495713 -127.41063119 1492.21035396 -151.35689545 1487.31805801 C-152.08870026 1487.16872818 -152.82050507 1487.01939835 -153.57448578 1486.86554337 C-212.6954224 1474.72199763 -270.09839035 1454.67061999 -324.35689545 1428.31805801 C-325.5254306 1427.75232071 -326.69396576 1427.1865834 -327.89791107 1426.60370255 C-344.05457044 1418.75962878 -359.87956076 1410.43272921 -375.35689545 1401.31805801 C-376.29307709 1400.76682266 -377.22925873 1400.21558731 -378.19380951 1399.64764786 C-412.72403625 1379.19730688 -445.49546792 1355.96193619 -476.35689545 1330.31805801 C-476.9390683 1329.83498184 -477.52124115 1329.35190567 -478.1210556 1328.85419083 C-484.76780966 1323.32369991 -491.2683293 1317.66522553 -497.6264267 1311.80243301 C-499.78967185 1309.83415845 -501.97382304 1307.90401799 -504.1811142 1305.98602676 C-514.47732335 1297.00055174 -524.30225638 1287.45995746 -533.98189545 1277.81805801 C-534.93902435 1276.86781754 -534.93902435 1276.86781754 -535.9154892 1275.89838028 C-539.64618153 1272.15541593 -543.17468324 1268.28991809 -546.6288681 1264.29120255 C-549.41057497 1261.11491618 -552.32796156 1258.0696443 -555.23189545 1255.00555801 C-560.06543012 1249.86570843 -564.68252491 1244.63510368 -569.0873642 1239.11883926 C-571.2565767 1236.44185929 -573.48538825 1233.8328357 -575.74312592 1231.23089981 C-581.43091098 1224.67571409 -586.84847924 1217.97807634 -592.06197357 1211.03827286 C-593.41837656 1209.23638458 -594.78551568 1207.442991 -596.15377045 1205.65008926 C-614.44223047 1181.59469469 -631.09214868 1156.39012037 -646.35689545 1130.31805801 C-646.82095795 1129.53414688 -647.28502045 1128.75023575 -647.76314545 1127.94256973 C-687.87390677 1060.10245918 -715.38761199 985.73992546 -747.35689545 798.31805801 C-747.41884598 797.25216446 -747.41884598 797.25216446 -747.48204803 796.1647377 C-748.32290009 781.50508385 -748.55897248 766.87510104 -748.54439545 752.19305801 C-748.54348907 750.49061935 -748.54348907 750.49061935 -748.54256439 748.75378799 C-748.51449967 729.21150194 -748.02571995 709.79082104 -746.35689545 690.31805801 C-746.29373138 689.57759232 -746.23056732 688.83712662 -746.1654892 688.07422256 C-739.07754847 606.15248114 -719.63843389 524.53219049 -677.88619232 432.48846817 C-676.34405097 429.29142991 -674.83865803 426.07924174 -673.34127045 422.86102676 C-667.09889324 409.51725766 -660.23234579 396.67400525 -652.85152435 383.92840958 C-651.05428686 380.78955572 -649.32729474 377.61618313 -647.60469818 374.43597794 C-621.11086553 325.69933131 -585.73738598 280.43376548 -547.91353607 239.98797989 C-546.2987711 238.25570379 -544.69432782 236.51429499 -543.09127045 234.77118301 C-536.68354988 227.82356377 -530.15315301 221.01344706 -523.48189545 214.31805801 C-522.79264984 213.62422012 -522.10340424 212.93038223 -521.3932724 212.21551895 C-517.49039821 208.32438767 -513.48064546 204.62362414 -509.30806732 201.0241127 C-506.13737216 198.2517381 -503.10096114 195.33984314 -500.04439545 192.44305801 C-494.87759924 187.58452638 -489.62073164 182.93737868 -484.07564545 178.50946426 C-481.62055317 176.53057523 -479.22028094 174.49932881 -476.8307724 172.44208145 C-469.2835364 165.95622954 -461.43318029 159.9089407 -453.4858017 153.92352676 C-451.45867465 152.39481261 -449.43829108 150.85761826 -447.41939545 149.31805801 C-411.41310846 121.9532799 -372.64969791 98.7680228 -332.35689545 78.31805801 C-331.21623627 77.73894669 -330.07557709 77.15983536 -328.90035248 76.5631752 C-255.16333211 39.30680115 -174.36106775 15.99116322 -81.35689545 4.06805801 C-79.43164032 3.84134415 -79.43164032 3.84134415 -77.46749115 3.6100502 C-73.10072881 3.12850792 -68.73289912 2.70539131 -64.35689545 2.31805801 C-63.37944366 2.23085495 -62.40199188 2.14365189 -61.39492035 2.0538063 C-40.9196226 0.29041972 -20.53807899 -0.04605487 0 0 Z " fill="#E84142" transform="translate(748.3568954467773,0.6819419860839844)" /><path d="M0 0 C9.57967371 7.65251279 16.09243516 19.06001585 22 29.59765625 C22.97076777 31.30442209 23.94154282 33.01118381 24.91267395 34.71774292 C25.91888594 36.48895936 26.92132549 38.26226312 27.92285156 40.03613281 C30.8854856 45.27997714 33.88443718 50.50299939 36.87744141 55.72955322 C38.55347139 58.65819617 40.22601848 61.58882517 41.8984375 64.51953125 C42.23139832 65.10296295 42.56435913 65.68639465 42.90740967 66.2875061 C44.25432083 68.64775599 45.60109509 71.00808398 46.94787598 73.3684082 C49.29791657 77.4868721 51.6485209 81.6050135 54 85.72265625 C54.33152069 86.30319763 54.66304138 86.88373901 55.00460815 87.48187256 C59.79376544 95.86643156 64.6070903 104.23679468 69.4375 112.59765625 C76.29116175 124.46052518 83.09519017 136.35133428 89.88464355 148.25100708 C92.30303571 152.48874481 94.72669834 156.72344179 97.15234375 160.95703125 C111.28453595 185.6283462 111.28453595 185.6283462 117.85693359 197.63330078 C118.94185692 199.60557667 120.04247671 201.56850604 121.14453125 203.53125 C134.3278359 227.24675421 140.08023678 256.86051391 132.8984375 283.578125 C132.58132813 284.57457031 132.26421875 285.57101562 131.9375 286.59765625 C131.62039063 287.66628906 131.30328125 288.73492188 130.9765625 289.8359375 C124.77971652 308.88794269 113.86972281 326.32617576 103.9375 343.59765625 C101.95654421 347.05496678 99.97827372 350.51381054 98 353.97265625 C97.27127686 355.24484009 97.27127686 355.24484009 96.52783203 356.54272461 C92.01504971 364.43234355 87.58080922 372.3651695 83.14868164 380.30029297 C78.96972408 387.77467349 74.73737536 395.21659012 70.4765625 402.64453125 C66.58593006 409.437699 62.75490463 416.26311088 58.9375 423.09765625 C54.13863892 431.68826671 49.29649811 440.2519291 44.40405273 448.78955078 C39.08920272 458.06743601 33.83383643 467.37867998 28.57861328 476.69042969 C25.86700977 481.49402603 23.15209904 486.29575231 20.4375 491.09765625 C19.35415057 493.01431382 18.27081725 494.93098049 17.1875 496.84765625 C-5.5625 537.09765625 -5.5625 537.09765625 -28.3125 577.34765625 C-28.84883057 578.29656738 -29.38516113 579.24547852 -29.93774414 580.22314453 C-31.0201993 582.13821998 -32.10271875 584.05325909 -33.18530273 585.96826172 C-35.90760255 590.78397693 -38.62875348 595.60033468 -41.34765625 600.41796875 C-46.54075009 609.61698689 -51.74771144 618.80729072 -57 627.97265625 C-61.34177641 635.54927102 -65.62051312 643.15922277 -69.875 650.78515625 C-76.5540578 662.74401757 -83.35780845 674.62761627 -90.24414062 686.46826172 C-91.44103346 688.528113 -92.63512118 690.5895972 -93.82617188 692.65283203 C-100.39739411 704.03312978 -107.0395479 715.17356974 -115.0625 725.59765625 C-115.61679687 726.33628906 -116.17109375 727.07492187 -116.7421875 727.8359375 C-131.24199733 745.83445766 -155.75846169 757.96882462 -178.0625 761.59765625 C-178.94684754 761.75948993 -179.83119509 761.9213236 -180.74234104 762.08806133 C-191.79439704 763.92571679 -202.70915382 763.88719248 -213.88452148 763.87231445 C-216.0592669 763.87666942 -218.23401079 763.88185516 -220.40875244 763.88780212 C-226.27859555 763.90111756 -232.14837399 763.90177925 -238.01822925 763.89923882 C-242.93350233 763.89816424 -247.84876258 763.90306478 -252.7640329 763.90784425 C-264.36621737 763.91891319 -275.96836945 763.91939127 -287.57055664 763.91333008 C-299.50846674 763.9072891 -311.44625901 763.91961055 -323.38414901 763.94090015 C-333.66484303 763.95855489 -343.94549967 763.96451149 -354.22620827 763.9612624 C-360.35276217 763.95945592 -366.47923196 763.96202232 -372.60577202 763.97597694 C-378.36873325 763.98861419 -384.13151157 763.98655565 -389.89447021 763.97356606 C-391.99901964 763.97121371 -394.10358217 763.97388633 -396.20811653 763.98218918 C-430.15757588 764.10638341 -430.15757588 764.10638341 -442.30859375 752.44140625 C-448.49627886 745.44761904 -451.93084891 736.95398803 -452.5625 727.59765625 C-451.03997373 707.00125923 -435.81249137 686.88411582 -425.74316406 669.50439453 C-422.53912356 663.9629497 -419.36420035 658.40480138 -416.1875 652.84765625 C-415.84887939 652.25569458 -415.51025879 651.66373291 -415.16137695 651.05383301 C-409.74165486 641.57737482 -404.3891309 632.064786 -399.06640625 622.53344727 C-393.46768837 612.51489871 -387.77182157 602.55345485 -382.0625 592.59765625 C-379.43572086 588.01533979 -376.81041488 583.43218541 -374.1875 578.84765625 C-373.84869812 578.25551331 -373.50989624 577.66337036 -373.16082764 577.05328369 C-367.74345658 567.58069523 -362.39245313 558.07241756 -357.07299805 548.54443359 C-352.93321365 541.13502938 -348.74202558 533.75671211 -344.52148438 526.39306641 C-340.92770875 520.12057494 -337.3639296 513.83170979 -333.8125 507.53515625 C-329.28478377 499.50868801 -324.72497048 491.50110522 -320.14526367 483.50421143 C-314.65400157 473.91552696 -309.19990809 464.30775859 -303.8125 454.66015625 C-297.63463944 443.5973552 -291.36585281 432.58931443 -285.0625 421.59765625 C-282.43572086 417.01533979 -279.81041488 412.43218541 -277.1875 407.84765625 C-276.84869812 407.25551331 -276.50989624 406.66337036 -276.16082764 406.05328369 C-270.74133517 396.57698582 -265.38900692 387.06456399 -260.06640625 377.53344727 C-254.46768837 367.51489871 -248.77182157 357.55345485 -243.0625 347.59765625 C-240.43572086 343.01533979 -237.81041488 338.43218541 -235.1875 333.84765625 C-234.84869812 333.25551331 -234.50989624 332.66337036 -234.16082764 332.05328369 C-228.74345658 322.58069523 -223.39245313 313.07241756 -218.07299805 303.54443359 C-213.93321365 296.13502938 -209.74202558 288.75671211 -205.52148438 281.39306641 C-201.92770875 275.12057494 -198.3639296 268.83170979 -194.8125 262.53515625 C-190.28478377 254.50868801 -185.72497048 246.50110522 -181.14526367 238.50421143 C-175.65400157 228.91552696 -170.19990809 219.30775859 -164.8125 209.66015625 C-158.63463944 198.5973552 -152.36585281 187.58931443 -146.0625 176.59765625 C-143.43572086 172.01533979 -140.81041488 167.43218541 -138.1875 162.84765625 C-137.84869812 162.25551331 -137.50989624 161.66337036 -137.16082764 161.05328369 C-131.74133517 151.57698582 -126.38900692 142.06456399 -121.06640625 132.53344727 C-115.46768837 122.51489871 -109.77182157 112.55345485 -104.0625 102.59765625 C-101.4357208 98.01533968 -98.8105647 93.43209975 -96.1875 88.84765625 C-95.84803345 88.2545163 -95.50856689 87.66137634 -95.15881348 87.05026245 C-90.36847658 78.67683425 -85.63389529 70.27424408 -80.9375 61.84765625 C-46.67690615 0.4620628 -46.67690615 0.4620628 -31.26953125 -5.04296875 C-20.31867082 -6.8261177 -9.3223962 -6.33852317 0 0 Z " fill="#FEFEFE" transform="translate(773.0625,287.40234375)" /><path d="M0 0 C10.1444424 8.57903677 16.81475259 19.9618642 23.58203125 31.24609375 C24.32321606 32.47434874 25.06451063 33.70253749 25.8059082 34.93066406 C32.60475639 46.22129909 39.18222711 57.63773266 45.73291016 69.07373047 C48.59797705 74.06077913 51.49428767 79.02944211 54.39453125 83.99609375 C54.96067139 84.96579102 55.52681152 85.93548828 56.11010742 86.93457031 C61.46376222 96.09771483 66.83332607 105.25154169 72.20263672 114.40551758 C77.21855001 122.95801761 82.21870465 131.51958875 87.2109375 140.0859375 C91.80111111 147.95928769 96.40840309 155.82250712 101.01953125 163.68359375 C107.40216205 174.56524228 113.77016585 185.45527524 120.12109375 196.35546875 C122.42334249 200.30635609 124.73113742 204.2539313 127.04296875 208.19921875 C159.73982983 264.02839981 159.73982983 264.02839981 157.05859375 278.70703125 C154.19131834 289.4002819 148.89314961 297.24420371 139.51953125 303.18359375 C130.02899048 308.47639533 118.20887417 308.48379213 107.57913208 308.43756104 C106.45154759 308.44068102 105.32396311 308.443801 104.16220939 308.44701552 C100.42335167 308.45492597 96.68465941 308.44869912 92.94580078 308.44238281 C90.24903902 308.4450958 87.55228826 308.44858678 84.85552979 308.45300293 C78.31435279 308.46185729 71.7732219 308.45999249 65.23204316 308.45417765 C59.91068197 308.44964473 54.58933361 308.44905528 49.26797104 308.45122528 C48.1281098 308.45168498 48.1281098 308.45168498 46.96522107 308.45215397 C45.42103498 308.45279348 43.87684889 308.4534419 42.33266281 308.45409915 C27.88037539 308.45979105 13.42811342 308.45326288 -1.02416982 308.44249842 C-13.39714809 308.43356756 -25.77008881 308.43511332 -38.14306641 308.44433594 C-52.54363723 308.455065 -66.94418579 308.45923805 -81.34476006 308.45311141 C-82.88359904 308.45247438 -84.42243802 308.45184563 -85.96127701 308.45122528 C-86.71822592 308.45091673 -87.47517483 308.45060818 -88.25506159 308.45029028 C-93.56264374 308.44857096 -98.87021165 308.45146196 -104.1777916 308.45618439 C-110.65670636 308.46182277 -117.13557273 308.46021527 -123.61448203 308.4496229 C-126.91359616 308.4444051 -130.21261427 308.44333835 -133.51173019 308.4489212 C-173.42644255 308.51020937 -173.42644255 308.51020937 -185.16796875 298.24609375 C-192.59310903 290.07843944 -196.31528206 280.75390817 -196.01953125 269.73046875 C-194.73735881 261.29414576 -191.69973188 254.02511874 -187.66796875 246.55859375 C-186.95217651 245.21341675 -186.95217651 245.21341675 -186.22192383 243.84106445 C-180.83642466 233.82042666 -175.06683817 224.02357184 -169.27880859 214.23193359 C-166.32636433 209.22728804 -163.4047795 204.20471146 -160.48046875 199.18359375 C-159.31267209 197.18088922 -158.14470329 195.17828507 -156.9765625 193.17578125 C-156.1100708 191.69029785 -156.1100708 191.69029785 -155.22607422 190.17480469 C-153.49035285 187.20053081 -151.7531795 184.22710953 -150.015625 181.25390625 C-144.01269816 170.97826818 -138.03859087 160.68720812 -132.10546875 150.37109375 C-126.96384527 141.43489201 -121.75067413 132.54453762 -116.48046875 123.68359375 C-108.69199612 110.58621307 -101.06855836 97.39781826 -93.48046875 84.18359375 C-83.87367925 67.45391873 -74.18383229 50.78053992 -64.29052734 34.21875 C-62.63380902 31.44071895 -60.98791977 28.65656081 -59.34375 25.87109375 C-43.49211467 -0.80308423 -43.49211467 -0.80308423 -30.16796875 -4.44921875 C-19.93225133 -5.8477034 -8.61212062 -6.30651353 0 0 Z " fill="#FEFEFE" transform="translate(1030.48046875,742.81640625)" /></svg>
-        <span
-          style={{
-            marginLeft: 8,
-            fontSize: 20,
-          }}
-        >
-          Academy / {course.name}
-        </span>
-      </div>
-      <div
-        style={{
-          display: 'flex',
-          flexDirection: 'column',
-          padding: '20px 50px',
-          margin: '0 42px',
-          fontSize: 20,
-          width: 'auto',
-          maxWidth: 560,
-          backgroundColor: 'black',
-          color: '#737373',
-          lineHeight: 1.4,
-          overflow: 'hidden',
-        }}
-      >
-        <span style={{ ...truncateText, WebkitLineClamp: 2, margin: '0 0 20px 0', color: '#fff', fontSize: 26, }}>{title}</span>
-        <span style={{ ...truncateText, WebkitLineClamp: 3}}>{description}</span>
-        <br />
-      </div>
-    </div>
-  );
-}
\ No newline at end of file
diff --git a/app/api/og/guide/[slug]/inter-bold.woff b/app/api/og/guide/[slug]/inter-bold.woff
deleted file mode 100644
index eaf3d4bf..00000000
Binary files a/app/api/og/guide/[slug]/inter-bold.woff and /dev/null differ
diff --git a/app/api/og/guide/[slug]/route.tsx b/app/api/og/guide/[slug]/route.tsx
deleted file mode 100644
index 940d6ae2..00000000
--- a/app/api/og/guide/[slug]/route.tsx
+++ /dev/null
@@ -1,100 +0,0 @@
-/* eslint-disable react/no-unknown-property -- Tailwind CSS `tw` property */
-import { ImageResponse } from 'next/og';
-import type { NextRequest } from 'next/server';
-
-export const runtime = 'edge';
-
-const bold = fetch(new URL('./inter-bold.woff', import.meta.url)).then((res) =>
-  res.arrayBuffer(),
-);
-
-export async function GET(
-  request: NextRequest,
-): Promise<ImageResponse> {
-  const { searchParams } = request.nextUrl;
-  const title = searchParams.get('title'),
-    description = searchParams.get('description');
-
-  return new ImageResponse(
-    OG({
-      title: title ?? 'Avalanche Academy',
-      description: description ?? 'The Learning Platform for Avalanche Ecosystem'
-    }),
-    {
-      width: 767,
-      height: 414,
-      fonts: [{ name: 'Inter', data: await bold, weight: 700 }],
-    },
-  );
-}
-
-function OG({
-  title,
-  description
-}: {
-  title: string;
-  description: string;
-}): React.ReactElement {
-  const truncateText: React.CSSProperties = {
-    overflow: 'hidden',
-    textOverflow: 'ellipsis',
-    display: '-webkit-box',
-    WebkitBoxOrient: 'vertical',
-  };
-
-  return (
-    <div
-      style={{
-        display: 'flex',
-        height: '100%',
-        width: '100%',
-        alignItems: 'center',
-        justifyContent: 'center',
-        letterSpacing: '-.02em',
-        fontWeight: 700,
-        backgroundColor: 'white',
-        backgroundImage: 'radial-gradient(circle at 25px 25px, lightgray 2%, transparent 0%), radial-gradient(circle at 75px 75px, lightgray 2%, transparent 0%)',
-        backgroundSize: '100px 100px',
-      }}
-    >
-      <div
-        style={{
-          left: 42,
-          top: 42,
-          position: 'absolute',
-          display: 'flex',
-          alignItems: 'center',
-        }}
-      >
-        <svg width="28" height="28" viewBox="0 0 1503 1504" fill="currentColor" xmlns="http://www.w3.org/2000/svg"><path d="M0 0 C2.55732537 0.00564458 5.11464409 0.00846231 7.67197418 0.0110817 C31.3592901 0.04635241 54.92104633 0.28871882 78.47373199 3.06482315 C80.7705047 3.33292967 83.06858053 3.58655283 85.36722565 3.83807755 C109.66314072 6.5211589 133.6968403 10.42576206 157.64310455 15.31805801 C158.37490936 15.46738785 159.10671417 15.61671768 159.86069489 15.77057266 C218.98163151 27.9141184 276.38459945 47.96549604 330.64310455 74.31805801 C331.81163971 74.88379532 332.98017487 75.44953262 334.18412018 76.03241348 C350.34077955 83.87648725 366.16576987 92.20338682 381.64310455 101.31805801 C382.57928619 101.86929337 383.51546783 102.42052872 384.48001862 102.98846817 C419.01024535 123.43880915 451.78167702 146.67417983 482.64310455 172.31805801 C483.51636383 173.04267227 483.51636383 173.04267227 484.40726471 173.7819252 C491.05401877 179.31241611 497.55453841 184.9708905 503.9126358 190.83368301 C506.07588096 192.80195757 508.26003215 194.73209803 510.4673233 196.65008926 C520.76353245 205.63556429 530.58846549 215.17615857 540.26810455 224.81805801 C540.90619049 225.45155167 541.54427643 226.08504532 542.2016983 226.73773575 C545.93239064 230.4807001 549.46089235 234.34619793 552.91507721 238.34491348 C555.69678407 241.52119985 558.61417067 244.56647173 561.51810455 247.63055801 C566.35163922 252.77040759 570.96873402 258.00101235 575.3735733 263.51727676 C577.54278581 266.19425674 579.77159736 268.80328033 582.02933502 271.40521622 C587.71712009 277.96040194 593.13468835 284.65803968 598.34818268 291.59784317 C599.70458566 293.39973145 601.07172479 295.19312503 602.43997955 296.98602676 C620.72843957 321.04142134 637.37835779 346.24599566 652.64310455 372.31805801 C653.3391983 373.49392471 653.3391983 373.49392471 654.04935455 374.6935463 C694.16011587 442.53365685 721.67382109 516.89619057 753.64310455 704.31805801 C753.70505508 705.38395157 753.70505508 705.38395157 753.76825714 706.47137833 C754.60910919 721.13103218 754.84518159 735.76101499 754.83060455 750.44305801 C754.83000031 751.57801712 754.82939606 752.71297623 754.8287735 753.88232803 C754.80070878 773.42461409 754.31192905 792.84529499 752.64310455 812.31805801 C752.57994049 813.05852371 752.51677643 813.79898941 752.4516983 814.56189346 C745.36375757 896.48363489 725.924643 978.10392554 684.17240143 1070.14764786 C682.63026007 1073.34468611 681.12486713 1076.55687428 679.62747955 1079.77508926 C673.38510235 1093.11885836 666.51855489 1105.96211078 659.13773346 1118.70770645 C657.34049597 1121.8465603 655.61350385 1125.01993289 653.89090729 1128.20013809 C627.39808864 1176.93491942 592.02614237 1222.19908964 554.20413971 1262.64374161 C552.57651377 1264.38948116 550.95878421 1266.14400991 549.3423233 1267.90008926 C543.10355175 1274.65972301 536.76021547 1281.30086048 530.26810455 1287.81805801 C529.62647369 1288.46428116 528.98484283 1289.1105043 528.32376862 1289.77630997 C524.55590553 1293.53201552 520.66891858 1297.08651347 516.64310455 1300.5631752 C513.28296844 1303.51149776 510.06855382 1306.61203489 506.83060455 1309.69305801 C501.48947737 1314.7370097 496.07660821 1319.58238497 490.3266983 1324.16180801 C487.88203872 1326.12607597 485.4953918 1328.14567454 483.11917877 1330.19183731 C475.57189222 1336.67918929 467.7201772 1342.72658201 459.7720108 1348.71258926 C457.74488376 1350.24130342 455.72450018 1351.77849777 453.70560455 1353.31805801 C417.69931756 1380.68283613 378.93590702 1403.86809322 338.64310455 1424.31805801 C337.50244537 1424.89716934 336.36178619 1425.47628067 335.18656158 1426.07294083 C261.44954122 1463.32931488 180.64727685 1486.6449528 87.64310455 1498.56805801 C86.35960114 1498.71920059 85.07609772 1498.87034317 83.75370026 1499.02606583 C79.38693792 1499.5076081 75.01910823 1499.93072472 70.64310455 1500.31805801 C69.17692688 1500.44886261 69.17692688 1500.44886261 67.68112946 1500.58230972 C47.2058317 1502.34569631 26.8242881 1502.6821709 6.28620911 1502.63611603 C3.72888374 1502.63047144 1.17156501 1502.62765372 -1.38576508 1502.62503433 C-25.073081 1502.58976362 -48.63483722 1502.3473972 -72.18752289 1499.57129288 C-74.4842956 1499.30318636 -76.78237143 1499.0495632 -79.08101654 1498.79803848 C-103.37693161 1496.11495713 -127.41063119 1492.21035396 -151.35689545 1487.31805801 C-152.08870026 1487.16872818 -152.82050507 1487.01939835 -153.57448578 1486.86554337 C-212.6954224 1474.72199763 -270.09839035 1454.67061999 -324.35689545 1428.31805801 C-325.5254306 1427.75232071 -326.69396576 1427.1865834 -327.89791107 1426.60370255 C-344.05457044 1418.75962878 -359.87956076 1410.43272921 -375.35689545 1401.31805801 C-376.29307709 1400.76682266 -377.22925873 1400.21558731 -378.19380951 1399.64764786 C-412.72403625 1379.19730688 -445.49546792 1355.96193619 -476.35689545 1330.31805801 C-476.9390683 1329.83498184 -477.52124115 1329.35190567 -478.1210556 1328.85419083 C-484.76780966 1323.32369991 -491.2683293 1317.66522553 -497.6264267 1311.80243301 C-499.78967185 1309.83415845 -501.97382304 1307.90401799 -504.1811142 1305.98602676 C-514.47732335 1297.00055174 -524.30225638 1287.45995746 -533.98189545 1277.81805801 C-534.93902435 1276.86781754 -534.93902435 1276.86781754 -535.9154892 1275.89838028 C-539.64618153 1272.15541593 -543.17468324 1268.28991809 -546.6288681 1264.29120255 C-549.41057497 1261.11491618 -552.32796156 1258.0696443 -555.23189545 1255.00555801 C-560.06543012 1249.86570843 -564.68252491 1244.63510368 -569.0873642 1239.11883926 C-571.2565767 1236.44185929 -573.48538825 1233.8328357 -575.74312592 1231.23089981 C-581.43091098 1224.67571409 -586.84847924 1217.97807634 -592.06197357 1211.03827286 C-593.41837656 1209.23638458 -594.78551568 1207.442991 -596.15377045 1205.65008926 C-614.44223047 1181.59469469 -631.09214868 1156.39012037 -646.35689545 1130.31805801 C-646.82095795 1129.53414688 -647.28502045 1128.75023575 -647.76314545 1127.94256973 C-687.87390677 1060.10245918 -715.38761199 985.73992546 -747.35689545 798.31805801 C-747.41884598 797.25216446 -747.41884598 797.25216446 -747.48204803 796.1647377 C-748.32290009 781.50508385 -748.55897248 766.87510104 -748.54439545 752.19305801 C-748.54348907 750.49061935 -748.54348907 750.49061935 -748.54256439 748.75378799 C-748.51449967 729.21150194 -748.02571995 709.79082104 -746.35689545 690.31805801 C-746.29373138 689.57759232 -746.23056732 688.83712662 -746.1654892 688.07422256 C-739.07754847 606.15248114 -719.63843389 524.53219049 -677.88619232 432.48846817 C-676.34405097 429.29142991 -674.83865803 426.07924174 -673.34127045 422.86102676 C-667.09889324 409.51725766 -660.23234579 396.67400525 -652.85152435 383.92840958 C-651.05428686 380.78955572 -649.32729474 377.61618313 -647.60469818 374.43597794 C-621.11086553 325.69933131 -585.73738598 280.43376548 -547.91353607 239.98797989 C-546.2987711 238.25570379 -544.69432782 236.51429499 -543.09127045 234.77118301 C-536.68354988 227.82356377 -530.15315301 221.01344706 -523.48189545 214.31805801 C-522.79264984 213.62422012 -522.10340424 212.93038223 -521.3932724 212.21551895 C-517.49039821 208.32438767 -513.48064546 204.62362414 -509.30806732 201.0241127 C-506.13737216 198.2517381 -503.10096114 195.33984314 -500.04439545 192.44305801 C-494.87759924 187.58452638 -489.62073164 182.93737868 -484.07564545 178.50946426 C-481.62055317 176.53057523 -479.22028094 174.49932881 -476.8307724 172.44208145 C-469.2835364 165.95622954 -461.43318029 159.9089407 -453.4858017 153.92352676 C-451.45867465 152.39481261 -449.43829108 150.85761826 -447.41939545 149.31805801 C-411.41310846 121.9532799 -372.64969791 98.7680228 -332.35689545 78.31805801 C-331.21623627 77.73894669 -330.07557709 77.15983536 -328.90035248 76.5631752 C-255.16333211 39.30680115 -174.36106775 15.99116322 -81.35689545 4.06805801 C-79.43164032 3.84134415 -79.43164032 3.84134415 -77.46749115 3.6100502 C-73.10072881 3.12850792 -68.73289912 2.70539131 -64.35689545 2.31805801 C-63.37944366 2.23085495 -62.40199188 2.14365189 -61.39492035 2.0538063 C-40.9196226 0.29041972 -20.53807899 -0.04605487 0 0 Z " fill="#E84142" transform="translate(748.3568954467773,0.6819419860839844)" /><path d="M0 0 C9.57967371 7.65251279 16.09243516 19.06001585 22 29.59765625 C22.97076777 31.30442209 23.94154282 33.01118381 24.91267395 34.71774292 C25.91888594 36.48895936 26.92132549 38.26226312 27.92285156 40.03613281 C30.8854856 45.27997714 33.88443718 50.50299939 36.87744141 55.72955322 C38.55347139 58.65819617 40.22601848 61.58882517 41.8984375 64.51953125 C42.23139832 65.10296295 42.56435913 65.68639465 42.90740967 66.2875061 C44.25432083 68.64775599 45.60109509 71.00808398 46.94787598 73.3684082 C49.29791657 77.4868721 51.6485209 81.6050135 54 85.72265625 C54.33152069 86.30319763 54.66304138 86.88373901 55.00460815 87.48187256 C59.79376544 95.86643156 64.6070903 104.23679468 69.4375 112.59765625 C76.29116175 124.46052518 83.09519017 136.35133428 89.88464355 148.25100708 C92.30303571 152.48874481 94.72669834 156.72344179 97.15234375 160.95703125 C111.28453595 185.6283462 111.28453595 185.6283462 117.85693359 197.63330078 C118.94185692 199.60557667 120.04247671 201.56850604 121.14453125 203.53125 C134.3278359 227.24675421 140.08023678 256.86051391 132.8984375 283.578125 C132.58132813 284.57457031 132.26421875 285.57101562 131.9375 286.59765625 C131.62039063 287.66628906 131.30328125 288.73492188 130.9765625 289.8359375 C124.77971652 308.88794269 113.86972281 326.32617576 103.9375 343.59765625 C101.95654421 347.05496678 99.97827372 350.51381054 98 353.97265625 C97.27127686 355.24484009 97.27127686 355.24484009 96.52783203 356.54272461 C92.01504971 364.43234355 87.58080922 372.3651695 83.14868164 380.30029297 C78.96972408 387.77467349 74.73737536 395.21659012 70.4765625 402.64453125 C66.58593006 409.437699 62.75490463 416.26311088 58.9375 423.09765625 C54.13863892 431.68826671 49.29649811 440.2519291 44.40405273 448.78955078 C39.08920272 458.06743601 33.83383643 467.37867998 28.57861328 476.69042969 C25.86700977 481.49402603 23.15209904 486.29575231 20.4375 491.09765625 C19.35415057 493.01431382 18.27081725 494.93098049 17.1875 496.84765625 C-5.5625 537.09765625 -5.5625 537.09765625 -28.3125 577.34765625 C-28.84883057 578.29656738 -29.38516113 579.24547852 -29.93774414 580.22314453 C-31.0201993 582.13821998 -32.10271875 584.05325909 -33.18530273 585.96826172 C-35.90760255 590.78397693 -38.62875348 595.60033468 -41.34765625 600.41796875 C-46.54075009 609.61698689 -51.74771144 618.80729072 -57 627.97265625 C-61.34177641 635.54927102 -65.62051312 643.15922277 -69.875 650.78515625 C-76.5540578 662.74401757 -83.35780845 674.62761627 -90.24414062 686.46826172 C-91.44103346 688.528113 -92.63512118 690.5895972 -93.82617188 692.65283203 C-100.39739411 704.03312978 -107.0395479 715.17356974 -115.0625 725.59765625 C-115.61679687 726.33628906 -116.17109375 727.07492187 -116.7421875 727.8359375 C-131.24199733 745.83445766 -155.75846169 757.96882462 -178.0625 761.59765625 C-178.94684754 761.75948993 -179.83119509 761.9213236 -180.74234104 762.08806133 C-191.79439704 763.92571679 -202.70915382 763.88719248 -213.88452148 763.87231445 C-216.0592669 763.87666942 -218.23401079 763.88185516 -220.40875244 763.88780212 C-226.27859555 763.90111756 -232.14837399 763.90177925 -238.01822925 763.89923882 C-242.93350233 763.89816424 -247.84876258 763.90306478 -252.7640329 763.90784425 C-264.36621737 763.91891319 -275.96836945 763.91939127 -287.57055664 763.91333008 C-299.50846674 763.9072891 -311.44625901 763.91961055 -323.38414901 763.94090015 C-333.66484303 763.95855489 -343.94549967 763.96451149 -354.22620827 763.9612624 C-360.35276217 763.95945592 -366.47923196 763.96202232 -372.60577202 763.97597694 C-378.36873325 763.98861419 -384.13151157 763.98655565 -389.89447021 763.97356606 C-391.99901964 763.97121371 -394.10358217 763.97388633 -396.20811653 763.98218918 C-430.15757588 764.10638341 -430.15757588 764.10638341 -442.30859375 752.44140625 C-448.49627886 745.44761904 -451.93084891 736.95398803 -452.5625 727.59765625 C-451.03997373 707.00125923 -435.81249137 686.88411582 -425.74316406 669.50439453 C-422.53912356 663.9629497 -419.36420035 658.40480138 -416.1875 652.84765625 C-415.84887939 652.25569458 -415.51025879 651.66373291 -415.16137695 651.05383301 C-409.74165486 641.57737482 -404.3891309 632.064786 -399.06640625 622.53344727 C-393.46768837 612.51489871 -387.77182157 602.55345485 -382.0625 592.59765625 C-379.43572086 588.01533979 -376.81041488 583.43218541 -374.1875 578.84765625 C-373.84869812 578.25551331 -373.50989624 577.66337036 -373.16082764 577.05328369 C-367.74345658 567.58069523 -362.39245313 558.07241756 -357.07299805 548.54443359 C-352.93321365 541.13502938 -348.74202558 533.75671211 -344.52148438 526.39306641 C-340.92770875 520.12057494 -337.3639296 513.83170979 -333.8125 507.53515625 C-329.28478377 499.50868801 -324.72497048 491.50110522 -320.14526367 483.50421143 C-314.65400157 473.91552696 -309.19990809 464.30775859 -303.8125 454.66015625 C-297.63463944 443.5973552 -291.36585281 432.58931443 -285.0625 421.59765625 C-282.43572086 417.01533979 -279.81041488 412.43218541 -277.1875 407.84765625 C-276.84869812 407.25551331 -276.50989624 406.66337036 -276.16082764 406.05328369 C-270.74133517 396.57698582 -265.38900692 387.06456399 -260.06640625 377.53344727 C-254.46768837 367.51489871 -248.77182157 357.55345485 -243.0625 347.59765625 C-240.43572086 343.01533979 -237.81041488 338.43218541 -235.1875 333.84765625 C-234.84869812 333.25551331 -234.50989624 332.66337036 -234.16082764 332.05328369 C-228.74345658 322.58069523 -223.39245313 313.07241756 -218.07299805 303.54443359 C-213.93321365 296.13502938 -209.74202558 288.75671211 -205.52148438 281.39306641 C-201.92770875 275.12057494 -198.3639296 268.83170979 -194.8125 262.53515625 C-190.28478377 254.50868801 -185.72497048 246.50110522 -181.14526367 238.50421143 C-175.65400157 228.91552696 -170.19990809 219.30775859 -164.8125 209.66015625 C-158.63463944 198.5973552 -152.36585281 187.58931443 -146.0625 176.59765625 C-143.43572086 172.01533979 -140.81041488 167.43218541 -138.1875 162.84765625 C-137.84869812 162.25551331 -137.50989624 161.66337036 -137.16082764 161.05328369 C-131.74133517 151.57698582 -126.38900692 142.06456399 -121.06640625 132.53344727 C-115.46768837 122.51489871 -109.77182157 112.55345485 -104.0625 102.59765625 C-101.4357208 98.01533968 -98.8105647 93.43209975 -96.1875 88.84765625 C-95.84803345 88.2545163 -95.50856689 87.66137634 -95.15881348 87.05026245 C-90.36847658 78.67683425 -85.63389529 70.27424408 -80.9375 61.84765625 C-46.67690615 0.4620628 -46.67690615 0.4620628 -31.26953125 -5.04296875 C-20.31867082 -6.8261177 -9.3223962 -6.33852317 0 0 Z " fill="#FEFEFE" transform="translate(773.0625,287.40234375)" /><path d="M0 0 C10.1444424 8.57903677 16.81475259 19.9618642 23.58203125 31.24609375 C24.32321606 32.47434874 25.06451063 33.70253749 25.8059082 34.93066406 C32.60475639 46.22129909 39.18222711 57.63773266 45.73291016 69.07373047 C48.59797705 74.06077913 51.49428767 79.02944211 54.39453125 83.99609375 C54.96067139 84.96579102 55.52681152 85.93548828 56.11010742 86.93457031 C61.46376222 96.09771483 66.83332607 105.25154169 72.20263672 114.40551758 C77.21855001 122.95801761 82.21870465 131.51958875 87.2109375 140.0859375 C91.80111111 147.95928769 96.40840309 155.82250712 101.01953125 163.68359375 C107.40216205 174.56524228 113.77016585 185.45527524 120.12109375 196.35546875 C122.42334249 200.30635609 124.73113742 204.2539313 127.04296875 208.19921875 C159.73982983 264.02839981 159.73982983 264.02839981 157.05859375 278.70703125 C154.19131834 289.4002819 148.89314961 297.24420371 139.51953125 303.18359375 C130.02899048 308.47639533 118.20887417 308.48379213 107.57913208 308.43756104 C106.45154759 308.44068102 105.32396311 308.443801 104.16220939 308.44701552 C100.42335167 308.45492597 96.68465941 308.44869912 92.94580078 308.44238281 C90.24903902 308.4450958 87.55228826 308.44858678 84.85552979 308.45300293 C78.31435279 308.46185729 71.7732219 308.45999249 65.23204316 308.45417765 C59.91068197 308.44964473 54.58933361 308.44905528 49.26797104 308.45122528 C48.1281098 308.45168498 48.1281098 308.45168498 46.96522107 308.45215397 C45.42103498 308.45279348 43.87684889 308.4534419 42.33266281 308.45409915 C27.88037539 308.45979105 13.42811342 308.45326288 -1.02416982 308.44249842 C-13.39714809 308.43356756 -25.77008881 308.43511332 -38.14306641 308.44433594 C-52.54363723 308.455065 -66.94418579 308.45923805 -81.34476006 308.45311141 C-82.88359904 308.45247438 -84.42243802 308.45184563 -85.96127701 308.45122528 C-86.71822592 308.45091673 -87.47517483 308.45060818 -88.25506159 308.45029028 C-93.56264374 308.44857096 -98.87021165 308.45146196 -104.1777916 308.45618439 C-110.65670636 308.46182277 -117.13557273 308.46021527 -123.61448203 308.4496229 C-126.91359616 308.4444051 -130.21261427 308.44333835 -133.51173019 308.4489212 C-173.42644255 308.51020937 -173.42644255 308.51020937 -185.16796875 298.24609375 C-192.59310903 290.07843944 -196.31528206 280.75390817 -196.01953125 269.73046875 C-194.73735881 261.29414576 -191.69973188 254.02511874 -187.66796875 246.55859375 C-186.95217651 245.21341675 -186.95217651 245.21341675 -186.22192383 243.84106445 C-180.83642466 233.82042666 -175.06683817 224.02357184 -169.27880859 214.23193359 C-166.32636433 209.22728804 -163.4047795 204.20471146 -160.48046875 199.18359375 C-159.31267209 197.18088922 -158.14470329 195.17828507 -156.9765625 193.17578125 C-156.1100708 191.69029785 -156.1100708 191.69029785 -155.22607422 190.17480469 C-153.49035285 187.20053081 -151.7531795 184.22710953 -150.015625 181.25390625 C-144.01269816 170.97826818 -138.03859087 160.68720812 -132.10546875 150.37109375 C-126.96384527 141.43489201 -121.75067413 132.54453762 -116.48046875 123.68359375 C-108.69199612 110.58621307 -101.06855836 97.39781826 -93.48046875 84.18359375 C-83.87367925 67.45391873 -74.18383229 50.78053992 -64.29052734 34.21875 C-62.63380902 31.44071895 -60.98791977 28.65656081 -59.34375 25.87109375 C-43.49211467 -0.80308423 -43.49211467 -0.80308423 -30.16796875 -4.44921875 C-19.93225133 -5.8477034 -8.61212062 -6.30651353 0 0 Z " fill="#FEFEFE" transform="translate(1030.48046875,742.81640625)" /></svg>
-        <span
-          style={{
-            marginLeft: 8,
-            fontSize: 20,
-          }}
-        >
-          Academy / Guides
-        </span>
-      </div>
-      <div
-        style={{
-          display: 'flex',
-          flexDirection: 'column',
-          padding: '20px 50px',
-          margin: '0 42px',
-          fontSize: 20,
-          width: 'auto',
-          maxWidth: 560,
-          backgroundColor: 'black',
-          color: '#737373',
-          lineHeight: 1.4,
-          overflow: 'hidden',
-        }}
-      >
-        <span style={{ ...truncateText, WebkitLineClamp: 2, margin: '0 0 20px 0', color: '#fff', fontSize: 26, }}>{title}</span>
-        <span style={{ ...truncateText, WebkitLineClamp: 3}}>{description}</span>
-        <br />
-      </div>
-    </div>
-  );
-}
\ No newline at end of file
diff --git a/app/api/search/route.ts b/app/api/search/route.ts
deleted file mode 100644
index 6fc74aa6..00000000
--- a/app/api/search/route.ts
+++ /dev/null
@@ -1,20 +0,0 @@
-import { getCoursePages } from '@/utils/course-loader';
-import { getGuidePages } from '@/utils/guide-loader';
-import { createSearchAPI } from 'fumadocs-core/search/server';
-
-export const { GET } = createSearchAPI('advanced', {
-  indexes: [
-    ...getCoursePages().map((page) => ({
-      title: page.data.title,
-      structuredData: page.data.exports.structuredData,
-      id: page.url,
-      url: page.url,
-    })),
-    ...getGuidePages().map((page) => ({
-      title: page.data.title,
-      structuredData: page.data.exports.structuredData,
-      id: page.url,
-      url: page.url,
-    })),
-  ],
-});
diff --git a/app/contribute/layout.tsx b/app/contribute/layout.tsx
deleted file mode 100644
index a15489ac..00000000
--- a/app/contribute/layout.tsx
+++ /dev/null
@@ -1,15 +0,0 @@
-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/contribute/page.tsx b/app/contribute/page.tsx
deleted file mode 100644
index e67d7b04..00000000
--- a/app/contribute/page.tsx
+++ /dev/null
@@ -1,51 +0,0 @@
-import Link from 'next/link';
-import { buttonVariants } from '@/components/ui/button';
-
-export default function Page(): React.ReactElement {
-
-    return (
-        <main className="py-12 sm:py-24">
-            <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">Contribute to Avalanche Academy</h2>
-                    <p className="m-12 text-center text-lg leading-8 text-muted-foreground">
-                        The Avalanche Academy and Documentation is open to community contributions. You can help improve the content by fixing bugs, adding new content, or improving existing content.
-                    </p>
-                    <p className="m-12 text-center">
-                        <Link
-                            href="https://github.com/ava-labs/avalanche-academy"
-                            target='_blank'
-                            className={buttonVariants({ size: 'lg', variant: 'default' })}
-                        >
-                            Open on Github
-                        </Link>
-                    </p>
-                </div>
-                <div className="flex flex-col gap-5">
-                    <div
-                        className="flex flex-col gap-2 bg-card p-4 rounded-lg transition-shadow shadow hover:shadow-lg dark:bg-card-dark dark:border dark:border-slate-500"
-                    >
-                        <h3 className="text-xl">Fix Bugs</h3>
-
-                        <p className="text-sm text-muted-foreground">
-                            Every course chapter and guide page has a link to edit the source code on GitHub. If you find a bug, you can fix it and submit a pull request. The link is located in the left sidebar.
-                        </p>
-                    </div>
-
-                    <div
-                        className="flex flex-col gap-2 bg-card p-4 rounded-lg transition-shadow shadow hover:shadow-lg dark:bg-card-dark dark:border dark:border-slate-500"
-                    >
-                        <h3 className="text-xl">Add Content</h3>
-
-                        <p className="text-sm text-muted-foreground">
-                            You can add guides or course content to the Avalanche Academy by submitting a pull request. The content should be written in MarkdownX and should be placed in the <code>content</code> directory.
-                        </p>
-                        <p className="text-sm text-muted-foreground">
-                            If your content contains often reoccuring steps, such as starting the Avalanche Starter Kit or creating a blockchain with Avalanche CLI, please use the snippets in the <code>content/common</code> directory.
-                        </p>
-                    </div>
-                </div>
-            </div>
-        </main>
-    );
-}
\ No newline at end of file
diff --git a/app/course/[[...slug]]/page.tsx b/app/course/[[...slug]]/page.tsx
deleted file mode 100644
index 71736916..00000000
--- a/app/course/[[...slug]]/page.tsx
+++ /dev/null
@@ -1,167 +0,0 @@
-import { ArrowUpRightIcon, MessagesSquare } from 'lucide-react';
-import type { Metadata } from 'next';
-import { Card, Cards } from 'fumadocs-ui/components/card';
-import { DocsPage, DocsBody } from 'fumadocs-ui/page';
-import { notFound } from 'next/navigation';
-import { getCoursePage, getCoursePages, type Page } from '@/utils/course-loader';
-import { createMetadata } from '@/utils/metadata';
-import IndexedDBComponent from '@/components/tracker'
-import { Callout } from 'fumadocs-ui/components/callout';
-import Comments from '@/components/comments';
-import Instructors from '@/components/instructor';
-import Link from 'next/link';
-import { buttonVariants } from '@/components/ui/button';
-import { cn } from '@/utils/cn';
-import COURSES from '@/content/courses';
-
-interface Param {
-  slug: string[];
-}
-
-export const dynamicParams = false;
-
-function formatDate(date: Date) {
-  const formatter = new Intl.DateTimeFormat("en-GB", {
-    day: "numeric",
-    month: "long",
-    year: "numeric",
-  });
-  return formatter.format(date); // 1 January 2021
-}
-
-export default function Page({
-  params,
-}: {
-  params: Param;
-}): React.ReactElement {
-  const page = getCoursePage(params.slug);
-
-  if (!page) notFound();
-
-  const path = `content/course/${page.file.path}`;
-
-  // Adding Date Formatting on Right Sidebar
-  const updated = new Date(page.data.updated);
-  const [updatedISO, updatedHuman] = [updated.toISOString(), formatDate(updated)];
-
-  const course = COURSES.official.find(c => c.slug === page.slugs[0]);
-
-  return (
-    <DocsPage
-      toc={page.data.exports.toc}
-      lastUpdate={page.data.exports.lastModified}
-      tableOfContent={{
-        enabled: true,
-        footer: (
-          <div className="flex flex-col gap-6">
-            <div className='flex flex-col gap-y-4 text-sm text-muted-foreground'>
-              <div>Instructors:</div>
-              <Instructors names={course?.instructors || []} />
-            </div>
-
-            <Link href="https://t.me/avalancheacademy"
-              target='_blank'
-              className={cn(buttonVariants({ size: 'lg', variant: 'secondary' }))}
-            >
-              Join Telegram Course Chat
-            </Link>
-            
-            <div className="grid grid-cols-3 text-sm gap-y-4 text-muted-foreground">
-              <div>Updated:</div>
-              <time dateTime={updatedISO} title={updatedISO} className="col-span-2 text-foreground">
-                {updatedHuman}
-              </time>
-            </div>
-
-            <a
-            href={`https://github.com/ava-labs/avalanche-academy/blob/dev/${path}`}
-            target="_blank"
-            rel="noreferrer noopener"
-            className="inline-flex items-center gap-1 text-sm text-muted-foreground hover:text-foreground"
-            >
-              Edit on Github <ArrowUpRightIcon className="size-5" />
-            </a>
-          </div>
-
-        ),
-      }}
-    >
-      <h1 className="text-3xl font-bold text-foreground sm:text-4xl">
-        {page.data.title}
-      </h1>
-      <p className="mb-8 text-lg text-muted-foreground">
-        {page.data.description}
-      </p>
-      <DocsBody>
-        <IndexedDBComponent/>
-        {page.data.index ? (
-          <Category page={page} />
-        ) : (
-          <page.data.exports.default />
-        )}
-        {page.data.comments && (
-            <Callout title="" icon={<MessagesSquare stroke="#3752ac"/>}><Comments/></Callout>
-        )}
-      </DocsBody>
-    </DocsPage>
-  );
-}
-
-function Category({ page }: { page: Page }): React.ReactElement {
-  const filtered = getCoursePages()
-    .filter(
-      (item) =>
-        item.file.dirname === page.file.dirname && item.file.name !== 'index',
-    );
-
-  return (
-    <Cards>
-      {filtered.map((item) => (
-        <Card
-          key={item.url}
-          title={item.data.title}
-          description={item.data.description ?? 'No Description'}
-          href={item.url}
-        />
-      ))}
-    </Cards>
-  );
-}
-
-export function generateMetadata({ params }: { params: Param }): Metadata {
-  const page = getCoursePage(params.slug);
-
-  if (!page) notFound();
-
-  const description =
-    page.data.description ?? 'Learn how to build on Avalanche blockchain with Academy';
-
-  const imageParams = new URLSearchParams();
-  imageParams.set('title', page.data.title);
-  imageParams.set('description', description);
-
-  const image = {
-    alt: 'Banner',
-    url: `/api/og/course/${params.slug[0]}?${imageParams.toString()}`,
-    width: 1200,
-    height: 630,
-  };
-
-  return createMetadata({
-    title: page.data.title,
-    description,
-    openGraph: {
-      url: `/course/${page.slugs.join('/')}`,
-      images: image,
-    },
-    twitter: {
-      images: image,
-    },
-  });
-}
-
-export function generateStaticParams(): Param[] {
-  return getCoursePages().map<Param>((page) => ({
-    slug: page.slugs,
-  }));
-}
diff --git a/app/course/layout.tsx b/app/course/layout.tsx
deleted file mode 100644
index 07721c18..00000000
--- a/app/course/layout.tsx
+++ /dev/null
@@ -1,8 +0,0 @@
-import { DocsLayout } from 'fumadocs-ui/layout';
-import type { ReactNode } from 'react';
-import { docsOptions } from '../layout.config';
-
-export default function Layout({ children }: { children: ReactNode }) {
-  return <DocsLayout {...docsOptions}>{children}</DocsLayout>;
-}
-
diff --git a/app/guide/[slug]/page.tsx b/app/guide/[slug]/page.tsx
deleted file mode 100644
index 82f7000a..00000000
--- a/app/guide/[slug]/page.tsx
+++ /dev/null
@@ -1,153 +0,0 @@
-import type { Metadata } from 'next';
-import { notFound } from 'next/navigation';
-import Link from 'next/link';
-import { InlineTOC } from 'fumadocs-ui/components/inline-toc';
-import { getGuidePage, getGuidePages } from '@/utils/guide-loader';
-import { createMetadata } from '@/utils/metadata';
-import { buttonVariants } from '@/components/ui/button';
-import { ArrowUpRightIcon, MessagesSquare } from 'lucide-react';
-import { SiX } from '@icons-pack/react-simple-icons';
-import { Callout } from 'fumadocs-ui/components/callout';
-import Comments from '@/components/comments';
-
-interface Param {
-    slug: string;
-}
-
-export const dynamicParams = false;
-
-export default function Page({
-    params,
-}: {
-    params: Param;
-}): React.ReactElement {
-    const page = getGuidePage([params.slug]);
-
-    if (!page) notFound();
-
-    const path = `content/guide/${page.file.path}`;
-
-    return (
-        <>
-            <div
-                className="container rounded-xl border mt-5 py-12 md:px-8"
-                style={{
-                    backgroundColor: 'black',
-                    backgroundImage: [
-                        'linear-gradient(140deg, #3752AC 0%, transparent 50%)',
-                        'linear-gradient(to left top, #E84142 0%, transparent 50%)',
-                        'radial-gradient(circle at 100% 100%, #3752AC, #E84142 17%, transparent 20%)',
-                    ].join(', '),
-                    backgroundBlendMode: 'difference, difference, normal',
-                }}
-            >
-                <h1 className="mb-2 text-3xl font-bold text-white">
-                    {page.data.title}
-                </h1>
-                <p className="mb-4 text-white/80">{page.data.description}</p>
-                <Link
-                    href="/guide"
-                    className={buttonVariants({ size: 'sm', variant: 'secondary' })}
-                >
-                    Back
-                </Link>
-            </div>
-            <article className="container grid grid-cols-1 px-0 py-8 lg:grid-cols-[2fr_1fr] lg:px-4">
-                <div className="prose p-4">
-                    {page.data.exports.toc.length > 0 ? <InlineTOC items={page.data.exports.toc} /> : null} 
-                    <page.data.exports.default />
-                    {page.data.comments && (
-                        <Callout title="" icon={<MessagesSquare stroke="#3752ac"/>}><Comments/></Callout>
-                    )}
-                </div>
-                <div className="flex flex-col gap-4 border-l p-4 text-sm">
-                    <div>
-                        <p className="mb-1 text-muted-foreground">Written by</p>
-                        <div className="col-span-2 flex flex-col gap-2">
-                            {page.data.authors.map(author => (
-                                <Link
-                                    key={author}
-                                    href={`https://x.com/${author}`}
-                                    target='_blank'
-                                    className="text-foreground transition-colors flex flex-row items-center gap-2 group"
-                                >
-                                    <SiX size={12} />
-                                    <span className="flex-grow truncate">{author}</span>
-                                </Link>
-                            ))}
-                        </div>
-                    </div>
-                    <div>
-                        <p className="mb-1 text-sm text-muted-foreground">On</p>
-                        <p className="font-medium">
-                            {new Date(page.data.date ?? page.file.name).toDateString()}
-                        </p>
-                    </div>
-
-                    <div>
-                        <p className="mb-2 text-muted-foreground">Topics</p>
-                        <div className="flex flex-wrap items-center gap-4 text-xs">
-                            {page.data.topics.map(item => (
-                                <span key={item}
-                                    className="relative z-10 rounded-full bg-accent px-3 py-1.5 font-medium text-muted-foreground"
-                                >
-                                    {item}
-                                </span>
-                            ))}
-                        </div>
-                    </div>
-
-                    <a
-                        href={`https://github.com/ava-labs/avalanche-academy/blob/dev/${path}`}
-                        target="_blank"
-                        rel="noreferrer noopener"
-                        className="inline-flex items-center gap-1 text-sm text-muted-foreground hover:text-foreground"
-                    >
-                        <ArrowUpRightIcon className="size-5" /> Edit on Github 
-                    </a>
-
-                    {/*<Control url={page.url} />*/}
-                </div>
-            </article>
-        </>
-    );
-}
-
-export function generateMetadata({ params }: { params: Param }): Metadata {
-  const page = getGuidePage([params.slug]);
-
-  if (!page) notFound();
-
-  const description =
-    page.data.description ?? 'Learn how to build on Avalanche blockchain with Academy';
-
-  const imageParams = new URLSearchParams();
-  imageParams.set('title', page.data.title);
-  imageParams.set('description', description);
-
-  const image = {
-    alt: 'Banner',
-    url: `/api/og/guide/${params.slug[0]}?${imageParams.toString()}`,
-    width: 1200,
-    height: 630,
-  };
-
-  return createMetadata({
-    title: page.data.title,
-    description,
-    openGraph: {
-      url: `/docs/${page.slugs.join('/')}`,
-      images: image,
-    },
-    twitter: {
-      images: image,
-    },
-  });
-}
-
-
-export function generateStaticParams(): Param[] {
-    return getGuidePages().map<Param>((page) => ({
-        slug: page.slugs[0],
-    }));
-}
\ No newline at end of file
diff --git a/app/guide/layout.tsx b/app/guide/layout.tsx
deleted file mode 100644
index a15489ac..00000000
--- a/app/guide/layout.tsx
+++ /dev/null
@@ -1,15 +0,0 @@
-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/guide/page.tsx b/app/guide/page.tsx
deleted file mode 100644
index ab591a33..00000000
--- a/app/guide/page.tsx
+++ /dev/null
@@ -1,78 +0,0 @@
-import Link from 'next/link';
-import { getGuidePages } from '@/utils/guide-loader';
-import { buttonVariants } from '@/components/ui/button';
-import { SiX } from '@icons-pack/react-simple-icons';
-
-export default function Page(): React.ReactElement {
-    const guides = [...getGuidePages()].sort(
-        (a, b) =>
-            new Date(b.data.date ?? b.file.name).getTime() -
-            new Date(a.data.date ?? a.file.name).getTime(),
-    );
-
-    return (
-        <main className="py-12 sm:py-24">
-            <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">Guides</h2>
-                    <p className="m-12 text-center text-lg leading-8 text-muted-foreground">
-                        Check out our end-to-end guides on how to build on Avalanche.
-                    </p>
-                    <p className="m-12 text-center ">
-                        <Link
-                            href="https://github.com/ava-labs/avalanche-academy/tree/dev/content/guide"
-                            target='_blank'
-                            className={buttonVariants({ size: 'lg', variant: 'default' })}
-                        >
-                            Add a Guide
-                        </Link>
-                    </p>
-                </div>
-                <div className="flex flex-col gap-5">
-                    {guides.map((guide) => (
-                        <Link
-                            key={guide.url}
-                            href={guide.url}
-                            className="flex flex-col gap-2 bg-card p-4 rounded-lg transition-shadow shadow hover:shadow-lg dark:bg-card-dark dark:border dark:border-slate-500"
-                        >
-                            <p className="text-xs text-muted-foreground">
-                                {new Date(guide.data.date ?? guide.file.name).toDateString()}
-                            </p>
-
-                            <h3 className="text-xl">{guide.data.title}</h3>
-
-                            <p className="text-sm text-muted-foreground">
-                                {guide.data.description}
-                            </p>
-
-                            
-
-                            <div className="flex flex-wrap items-center gap-4 text-xs">
-                                {guide.data.topics.map(topic => (
-                                    <span key={topic}
-                                        className="relative z-10 rounded-full bg-accent px-3 py-1.5 font-medium text-muted-foreground"
-                                    >
-                                        {topic}
-                                    </span>
-                                ))}
-                            </div>
-
-                            <div className="col-span-2 flex gap-2">
-                                {guide.data.authors.map(author => (
-                                    <div
-                                        key={author}
-                                        className="text-sm text-muted-foreground transition-colors flex flex-row items-center gap-2 group"
-                                    >
-                                        <SiX size={12} />
-                                        <span className="flex-grow truncate">{author}</span>
-                                    </div>
-                                ))}
-                            </div>
-
-                        </Link>
-                    ))}
-                </div>
-            </div>
-        </main>
-    );
-}
\ No newline at end of file
diff --git a/app/hackathon/layout.tsx b/app/hackathon/layout.tsx
deleted file mode 100644
index a15489ac..00000000
--- a/app/hackathon/layout.tsx
+++ /dev/null
@@ -1,15 +0,0 @@
-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
deleted file mode 100644
index ba3704f8..00000000
--- a/app/hackathon/page.tsx
+++ /dev/null
@@ -1,383 +0,0 @@
-"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, Box, Mail } 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: 'nodes-network',
-      title: 'Nodes and Network',
-      description: "Develop solutions for staking management contracts, on-chain governance, membership platforms, and validator node group management.",
-      difficulty: 'Advanced',
-      color: 'border-red-500 text-red-700',
-      icon: <Box size={24} className="text-red-500" />,
-      examples: [
-        'Build staking management smart contracts for validator nodes.',
-        'Create on-chain governance frameworks to manage decentralized networks.',
-        'Develop platforms to manage memberships and validator node groups.'
-      ],
-      resources: [
-        { name: 'Avalanche Validator Guide', url: 'https://docs.avax.network/nodes' },
-        { name: 'Governance Models', url: 'https://github.com/ava-labs/icm-contracts/tree/main/contracts/governance' }
-      ]
-    },
-    {
-      id: 'virtual-machines',
-      title: 'Virtual Machines',
-      description: "Customize the execution layer of your blockchain by enhancing the EVM or creating dedicated virtual machines for specific functionalities, optimizing resource usage, and increasing TPS.",
-      difficulty: 'Advanced',
-      color: 'border-blue-500 text-blue-700',
-      icon: <SquareTerminal size={24} className="text-blue-500" />,
-      examples: [
-        'Add custom functionality to the EVM for specialized use cases.',
-        'Develop dedicated virtual machines for optimized transaction processing.',
-        'Utilize modular frameworks to modify transaction logic.'
-      ],
-      resources: [
-        { name: 'Customize the EVM:', url: 'https://academy.avax.network/course/customizing-evm' },
-        { name: 'Custom VM with HyperSDK:', url: 'https://github.com/ava-labs/hypersdk' }
-      ]
-    },
-    {
-        id: 'cross-chain-dapps',
-        title: 'Cross-Chain Decentralized Applications (dApps)',
-        description: "Develop cross-chain decentralized applications on your own customizable L1 that seamlessly interacts with multiple blockchain networks using ICM and ICTT.",
-        difficulty: 'Intermediate',
-        color: 'border-green-500 text-green-700',
-        icon: <Zap size={24} className="text-green-500" />,
-        examples: [
-          'Create DeFi, SocialFi, or Gaming dApps that operate across multiple Avalanche L1s and other blockchains.',
-          'Develop applications utilizing staking, governance, or NFTs with cross-chain functionality.',
-          'Integrate seamless user experiences with multi-network infrastructures.'
-        ],
-        resources: [
-          { name: 'InterChain Messaging', url: 'https://academy.avax.network/course/interchain-messaging' },
-          { name: 'InterChain Token Transfer', url: 'https://academy.avax.network/course/interchain-token-transfer' },
-          { name: 'Cross-Chain Communication', url: 'https://docs.avax.network/build/avalanchego/cross-chain' }
-        ]
-      },
-      {
-        id: 'tooling',
-        title: 'Developer Tooling',
-        description: "Leverage Avalanche's technology by creating developer tools that simplify building and deploying applications on Avalanche.",
-        difficulty: 'Intermediate',
-        color: 'border-purple-500 text-purple-700',
-        icon: <Code size={24} className="text-purple-500" />,
-        examples: [
-          'Develop SDKs or APIs to improve developer experience.',
-          'Build tools for smart contract deployment and testing.',
-          'Create dashboards for network monitoring and analytics.'
-        ],
-        resources: [
-          { name: 'Avalanche SDK', url: 'https://github.com/ava-labs/avalanchejs' },
-          { name: 'Developer Tools', url: 'https://docs.avax.network/tools' }
-        ]
-      },
-      {
-        id: 'ai-agent',
-        title: 'AI Agents',
-        description: "Leverage Avalanche's technology by creating developer tools that simplify building and deploying applications on Avalanche.",
-        difficulty: 'Intermediate',
-        color: 'border-purple-500 text-purple-700',
-        icon: <Code size={24} className="text-purple-500" />,
-        examples: [
-          'Develop SDKs or APIs to improve developer experience.',
-          'Build tools for smart contract deployment and testing.',
-          'Create dashboards for network monitoring and analytics.'
-        ],
-        resources: [
-          { name: 'Avalanche SDK', url: 'https://github.com/ava-labs/avalanchejs' },
-        ]
-      },  
-  ];
-
-  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 London 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://lu.ma/avalanchesummitlondonhackathon" className={buttonVariants({ size: 'lg', variant: 'default' })}>
-              Register Here! →
-            </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. (Plus partner's prizes).
-              </p>
-              <div className="mb-6">
-                <p className="text-lg text-gray-600 dark:text-gray-400">
-                  Top participants may earn a spot in the{" "}
-                  <Link href="https://codebase.avax.network/" passHref>
-                    <strong className="text-yellow-500 hover:underline">
-                    Codebase Incubator Program
-                    </strong>
-                  </Link>, gaining access to exclusive resources and mentorship.
-                </p>
-              </div>
-            </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>
-          {/*
-          <p className="text-lg text-gray-600 dark:text-gray-400">
-              To be Announced...<strong>Stay Tuned!</strong>
-          </p>
-          */}
-          
-          <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-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">Partner Tracks</h2>
-            
-            <p className="text-lg text-gray-600 dark:text-gray-400">
-              Are you a project looking for developers to test your product and enhace the Avalanche Ecosystem?{" "}
-              <Link href="mailto:brittany.gilliam@avalabs.org" passHref>
-                <strong className="text-yellow-500 hover:underline">
-                Contact us
-                </strong>
-              </Link>, and become a partner
-            </p>
-        </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
deleted file mode 100644
index 994797d6..00000000
--- a/app/hackathon/partners.tsx
+++ /dev/null
@@ -1,235 +0,0 @@
-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_' }
-      ]
-    },
-    {
-      id: 'gogopool',
-      name: 'GoGoPool',
-      prize: '1000 GGP Tokens',
-      description: "Explore the frontier of AI and blockchain integration with GoGoPool's challenge. Build a decentralized L1 blockchain purpose-built for AI agents using GoGoPool.",
-      tracks: [
-        {
-          name: 'Decentralized L1 for AI Agents',
-          bounty: '1,000 GGP [1st place: 500 GGP, 2nd place: 300 GGP, 3rd place: 200 GGP]',
-          description: "Your challenge is to build a decentralized L1 purpose-built for AI agents, showcasing how these agents can transact seamlessly onchain while also delivering an intuitive, visually appealing interface for users and developers alike."
-        }
-      ],
-      eligibilityRequirements: [
-        'Must use the GoGoPool L1 Launcher to create their Fuji L1',
-        'Must demonstrate swarms of agents transacting with each other onchain ',
-        'Must write a ~1 page thesis document on why a L1 was requisit for their idea to work',
-        'If you can go beyond these requirements with something surprising or exceptional, you might just blow us away!'
-      ],
-      resources: [
-        { name: 'Etna Devnet Resources', url: 'https://github.com/ava-labs/etna-devnet-resources' },
-        { name: 'GGP L1 Launcher', url: 'https://www.gogopool.com/launcher' }
-      ]
-    }
-  ];
-
-  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.client.tsx b/app/layout.client.tsx
deleted file mode 100644
index 590dee68..00000000
--- a/app/layout.client.tsx
+++ /dev/null
@@ -1,76 +0,0 @@
-'use client';
-import type { ReactNode } from 'react';
-
-export function Title(): React.ReactElement {
-
-  const svgCode = `<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
-	 width="100%" viewBox="0 0 220 190" enable-background="new 0 0 220 190" xml:space="preserve">
-<path fill="#010000" opacity="0" stroke="none" 
-	d="
-M106.000000,191.000000 
-	C70.687920,191.000000 35.875835,191.000000 1.031875,191.000000 
-	C1.031875,127.726570 1.031875,64.453117 1.031875,1.089830 
-	C74.228607,1.089830 147.457367,1.089830 220.843063,1.089830 
-	C220.843063,64.333038 220.843063,127.666473 220.843063,191.000000 
-	C182.786728,191.000000 144.643356,191.000000 106.000000,191.000000 
-M108.753487,23.066143 
-	C106.781303,24.703455 104.299789,26.001934 102.939713,28.046438 
-	C99.810646,32.750118 97.235901,37.821735 94.420807,42.735210 
-	C71.899803,82.043488 49.344860,121.332367 26.880989,160.673264 
-	C23.042721,167.395203 25.895014,172.155457 33.583733,172.183975 
-	C48.081749,172.237732 62.580860,172.111847 77.077980,172.237946 
-	C83.770172,172.296158 88.432472,169.499405 91.727638,163.708237 
-	C107.212326,136.494400 122.784348,109.330147 138.378067,82.178566 
-	C141.392197,76.930382 141.523560,71.750351 138.545532,66.532860 
-	C131.114777,53.514198 123.769547,40.442513 116.039948,27.602837 
-	C114.786873,25.521351 111.741776,24.518684 108.753487,23.066143 
-M189.977249,151.515366 
-	C182.832336,139.327515 175.755188,127.099236 168.514145,114.968781 
-	C164.857819,108.843597 159.019684,108.509308 155.552734,114.306282 
-	C146.170135,129.994598 136.920776,145.764069 127.775551,161.592056 
-	C124.725456,166.870987 127.530586,172.066513 133.547867,172.121841 
-	C152.337845,172.294647 171.131317,172.293900 189.921402,172.129471 
-	C196.006195,172.076218 198.644424,167.142075 195.809311,161.653442 
-	C194.133530,158.409164 192.156281,155.320618 189.977249,151.515366 
-z"/>
-<path fill="#FD3648" opacity="1.000000" stroke="none" 
-	d="
-M109.139252,23.041748 
-	C111.741776,24.518684 114.786873,25.521351 116.039948,27.602837 
-	C123.769547,40.442513 131.114777,53.514198 138.545532,66.532860 
-	C141.523560,71.750351 141.392197,76.930382 138.378067,82.178566 
-	C122.784348,109.330147 107.212326,136.494400 91.727638,163.708237 
-	C88.432472,169.499405 83.770172,172.296158 77.077980,172.237946 
-	C62.580860,172.111847 48.081749,172.237732 33.583733,172.183975 
-	C25.895014,172.155457 23.042721,167.395203 26.880989,160.673264 
-	C49.344860,121.332367 71.899803,82.043488 94.420807,42.735210 
-	C97.235901,37.821735 99.810646,32.750118 102.939713,28.046438 
-	C104.299789,26.001934 106.781303,24.703455 109.139252,23.041748 
-z"/>
-<path fill="#FC3648" opacity="1.000000" stroke="none" 
-	d="
-M190.145935,151.838699 
-	C192.156281,155.320618 194.133530,158.409164 195.809311,161.653442 
-	C198.644424,167.142075 196.006195,172.076218 189.921402,172.129471 
-	C171.131317,172.293900 152.337845,172.294647 133.547867,172.121841 
-	C127.530586,172.066513 124.725456,166.870987 127.775551,161.592056 
-	C136.920776,145.764069 146.170135,129.994598 155.552734,114.306282 
-	C159.019684,108.509308 164.857819,108.843597 168.514145,114.968781 
-	C175.755188,127.099236 182.832336,139.327515 190.145935,151.838699 
-z"/>
-</svg>`
-  return (
-    <>
-      <img width="80" height="80" src={`data:image/svg+xml;utf8,${encodeURIComponent(svgCode)}`} className="size-7" alt="logo" />
-      <span style={{fontSize: "larger"}}>Academy</span>
-    </>
-  );
-}
-
-export function Body({
-  children,
-}: {
-  children: ReactNode;
-}): React.ReactElement {
-  return <div>{children}</div>;
-}
diff --git a/app/layout.config.tsx b/app/layout.config.tsx
deleted file mode 100644
index 6577b336..00000000
--- a/app/layout.config.tsx
+++ /dev/null
@@ -1,57 +0,0 @@
-import { type BaseLayoutProps, type DocsLayoutProps } from 'fumadocs-ui/layout';
-import { coursePageTree } from '@/utils/course-loader';
-import { RootToggle } from 'fumadocs-ui/components/layout/root-toggle';
-import { Title } from '@/app/layout.client';
-import { MailIcon, SquareStackIcon, ArrowLeftRight, SquareIcon, SquareCode, Triangle } from 'lucide-react';
-import COURSES from '@/content/courses';
-
-export const baseOptions: BaseLayoutProps = {
-  githubUrl: 'https://github.com/ava-labs/avalanche-academy',
-  nav: {
-    title: <Title />,
-  },
-  links: [
-    {
-      text: 'Courses',
-      url: '/',
-    },
-    {
-      text: 'Guides',
-      url: '/guide',
-    },
-    {
-      text: 'Documentation',
-      url: 'https://docs.avax.network',
-    },
-    {
-      text: 'Contribute',
-      url: '/contribute',
-    },
-    {
-      text: 'Hackathons',
-      url: '/hackathon',
-    },
-  ],
-};
-
-export const docsOptions: DocsLayoutProps = {
-  ...baseOptions,
-  tree: coursePageTree,
-  sidebar: {
-    defaultOpenLevel: 0,
-    banner: (
-      <RootToggle
-        options={
-          COURSES.official.map(c => {
-            return {
-              title: c.name,
-              description: '',
-              icon: c.icon,
-              url: `/course/${c.slug}`
-            }
-          })
-        }
-      />
-    ),
-  }
-};
diff --git a/app/layout.tsx b/app/layout.tsx
index 54f7faca..0696235b 100644
--- a/app/layout.tsx
+++ b/app/layout.tsx
@@ -1,45 +1,20 @@
-import './global.css';
-import { RootProvider } from 'fumadocs-ui/provider';
-import { PHProvider } from './providers'
-import type { Viewport } from 'next';
-import type { ReactNode } from 'react';
-import { GeistSans } from 'geist/font/sans';
-import { GeistMono } from 'geist/font/mono';
-import { baseUrl, createMetadata } from '@/utils/metadata';
-import { Analytics } from "@vercel/analytics/react";
-import { SpeedInsights } from "@vercel/speed-insights/next"
-import Chatbot from '@/components/chatbot';
+import type { Metadata } from 'next';
 
-export const metadata = createMetadata({
-  title: {
-    template: '%s | Avalanche Academy',
-    default: 'Avalanche Academy',
-  },
-
-  // area for improvement: add page specific metadata
-  description: 'The Learning Platform for the Avalanche Ecosystem',
-  metadataBase: baseUrl,
-});
-
-export const viewport: Viewport = {
-  themeColor: [
-    { media: '(prefers-color-scheme: dark)', color: '#0A0A0A' },
-    { media: '(prefers-color-scheme: light)', color: '#fff' },
-  ],
+export const metadata: Metadata = {
+  robots: {
+    index: false,
+    follow: true
+  }
 };
 
-export default function Layout({ children }: { children: ReactNode }) {
+export default function RootLayout({
+  children,
+}: {
+  children: React.ReactNode;
+}) {
   return (
-    <html lang="en" className={`${GeistSans.variable} ${GeistMono.variable}`} suppressHydrationWarning>
-      <PHProvider>
-        <body className="flex min-h-screen flex-col">
-          <RootProvider>{children}</RootProvider>
-          <Analytics/>
-          <SpeedInsights/>
-          {/* <Chatbot websiteId="9303deff-3c25-458d-b6ab-8a10c497b39d" projectName="AvaGPT" projectColor="#e84142" projectLogo="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAANEAAADQCAYAAACZZoRKAAAQHUlEQVR4nO2dPVBc1xXHrySMrQ9LJClWnZhBPaSWZqTZnYncmZjUARVxZqIGuZBKk6SyC3lTOEVSiE0d2aizMgOBmbg29GICnbZwImRJthVpyJzlPHjsfbv7Pu7Huff9fzMM6D1WLLA/zrnn3nvuif39fQXs0222ZpRSE0qp5P0kvyl+f6nkk9hSSj3ljzf5453krbG2uqM9AhgFEhmGZZlhMa5XFMQUWywVSbZO7xtrq0/dfOn4gUQV6DZbEyzKDL+/FtDT301Jtd5YW93UPgPkAhIVpNtskSyzLM10UE9+OHuJUJCqGJBoBBxtZlPiXBj+iGigSLXCQq3U5HsuBSTKoE+c9/XPqB17LNRyY211ve4/jH4gUQpO1RaUUvPaTZCQRKg2Kn8H1F4ijjqLLI/vKlpobHB0Wq7zD6G2EnEpehFRxwiU7rU5OtWudF47iThlWwqsHB0SHfr51inVq41E3WZrgSNPTGVpydRGpugl4sjThjzeiF6maCVC2iYOkmkxxjFTdBJ1m61JlgcFA3nscfFhKaZvKiqJus3WEo976rKqIFR2OSpFsRIiCok4dVvGPE9wPGSZgh4vBS0RT5QuY2lO0Oxx4aEd6jcRrETdZmuWBULqFge0+mEhxKgUnEQcfdooHERJkFEpKIl4qc4Kxj7R85CjUhDl8JPaFaFw5e0bCFQLaIy7wwUj8YiPRCge1J7b0tM70RIhfQOM6PRObDrHC0bXIRDgLGSdV6OIQ6REPP65j/I1SEELiDc5OxGFOIm6zRaNfz7WbgBw8Ef1G85SxCBmTMQFhBWsugY5uSllW7oIiVigdez5AQXpNNZWvUcl7+kcBAIVmOf03yteJYJAwADeRfImEQQCBvEqkheJIBCwgDeRnEsEgYBFvIjkVCIIBBzgXCTXkQgCARfMu5yQdSYR/3WAQMAV912J5EQiXguHnajANW0Xa+2sr1jgvwb3tRsAuIG2nM/Y7N1gVSL+K7CO1djAM3Tw83Vb+5GspXOpBaUQCPhmmpvbWMHmmAg7UoEkqGK3aOP5WJGICwnY0gCk8ZmNQoPxMRF3aPmndgMAGexyocHY+MhoJEqNgwCQyiXuHmUM0+kc2vqCEHif21AbwVg6x0/qS+1GQJw4d069dXlKjU8fpM1jl6d618ARrx9vq/3nz9Wb7hP15skT9WpzK9SfjrH5IyMScRq3E2IUGrt8WZ2+cUO9ffWKOtVoaPfBaF5tbakf//W1+vHrr3tiBcRGY221cpdVUxKthNShlKILiXPmV3MQxzAk0ssHD0KKUJUbnlSWKLQ07tz8fE+eE2fPaveAOSg6veh0QpCJ0rrJKtW6ShKFlMaNz0yr83fvIvI45uWDL9TzTqc3jhJMpa5BVatzSyEIRNHnJ/fuQSAPnJn7QP3sr3/pjT0FM1/lBIrSkYj7Iv9buyEIGvtM/PEPanwa25gk8OzTT9X3Xz2S+vS2GmurpVYzVIlEIrpPDoIE+uln9yCQIM7fuaNOv3dD6tObLruJr1Qkkr60JxFobGpKuwf8IzgilSoylI1EoqMQBJKN4IhE4/vCK70LS8QhT+wWB6rAQSD5kEhCiw2LXHXOTZlItKRdEQKtOjh94xdSnx7og4o+ApdVXSi6ga+QRJKjEP0yLty9q10HcqEpB5p+EMh8kVP5ikYisVHo3Vu3sAohQGgeiSbCBZL7tZ5bIslR6NTFi0jjAuaszGg0m3dsVCQSiY1CQn8JICc0lycwGuWu1OWSiOeFEIWANd658Z7EH26uSl3eSCS3InflinYNhAf9IRRaqRu5A3akRFylENu5R/AyElCQd66K/IM4MoDkiURWenWZgFI5TKzGg9Cs4tKoFd55JPJ+OvMghJZGQUnGZ6z3ni/LUAeGSsRlbbH7hcamRO9RAQWheT6hS4HmhxUYhkokOQop7sYTO6+3t3tbrel9HTh1UezGyYEuDJRIekGBeEv2bsnKUNOPb3/zofrv7Y9670mm2HlLbnZRXKI8pT3fxL7M57vP/3zs388++VT7HOCM6UHr6YZJNNA8YB9q8NHfw43+/f2jf0T90z958aJ2TRCZgSVTIjYOpS9P7L940euQkwW1oaL7sSJ4TKQGBZZMiQYZB9zw8u8PBraYomhE94EXMlO6QRJlGgfs86bbHRiFEug+fR7wghZgNIm4Ho5UzhMvRgiU8N3nn2vXgBNGS5T1ScANVMLO2wWHGsjXoeQtkGv9E69ZEg1dJwTskTcKJaDk7Y1jjmRJhEjkASpdF23+3isyPPhCuw6sM1giPhQWJ915oGgUSngeeclbKMcCTX8kQirngRedv2kTq3mhUjiKDM65lB4X9Uskdi16rFAUefGg2rwPFSNQ8nbOYcBBJPLM82UzZ/cgGjlHl4jDk9j2wDFC0eNlxSiUIPwQrRg5zNrSkQipnGOeffJJrb7fyDjcJpSWCKmcQ2iiNODj68FRNRuRyBf9e4WqMj6NX58HeotR0xJpq1OBHWhi9fXjx8b+b+pLQCeiA+dokQiLTh3QK2mXnFjN4uA0jDto5u+HI4mS3A7Yh/YClZ1YzeLs3Bx67/njWDo3sB0QMIeJidU01LwSaZxXetlbIhEqcw6gCVGT8zl0GgbSOL/QTtesVdzAAtQ3zuSJ2TgNQwyTiESOML0sB2cyiWECkcgBpidWEYVEMZNIhDkii5jegYooJIsxfjZYeGoJmlg1WdIuEoXoa//w6Kvex9T8/91bv9M+B1Rmcgw/Q3tQSdvXWCj52kk1kNLJt69e6Z2PCoyC6pxNhjVhLAMt78kbhbK+tsmVEuCIk6NOAQPloL1CJidWibzp2KAGkBSNYu/l7QNEIkv0emYbjEJ0KmDeVGzYPqVeiofGJiZBOmeDIk0Y85J3LDSqnE5io5e3US5BIguYHnsUi0Kjy+no5W0WSGQYOt1uWCQoQ94oVKT11rCUDxQDEhnG+I7VnFGoaCGDRCfhQXUgkUGyTrerSv4oVLyQYVr4ugKJDDHsdLuy5I1CZQsZJDylgKAakMgQppowpjl/9652LYsqEYVSQBQZqgGJDGCyCWPC6fduqFON0eeXUgpZpekJenlXBxIZwMaLMM9YyFQKiQPDKrELiSpCUYhehCY5MzeXKwrROMhUCokiQ2l2TjbWVtcDffIi+MHwygRqgXVuIV9FzmQKSSkh1tWVA5GoAqa79yhugZWn+YjpfUpEsvfIJyE25odEFaAX+ztXrxj7/6iYcHb+19r1LKj8TVHLJBJaEb9+vK1dE85OsilvF7tby3H+zh11qnFRvdraLP1/0G5VKiTkGQcdPqbRUOfm540VNWivUl6BwTEOJdqBROWhF99Z5f4FeGbuAzV2eUr9r+JavZOCGp+86ZpNUV2A7eGBQysaYtrybXqc54DNZEyECh0QQYBnNj1FYQGIIdAJ3x1EIiAG05PWLmisrR5K9BQvJeCbAPc39UJnT6LG2mr5+iwABqBULsCiAlW1j022YgUi8MYPj8wun3JEL/ikJdrBSwj4gBbxmu6O5AhNIqR0wAsB72fS0jlU6IBzaCwUYlVOpWoJiETAG7QK3vSxMw7ZSL7UoUSNtdWnvBAVACdQGhdgRS7hMOj0r1hASgecQPuhAi0mJBy60i8RUjpgHRIogg6sAyVCJAJWiUSgXR7+9DgmEVcb9rSHAGCASAQiVtL/yFrFvaJdAaAi1E0ooib6xzK2LImQ0gFjvN7eVt9++FvjzS09c8yRrJ2tFInua1cBKADNAdFhYqb7kwtgIz0eUlkS0Sd0my1ajIpjpkFhEnmolViI7a9yoA13NImYZaXUZ9pVADIgcV5tbqrvHz0KdglPAXJLtAKJQBbJFu43T7q9rqmvtx+H2BehLFu0k7X/sZkS0ScipcsPDZ7/c/ujWNMXcMRy1s8iqzqXkPkAcBwIVCu0VE6NkCjzAeAICFQrMlM5NUwifsCGdgP0gEC1Y2BmNlAiZuAD6wwEqiUDXRgqUWNtdRlr6Y4DgWpJp3+CNc1QiZiBBtYNCFRbhjqQR6K2dqWGQKDasjvqNMmREqHAAIFqztKobz9vQ/uR/1GsQKBas5dnqieXRBzOatfEBALVnvawgkJCkaNVahWNIFDt2ctbD8gtEZe7axGNIBCgNC5PFFIlTg+PPhpBIMDkfq0Xkij2aASBANMZtE4uizLHTUYZjSAQYGgstFjkh1FYohijEQQCKXJV5NKUPfh4QbsSKBAIpMhdkUtTSiKeNwp+FQMEAn0sFo1CqkIkUqFHIwgE+tjioUphSkvE1Ys/aTcCAAKBDAoVE9JUiUSKK3Xe9huRDGUeA4FAH51RK7WHUUkizh+9pXVFz7eBQCCDwiXtfqpGIhKJVrk+1G44gPo7541GEAgMoFQxIU1liZgFX2kdiZE0FBwE3YdAIIONssWENCf29/e1i2XoNluzSqkvff2m3r56RY1Pz6jxmWk1NjXVu0bRh6JV4McaAjvQH/2ZIst7BmFMInUgEqV272s3AJDHL3koUhlT6VyCt7QOgAI8NCWQMi0RD9BmtRsAyGHXdEXZdCRKlgT9XrsBgAxmq1bj+jEukToQaanuHYKASG7z4d5GsSIRM1vH5iZALLQqwUoPRWsSpcZHKDQA32xVXZUwDJuRSHHotPbkAcjBno1xUBqrEqmjnbAoNAAfkEDXTUyoDsO6ROqo0BDdWexAPIs2Cgn9GF2xMIpus7WJc2CBI26aWBeXByeRKMV1HuQBYJOOK4GUa4l4cAeRgE1IIKd73FxHIogEbOJcIOVDIgWRgB28CKR8SaQgEjCLN4GUT4kURAJm8CqQ8i2RgkigGt4FUhIkUsdFwspvkJebEgRSridb89Bttqi+Py/qSQFpOJtIzYOISJSG/7pgrR3IgtbC/VySQEqiROpord1NbKMAKba4O4/1tXBFEZfOpek2WzN8BPol7SaoE9QcdMHmdoYqiJZIHYg0oZRaRiuu2nLb1o5UU4iXKKHbbFGK97F2A8RKspmudKN5VwQjkUJ6VydEp2/9BCWROkrv2iiDRwlFnyXp6Vs/wUmUwL2/aax0QbsJQmSDo4/Vrdw2CFYihaJDLAQZfdIELVFCt9m6zjJhrBQWD7kPQnDRJ00UEiVwBW8RKZ54dlkeY03lfRKVROpApEk+SxaFB3lQ6tbmFSnREJ1ECZzi0S/rmnYT+KBj4mhHiUQrUQLL1EarLm90uHAQ9LhnGNFLlNBtthZ4vASZ3BC9PAm1kSgBaZ51aiNPQu0kSuAlRIsoQBhhj1PmdoxjnlHUVqIEnrBd5CMIMc9UDFplsCxtk5xrai9RGk71FhCdhrLLi4DbdUrZhgGJMuDoNMtvWFJ0kK6tcNQRvzXBNZBoBH1CXa/Raogk4qzHsrLAFpCoIJzyJULFVC6naLOevEnsZSAVSFQBjlIk0wy/D6lsTpFmE9JUBxIZhkvn9DbJYk0KqPpRp5ydlDSbdSxF2wISOYLlmmDBJliuSf7qVUQjQRIhNvnjneQNFTTLKKX+D7rIQEhQx22LAAAAAElFTkSuQmCC" /> */}
-          <Chatbot />
-        </body>
-      </PHProvider>
+    <html>
+      <body>{children}</body>
     </html>
   );
 }
diff --git a/app/page.tsx b/app/page.tsx
new file mode 100644
index 00000000..3f20a161
--- /dev/null
+++ b/app/page.tsx
@@ -0,0 +1,5 @@
+import { permanentRedirect } from 'next/navigation';
+
+export default function Home() {
+  permanentRedirect('https://build.avax.network/academy');
+}
diff --git a/app/providers.js b/app/providers.js
deleted file mode 100644
index 6bdb1ca1..00000000
--- a/app/providers.js
+++ /dev/null
@@ -1,14 +0,0 @@
-'use client'
-import posthog from 'posthog-js'
-import { PostHogProvider } from 'posthog-js/react'
-
-if (typeof window !== 'undefined') {
-  posthog.init(process.env.NEXT_PUBLIC_POSTHOG_KEY, {
-    api_host: process.env.NEXT_PUBLIC_POSTHOG_HOST,
-    persistence: 'memory' //enables cookieless tracking
-  })
-}
-
-export function PHProvider({ children }) {
-  return <PostHogProvider client={posthog}>{children}</PostHogProvider>
-}
diff --git a/components/certificates.tsx b/components/certificates.tsx
deleted file mode 100644
index dec27080..00000000
--- a/components/certificates.tsx
+++ /dev/null
@@ -1,246 +0,0 @@
-"use client";
-import React, { useState, useEffect } from 'react';
-import { getQuizResponse } from '@/utils/indexedDB';
-import { buttonVariants } from '@/components/ui/button';
-import { cn } from '@/utils/cn';
-import quizDataImport from '@/components/quizzes/quizData.json';
-import Quiz from '@/components/quizzes/quiz';
-import { Accordion, Accordions } from 'fumadocs-ui/components/accordion';
-import { Linkedin, Twitter, Award, Share2 } from 'lucide-react';
-
-interface CertificatePageProps {
-  courseId: string;
-}
-
-interface QuizInfo {
-  id: string;
-  chapter: string;
-  question: string;
-}
-
-interface QuizData {
-  question: string;
-  options: string[];
-  correctAnswers: number[];
-  hint: string;
-  explanation: string;
-  chapter: string;
-}
-
-interface Course {
-  title: string;
-  quizzes: string[];
-}
-
-interface QuizDataStructure {
-  courses: {
-    [courseId: string]: Course;
-  };
-  quizzes: {
-    [quizId: string]: QuizData;
-  };
-}
-
-const quizData = quizDataImport as QuizDataStructure;
-
-const CertificatePage: React.FC<CertificatePageProps> = ({ courseId }) => {
-  const [completedQuizzes, setCompletedQuizzes] = useState<string[]>([]);
-  const [isLoading, setIsLoading] = useState(true);
-  const [userName, setUserName] = useState('');
-  const [isGenerating, setIsGenerating] = useState(false);
-  const [quizzes, setQuizzes] = useState<QuizInfo[]>([]);
-
-  useEffect(() => {
-    const fetchQuizzes = () => {
-      const courseQuizzes = quizData.courses[courseId]?.quizzes || [];
-      const quizzesWithChapters = courseQuizzes.map(quizId => ({
-        id: quizId,
-        chapter: quizData.quizzes[quizId]?.chapter || 'Unknown Chapter',
-        question: quizData.quizzes[quizId]?.question || ''
-      }));
-      setQuizzes(quizzesWithChapters);
-    };
-
-    fetchQuizzes();
-  }, [courseId]);
-
-  useEffect(() => {
-    const checkQuizCompletion = async () => {
-      const completed = await Promise.all(
-        quizzes.map(async (quiz) => {
-          const response = await getQuizResponse(quiz.id);
-          return response && response.isCorrect ? quiz.id : null;
-        })
-      );
-      setCompletedQuizzes(completed.filter((id): id is string => id !== null));
-      setIsLoading(false);
-    };
-
-    if (quizzes.length > 0) {
-      checkQuizCompletion();
-    }
-  }, [quizzes]);
-
-  const allQuizzesCompleted = completedQuizzes.length === quizzes.length;
-
-  const generateCertificate = async () => {
-    if (!userName.trim()) {
-      alert('Please enter your name');
-      return;
-    }
-
-    setIsGenerating(true);
-    try {
-      const response = await fetch('/api/generate-certificate', {
-        method: 'POST',
-        headers: {
-          'Content-Type': 'application/json',
-        },
-        body: JSON.stringify({
-          courseId,
-          userName,
-        }),
-      });
-
-      if (!response.ok) {
-        throw new Error('Failed to generate certificate');
-      }
-
-      const blob = await response.blob();
-      const url = window.URL.createObjectURL(blob);
-      const a = document.createElement('a');
-      a.style.display = 'none';
-      a.href = url;
-      a.download = `${courseId}_certificate.pdf`;
-      document.body.appendChild(a);
-      a.click();
-      window.URL.revokeObjectURL(url);
-    } catch (error) {
-      console.error('Error generating certificate:', error);
-      alert('Failed to generate certificate. Please try again.');
-    } finally {
-      setIsGenerating(false);
-    }
-  };
-
-  const chapters = [...new Set(quizzes.map(quiz => quiz.chapter))];
-
-  const quizzesByChapter = chapters.reduce((acc, chapter) => {
-    acc[chapter] = quizzes.filter(quiz => quiz.chapter === chapter);
-    return acc;
-  }, {} as Record<string, QuizInfo[]>);
-
-  const shareOnLinkedIn = () => {
-    const organizationName = 'Avalanche';
-    const organizationId = 19104188;
-    const certificationName = encodeURIComponent(quizData.courses[courseId].title);
-    const issuedMonth = new Date().getMonth() + 1;
-    const issuedYear = new Date().getFullYear();
-
-    return `https://www.linkedin.com/profile/add?startTask=CERTIFICATION_NAME&name=${certificationName}&organizationId=${organizationId}&issueMonth=${issuedMonth}&issueYear=${issuedYear}&organizationName=${organizationName}`;
-  };
-
-  const shareOnTwitter = () => {
-    const text = `I just completed the ${quizData.courses[courseId].title} course on Avalanche Academy!`;
-    const url = `https://twitter.com/intent/tweet?text=${encodeURIComponent(text)}&url=${encodeURIComponent(window.location.href)}`;
-    window.open(url, '_blank');
-  };
-
-  if (isLoading) {
-    return <div>Loading...</div>;
-  }
-
-  return (
-    <div className="max-w-4xl mx-auto p-4">
-      {chapters.map((chapter) => {
-        const chapterQuizzes = quizzesByChapter[chapter];
-        const incompleteQuizzes = chapterQuizzes.filter(quiz => !completedQuizzes.includes(quiz.id));
-
-        if (incompleteQuizzes.length === 0) return null;
-
-        return (
-          <div key={chapter} className="mb-8">
-            <h3 className="text-xl font-medium mb-4">{chapter}</h3>
-            <Accordions type="single" collapsible>
-              {incompleteQuizzes.map((quiz) => (
-                <Accordion key={quiz.id} title={`${quiz.question}`}>
-                  <Quiz quizId={quiz.id} />
-                </Accordion>
-              ))}
-            </Accordions>
-          </div>
-        );
-      })}
-      
-      {allQuizzesCompleted && (
-        <div className="mt-12 bg-white dark:bg-gray-800 rounded-lg shadow-lg p-8">
-          <div className="flex items-center justify-center mb-6">
-            <Award className="w-16 h-16 text-green-500 mr-4" />
-            <h2 className="text-3xl font-bold text-gray-800 dark:text-white" style={{ fontSize: '2rem', marginTop: '1em'}}>Congratulations!</h2>
-          </div>
-          <p className="text-center text-gray-600 dark:text-gray-300 mb-8">
-            You've completed all quizzes for the {quizData.courses[courseId].title} course. Claim your certificate now!
-          </p>
-          <div className="mb-6">
-            <label htmlFor="userName" className="block text-sm font-medium text-gray-700 dark:text-gray-300 mb-2">
-              Enter your full name for the certificate:
-            </label>
-            <input
-              type="text"
-              id="userName"
-              value={userName}
-              onChange={(e) => setUserName(e.target.value)}
-              className="w-full px-4 py-2 border border-gray-300 rounded-md shadow-sm focus:ring-2 focus:ring-indigo-500 focus:border-indigo-500 dark:bg-gray-700 dark:border-gray-600 dark:text-white"
-              placeholder="John Doe"
-            />
-          </div>
-          <button
-            className={cn(
-              buttonVariants({ variant: 'default' }),
-              'w-full mb-6 py-3 text-lg'
-            )}
-            onClick={generateCertificate}
-            disabled={isGenerating}
-          >
-            {isGenerating ? 'Generating Certificate...' : 'Generate My Certificate'}
-          </button>
-          <div className="border-t border-gray-200 dark:border-gray-700 pt-6">
-            <p className="text-center text-gray-600 dark:text-gray-300 mb-4">
-              Share your achievement:
-            </p>
-            <div className="flex justify-center space-x-4">
-              <a href={shareOnLinkedIn()} target="_blank" rel="noopener noreferrer"
-                style={{ textDecoration: 'none' }}
-                className={cn(
-                  buttonVariants({ variant: 'secondary' }),
-                  'flex items-center px-4 py-2'
-                )}
-              >
-                <Linkedin className="mr-2 h-5 w-5" />
-                Add to LinkedIn
-              </a>
-              <button
-                className={cn(
-                  buttonVariants({ variant: 'secondary' }),
-                  'flex items-center px-4 py-2'
-                )}
-                onClick={shareOnTwitter}
-              >
-                <Twitter className="mr-2 h-5 w-5" />
-                Twitter
-              </button>
-            </div>
-          </div>
-        </div>
-      )}
-      {!allQuizzesCompleted && (
-        <div className="mt-12 bg-muted rounded-lg shadow-lg p-8">
-          <Share2 className="w-8 h-8 mx-auto mb-2 text-yellow-500" />
-          Complete all quizzes to unlock your certificate and share your achievement!
-        </div>
-      )}
-    </div>
-  );
-};
-
-export default CertificatePage;
\ No newline at end of file
diff --git a/components/chatbot.tsx b/components/chatbot.tsx
deleted file mode 100644
index 6f36f3b2..00000000
--- a/components/chatbot.tsx
+++ /dev/null
@@ -1,24 +0,0 @@
-"use client";
-import React, { useEffect } from 'react';
-
-const COOKBOOK_API_KEY = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI2NmJlNDZhZDZkMjk4YjBkZjY5OWExMTgiLCJpYXQiOjE3MjM3NDU5NjUsImV4cCI6MjAzOTMyMTk2NX0.YRFXnhY4r8Z3it93zRzBenOL3oBPtD96tGYYl-USX2o"
-const Chatbot: React.FC = () => {
-  useEffect(() => {
-    if (typeof document !== 'undefined') {
-      let script = document.getElementById('__cookbook-script') as HTMLScriptElement | null;
-      if (!script) {
-        script = document.createElement('script');
-        script.src = 'https://cdn.jsdelivr.net/npm/@cookbookdev/docsbot/dist/standalone/index.cjs.js';
-        script.id = '__cookbook-script';
-        script.async = true;
-        document.body.appendChild(script);
-      }
-    }
-  }, []);
-
-  return (
-    <div id="__cookbook" data-api-key={COOKBOOK_API_KEY} />
-  );
-};
-
-export default Chatbot;
\ No newline at end of file
diff --git a/components/code-block.tsx b/components/code-block.tsx
deleted file mode 100644
index 031451bc..00000000
--- a/components/code-block.tsx
+++ /dev/null
@@ -1,54 +0,0 @@
-import * as Base from 'fumadocs-ui/components/codeblock';
-import type { HTMLAttributes } from 'react';
-import { useMemo } from 'react';
-import { getHighlighter } from 'shiki';
-
-const highlighter = await getHighlighter({
-  langs: ['bash', 'ts', 'tsx'],
-  themes: ['github-light', 'github-dark'],
-});
-
-export type CodeBlockProps = HTMLAttributes<HTMLPreElement> & {
-  code: string;
-  wrapper?: Base.CodeBlockProps;
-  lang: 'bash' | 'ts' | 'tsx';
-};
-
-export function CodeBlock({
-  code,
-  lang,
-  wrapper,
-  ...props
-}: CodeBlockProps): React.ReactElement {
-  const html = useMemo(
-    () =>
-      highlighter.codeToHtml(code, {
-        lang,
-        defaultColor: false,
-        themes: {
-          light: 'github-light',
-          dark: 'github-dark',
-        },
-        transformers: [
-          {
-            name: 'remove-pre',
-            root: (root) => {
-              if (root.children[0].type !== 'element') return;
-
-              return {
-                type: 'root',
-                children: root.children[0].children,
-              };
-            },
-          },
-        ],
-      }),
-    [code, lang],
-  );
-
-  return (
-    <Base.CodeBlock {...wrapper}>
-      <Base.Pre {...props} dangerouslySetInnerHTML={{ __html: html }} />
-    </Base.CodeBlock>
-  );
-}
diff --git a/components/comments.tsx b/components/comments.tsx
deleted file mode 100644
index 6615945a..00000000
--- a/components/comments.tsx
+++ /dev/null
@@ -1,68 +0,0 @@
-"use client";
-import React, { useEffect, useRef, useState } from 'react';
-
-const Comments: React.FC = () => {
-  const giscusRef = useRef<HTMLDivElement>(null);
-  const [theme, setTheme] = useState<'light' | 'dark'>(() => {
-    if (typeof window !== 'undefined') {
-      return document.documentElement.classList.contains('dark') ? 'dark' : 'light';
-    }
-    return 'light';
-  });
-
-  useEffect(() => {
-    const updateTheme = () => {
-      const isDarkMode = document.documentElement.classList.contains('dark');
-      setTheme(isDarkMode ? 'dark' : 'light');
-    };
-
-    updateTheme();
-    const observer = new MutationObserver(updateTheme);
-    observer.observe(document.documentElement, { attributes: true, attributeFilter: ['class'] });
-    return () => observer.disconnect();
-  }, []);
-
-  useEffect(() => {
-    if (typeof window !== 'undefined' && window.location.origin === 'https://academy.avax.network') {
-      const updateGiscusTheme = (theme: 'light' | 'dark') => {
-        const iframe = document.querySelector<HTMLIFrameElement>('.giscus-frame');
-        if (iframe) {
-          iframe.contentWindow?.postMessage({ giscus: { setConfig: { theme: theme === 'dark' ? 'transparent_dark' : 'light' } } },'https://giscus.app');
-        }
-      };
-
-      const script = document.createElement('script');
-      script.src = "https://giscus.app/client.js";
-      script.setAttribute('data-repo', "ava-labs/avalanche-academy");
-      script.setAttribute('data-repo-id', "R_kgDOMDfRrg");
-      script.setAttribute('data-category', "Discussions");
-      script.setAttribute('data-category-id', "DIC_kwDOMDfRrs4CiB5x");
-      script.setAttribute('data-mapping', "title");
-      script.setAttribute('data-strict', "0");
-      script.setAttribute('data-reactions-enabled', "0");
-      script.setAttribute('data-emit-metadata', "0");
-      script.setAttribute('data-input-position', "bottom");
-      script.setAttribute('data-theme', theme === 'dark' ? 'transparent_dark' : 'light');
-      script.setAttribute('data-lang', "en");
-      script.async = true;
-
-      if (giscusRef.current && !giscusRef.current.hasChildNodes()) {
-        giscusRef.current.appendChild(script);
-
-        const observer = new MutationObserver(() => {
-          if (document.querySelector('.giscus-frame')) {
-            updateGiscusTheme(theme);
-            observer.disconnect();
-          }
-        });
-        observer.observe(giscusRef.current, { childList: true, subtree: true });
-      } else {
-        updateGiscusTheme(theme);
-      }
-    }
-  }, [theme]);
-
-  return <div id="comment-box" ref={giscusRef} />;
-};
-
-export default Comments;
\ No newline at end of file
diff --git a/components/footer.tsx b/components/footer.tsx
deleted file mode 100644
index 20e94b5e..00000000
--- a/components/footer.tsx
+++ /dev/null
@@ -1,117 +0,0 @@
-export function Footer() {
-  return (
-    <footer className="mt-auto border-t bg-card py-12 text-secondary-foreground">
-      <div className="container flex flex-col gap-4 sm:flex-row sm:items-end sm:justify-between">
-        <div>
-          <p className="mb-1 text-sm font-semibold">Avalanche Academy</p>
-          <p className="text-xs">
-            Crafted with ❤️ by Ava Labs DevRel team.
-          </p>
-        </div>
-          <div className="grid grid-cols-2 gap-8 mt-12 text-sm font-medium text-gray-500 lg:grid-cols-3 lg:mt-0 xl:col-span-2">
-            <div>
-              <h3 className="text-lg text-neutral-800 dark:text-neutral-100">
-                Avalanche
-              </h3>
-              <ul role="list" className="mt-4 space-y-2">
-                <li>
-                  <a
-                    href="https://www.avax.network/get-started"
-                    target="_blank"
-                    className="relative after:absolute after:-bottom-1 after:left-0 after:h-[2px] after:w-full after:origin-bottom-right after:scale-x-0 after:bg-gray-500 after:transition-transform after:duration-200 after:ease-&lsqb;cubic-bezier(0.65_0.05_0.36_1)&rsqb; hover:after:origin-bottom-left hover:after:scale-x-100 p-0.5 rounded-md transition duration-300 outline-none focus:ring-2 focus:ring-offset-2 focus:ring-offset-white dark:focus:ring-offset-neutral-800 dark:focus:ring-neutral-600 focus:ring-neutral-100"
-                  >
-                    Get Started
-                  </a>
-                </li>
-                <li>
-                  <a
-                    href="https://subnets.avax.network/"
-                    target="_blank"
-                    className="relative after:absolute after:-bottom-1 after:left-0 after:h-[2px] after:w-full after:origin-bottom-right after:scale-x-0 after:bg-gray-500 after:transition-transform after:duration-200 after:ease-&lsqb;cubic-bezier(0.65_0.05_0.36_1)&rsqb; hover:after:origin-bottom-left hover:after:scale-x-100 p-0.5 rounded-md transition duration-300 outline-none focus:ring-2 focus:ring-offset-2 focus:ring-offset-white dark:focus:ring-offset-neutral-800 dark:focus:ring-neutral-600 focus:ring-neutral-100"
-                  >
-                    Explorer
-                  </a>
-                </li>
-                <li>
-                  <a
-                    href="https://stats.avax.network/dashboard/overview/"
-                    target="_blank"
-                    className="relative after:absolute after:-bottom-1 after:left-0 after:h-[2px] after:w-full after:origin-bottom-right after:scale-x-0 after:bg-gray-500 after:transition-transform after:duration-200 after:ease-&lsqb;cubic-bezier(0.65_0.05_0.36_1)&rsqb; hover:after:origin-bottom-left hover:after:scale-x-100 p-0.5 rounded-md transition duration-300 outline-none focus:ring-2 focus:ring-offset-2 focus:ring-offset-white dark:focus:ring-offset-neutral-800 dark:focus:ring-neutral-600 focus:ring-neutral-100"
-                  >
-                    Statistics
-                  </a>
-                </li>
-                
-              </ul>
-            </div>
-            <div>
-              <h3 className="text-lg text-neutral-800 dark:text-neutral-100">
-                Community
-              </h3>
-              <ul role="list" className="mt-4 space-y-2">
-                <li>
-                  <a
-                    href="https://github.com/ava-labs"
-                    target="_blank"
-                    className="relative after:absolute after:-bottom-1 after:left-0 after:h-[2px] after:w-full after:origin-bottom-right after:scale-x-0 after:bg-gray-500 after:transition-transform after:duration-200 after:ease-&lsqb;cubic-bezier(0.65_0.05_0.36_1)&rsqb; hover:after:origin-bottom-left hover:after:scale-x-100 p-0.5 rounded-md transition duration-300 outline-none focus:ring-2 focus:ring-offset-2 focus:ring-offset-white dark:focus:ring-offset-neutral-800 dark:focus:ring-neutral-600 focus:ring-neutral-100"
-                  >
-                    GitHub
-                  </a>
-                </li>
-                <li>
-                  <a
-                    href="https://medium.com/@avaxdevelopers"
-                    target="_blank"
-                    className="relative after:absolute after:-bottom-1 after:left-0 after:h-[2px] after:w-full after:origin-bottom-right after:scale-x-0 after:bg-gray-500 after:transition-transform after:duration-200 after:ease-&lsqb;cubic-bezier(0.65_0.05_0.36_1)&rsqb; hover:after:origin-bottom-left hover:after:scale-x-100 p-0.5 rounded-md transition duration-300 outline-none focus:ring-2 focus:ring-offset-2 focus:ring-offset-white dark:focus:ring-offset-neutral-800 dark:focus:ring-neutral-600 focus:ring-neutral-100"
-                  >
-                    Medium Blog
-                  </a>
-                </li>
-                <li>
-                  <a
-                    href="https://twitter.com/AvaxDevelopers"
-                    target="_blank"
-                    className="relative after:absolute after:-bottom-1 after:left-0 after:h-[2px] after:w-full after:origin-bottom-right after:scale-x-0 after:bg-gray-500 after:transition-transform after:duration-200 after:ease-&lsqb;cubic-bezier(0.65_0.05_0.36_1)&rsqb; hover:after:origin-bottom-left hover:after:scale-x-100 p-0.5 rounded-md transition duration-300 outline-none focus:ring-2 focus:ring-offset-2 focus:ring-offset-white dark:focus:ring-offset-neutral-800 dark:focus:ring-neutral-600 focus:ring-neutral-100"
-                  >
-                    Twitter
-                  </a>
-                </li>
-              </ul>
-            </div>
-            <div className="mt-12 md:mt-0">
-              <h3 className="text-lg text-neutral-800 dark:text-neutral-100">
-                More Links
-              </h3>
-              <ul role="list" className="mt-4 space-y-2">
-                <li>
-                  <a
-                    href="https://status.avax.network/"
-                    target="_blank"
-                    className="relative after:absolute after:-bottom-1 after:left-0 after:h-[2px] after:w-full after:origin-bottom-right after:scale-x-0 after:bg-gray-500 after:transition-transform after:duration-200 after:ease-&lsqb;cubic-bezier(0.65_0.05_0.36_1)&rsqb; hover:after:origin-bottom-left hover:after:scale-x-100 p-0.5 rounded-md transition duration-300 outline-none focus:ring-2 focus:ring-offset-2 focus:ring-offset-white dark:focus:ring-offset-neutral-800 dark:focus:ring-neutral-600 focus:ring-neutral-100"
-                  >
-                    Network Status
-                  </a>
-                </li>
-                <li>
-                  <a
-                    href="https://core.app/"
-                    className="relative after:absolute after:-bottom-1 after:left-0 after:h-[2px] after:w-full after:origin-bottom-right after:scale-x-0 after:bg-gray-500 after:transition-transform after:duration-200 after:ease-&lsqb;cubic-bezier(0.65_0.05_0.36_1)&rsqb; hover:after:origin-bottom-left hover:after:scale-x-100 p-0.5 rounded-md transition duration-300 outline-none focus:ring-2 focus:ring-offset-2 focus:ring-offset-white dark:focus:ring-offset-neutral-800 dark:focus:ring-neutral-600 focus:ring-neutral-100"
-                  >
-                    Core Wallet
-                  </a>
-                </li>
-                <li>
-                  <a
-                    href="https://www.avax.network/legal"
-                    className="relative after:absolute after:-bottom-1 after:left-0 after:h-[2px] after:w-full after:origin-bottom-right after:scale-x-0 after:bg-gray-500 after:transition-transform after:duration-200 after:ease-&lsqb;cubic-bezier(0.65_0.05_0.36_1)&rsqb; hover:after:origin-bottom-left hover:after:scale-x-100 p-0.5 rounded-md transition duration-300 outline-none focus:ring-2 focus:ring-offset-2 focus:ring-offset-white dark:focus:ring-offset-neutral-800 dark:focus:ring-neutral-600 focus:ring-neutral-100"
-                  >
-                    Legal
-                  </a>
-                </li>
-              </ul>
-            </div>
-          </div>
-      </div>
-    </footer>
-  )
-}
\ No newline at end of file
diff --git a/components/gallery.tsx b/components/gallery.tsx
deleted file mode 100644
index ecb9c6e0..00000000
--- a/components/gallery.tsx
+++ /dev/null
@@ -1,18 +0,0 @@
-export default function Gallery({ url1, url2 } : { url1 : string, url2 : string }){
-  return (
-    <div className="row" style={{display: "flex"}}>
-      <div className="column">
-        <img
-          src={url1}
-          style={{ border: '1px solid rgb(220, 220, 220)' }}
-        />
-      </div>
-      <div className="column">
-        <img
-          src={url2}
-          style={{ border: '1px solid rgb(220, 220, 220)' }}
-        />
-      </div>
-    </div>
-  );
-}
\ No newline at end of file
diff --git a/components/instructor.tsx b/components/instructor.tsx
deleted file mode 100644
index df021ff5..00000000
--- a/components/instructor.tsx
+++ /dev/null
@@ -1,40 +0,0 @@
-import {getInstructorsByNames} from '@/content/common/intro/instructors'
-import Link from 'next/link';
-import { v4 as uuidv4 } from 'uuid';
-
-function Instructor ({ id } : { id : string }){
-    return (
-      <div>
-        <iframe
-          className="aspect-video w-full"
-          src={"https://www.youtube.com/embed/" + id}
-          title="YouTube Video Player"
-          allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
-        ></iframe>
-      </div>
-    );
-  };
-
-export default function Instructors ({ names } : { names : string[] }) {
-    return (
-        <div className="flex flex-col space-y-4">
-            {getInstructorsByNames(names).map((instructor) => (
-                <Link href={instructor.twitter} target="_blank" key={uuidv4()} className="flex text-muted-foreground hover:text-foreground">
-                    <img 
-                        src={`/common-images/intro/instructors/${instructor.name.toLowerCase().replaceAll(" ", "-")}.jpeg`} 
-                        alt={instructor.name} 
-                        className="w-12 h-12 rounded-full" 
-                    />
-                    <div className="flex flex-col ml-3 my-auto">
-                        <div className="font-semibold">
-                            {instructor.name}
-                        </div>
-                        <div className="text-xs">
-                            {instructor.title}
-                        </div>
-                    </div>
-                </Link>
-            ))}
-        </div>
-    );
-}
\ No newline at end of file
diff --git a/components/mermaid.tsx b/components/mermaid.tsx
deleted file mode 100644
index b52498d9..00000000
--- a/components/mermaid.tsx
+++ /dev/null
@@ -1,19 +0,0 @@
-"use client";
-import React, { useEffect } from "react";
-import mermaid from "mermaid";
-
-mermaid.initialize({
-  startOnLoad: true,
-});
-
-type MermaidProps = {
-  readonly chart: string;
-};
-
-const Mermaid = ({ chart }: MermaidProps): JSX.Element => {
-  useEffect(() => mermaid.contentLoaded(), []);
-
-  return <div className="mermaid">{chart}</div>;
-};
-
-export default Mermaid;
\ No newline at end of file
diff --git a/components/quizzes/QuizProgress.tsx b/components/quizzes/QuizProgress.tsx
deleted file mode 100644
index 01c364fe..00000000
--- a/components/quizzes/QuizProgress.tsx
+++ /dev/null
@@ -1,60 +0,0 @@
-"use client";
-import React, { useState, useEffect } from 'react';
-import { getQuizResponse } from '@/utils/indexedDB';
-import quizData from './quizData.json';
-
-const QuizProgress: React.FC = () => {
-  const [progress, setProgress] = useState<{ [quizId: string]: boolean }>({});
-  const [isLoading, setIsLoading] = useState(true);
-
-  useEffect(() => {
-    async function loadProgress() {
-      const quizIds = Object.keys(quizData.quizzes);
-      const quizProgress: { [quizId: string]: boolean } = {};
-      
-      for (const quizId of quizIds) {
-        const response = await getQuizResponse(quizId);
-        quizProgress[quizId] = response ? response.isCorrect : false;
-      }
-      
-      setProgress(quizProgress);
-      setIsLoading(false);
-    }
-    loadProgress();
-  }, []);
-
-  if (isLoading) {
-    return <div>Loading progress...</div>;
-  }
-
-  const totalQuizzes = Object.keys(quizData.quizzes).length;
-  const completedQuizzes = Object.values(progress).filter(Boolean).length;
-  const eligibleForCertificate = completedQuizzes === totalQuizzes;
-
-  return (
-    <div className="mt-8 p-6 bg-white shadow-md rounded-lg">
-      <h2 className="text-2xl font-bold mb-4">Quiz Progress</h2>
-      <ul className="mb-4">
-        {Object.entries(quizData.quizzes).map(([quizId, quizInfo]) => (
-          <li key={quizId} className="flex items-center mb-2">
-            <span className={`w-4 h-4 rounded-full mr-2 ${progress[quizId] ? 'bg-green-500' : 'bg-red-500'}`}></span>
-            Quiz {quizId}: {progress[quizId] ? 'Completed' : 'Not completed'}
-          </li>
-        ))}
-      </ul>
-      {eligibleForCertificate ? (
-        <div className="bg-green-100 border-l-4 border-green-500 text-green-700 p-4" role="alert">
-          <p className="font-bold">Congratulations!</p>
-          <p>You're eligible for a certificate. Click here to claim it.</p>
-        </div>
-      ) : (
-        <div className="bg-yellow-100 border-l-4 border-yellow-500 text-yellow-700 p-4" role="alert">
-          <p className="font-bold">Keep going!</p>
-          <p>Complete more quizzes to earn your certificate.</p>
-        </div>
-      )}
-    </div>
-  );
-};
-
-export default QuizProgress;
\ No newline at end of file
diff --git a/components/quizzes/quiz.tsx b/components/quizzes/quiz.tsx
deleted file mode 100644
index 57bef300..00000000
--- a/components/quizzes/quiz.tsx
+++ /dev/null
@@ -1,219 +0,0 @@
-"use client";
-import React, { useState, useEffect } from 'react';
-import { v4 as uuidv4 } from 'uuid';
-import { saveQuizResponse, getQuizResponse, resetQuizResponse } from '@/utils/indexedDB';
-import Image from 'next/image';
-import { cn } from '@/utils/cn';
-import { buttonVariants } from '@/components/ui/button';
-import quizData from './quizData.json';
-
-interface QuizProps {
-  quizId: string;
-}
-
-interface QuizData {
-  question: string;
-  options: string[];
-  correctAnswers: number[];
-  hint: string;
-  explanation: string;
-}
-
-const Quiz: React.FC<QuizProps> = ({ quizId }) => {
-  const [quizInfo, setQuizInfo] = useState<QuizData | null>(null);
-  const [selectedAnswers, setSelectedAnswers] = useState<number[]>([]);
-  const [isAnswerChecked, setIsAnswerChecked] = useState<boolean>(false);
-  const [isCorrect, setIsCorrect] = useState<boolean>(false);
-  const [isClient, setIsClient] = useState(false);
-
-  useEffect(() => {
-    setIsClient(true);
-    const all = {
-      ...quizData.quizzes,
-    };
-    const fetchedQuizInfo = all[quizId as keyof typeof quizData.quizzes];
-    if (fetchedQuizInfo) {
-      setQuizInfo(fetchedQuizInfo);
-    }
-    loadSavedResponse();
-  }, [quizId]);
-
-  const loadSavedResponse = async () => {
-    const savedResponse = await getQuizResponse(quizId);
-    if (savedResponse) {
-      setSelectedAnswers(savedResponse.selectedAnswers || []);
-      setIsAnswerChecked(savedResponse.isAnswerChecked || false);
-      setIsCorrect(savedResponse.isCorrect || false);
-    } else {
-      resetQuizState();
-    }
-  };
-
-  const resetQuizState = () => {
-    setSelectedAnswers([]);
-    setIsAnswerChecked(false);
-    setIsCorrect(false);
-  };
-
-  const handleAnswerSelect = (index: number) => {
-    if (!isAnswerChecked) {
-      if (quizInfo && quizInfo.correctAnswers.length === 1) {
-        setSelectedAnswers([index]);
-      } else {
-        setSelectedAnswers(prev => 
-          prev.includes(index) 
-            ? prev.filter(a => a !== index) 
-            : [...prev, index]
-        );
-      }
-    }
-  };
-
-  const checkAnswer = async () => {
-    if (quizInfo && selectedAnswers.length > 0 && quizInfo.correctAnswers.length > 0) {
-      const correct = quizInfo.correctAnswers.length === 1
-        ? selectedAnswers[0] === quizInfo.correctAnswers[0]
-        : selectedAnswers.length === quizInfo.correctAnswers.length && 
-          selectedAnswers.every(answer => quizInfo.correctAnswers.includes(answer));
-      setIsCorrect(correct);
-      setIsAnswerChecked(true);
-
-      await saveQuizResponse(quizId, {
-        selectedAnswers,
-        isAnswerChecked: true,
-        isCorrect: correct,
-      });
-    }
-  };
-
-  const handleTryAgain = async () => {
-    await resetQuizResponse(quizId);
-    resetQuizState();
-  };
-
-  const renderAnswerFeedback = () => {
-    if (isAnswerChecked && quizInfo) {
-      if (isCorrect) {
-        return (
-          <div className="mt-4 p-4 bg-green-50 dark:bg-green-900/30 rounded-lg">
-            <div className="flex items-center text-green-800 dark:text-green-300 mb-2">
-              <svg className="mr-2" style={{width: '1rem', height: '1rem'}} fill="currentColor" viewBox="0 0 20 20">
-                <path fillRule="evenodd" d="M10 18a8 8 0 100-16 8 8 0 000 16zm3.707-9.293a1 1 0 00-1.414-1.414L9 10.586 7.707 9.293a1 1 0 00-1.414 1.414l2 2a1 1 0 001.414 0l4-4z" clipRule="evenodd" />
-              </svg>
-              <span className="font-semibold text-sm">Correct</span>
-            </div>
-            <p className="text-sm text-gray-600 dark:text-gray-300 m-0">{quizInfo.explanation}</p>
-          </div>
-        );
-      } else {
-        return (
-          <div className="mt-4 p-3 bg-amber-50 dark:bg-amber-900/30 rounded-lg">
-            <div className="flex items-center text-amber-800 dark:text-amber-300 mb-2">
-              <svg className="mr-2" style={{width: '1rem', height: '1rem'}} fill="currentColor" viewBox="0 0 20 20">
-                <path fillRule="evenodd" d="M10 18a8 8 0 100-16 8 8 0 000 16zM8.707 7.293a1 1 0 00-1.414 1.414L8.586 10l-1.293 1.293a1 1 0 101.414 1.414L10 11.414l1.293 1.293a1 1 0 001.414-1.414L11.414 10l1.293-1.293a1 1 0 00-1.414-1.414L10 8.586 8.707 7.293z" clipRule="evenodd" />
-              </svg>
-              <span className="font-semibold text-sm">Not Quite</span>
-            </div>
-            <p className="text-sm text-gray-600 dark:text-gray-300 m-0"><b>Hint:</b> {quizInfo.hint}</p>
-          </div>
-        );
-      }
-    }
-    return null;
-  };
-
-  if (!isClient || !quizInfo) {
-    return <div>Loading...</div>;
-  }
-
-  return (
-    <div className="bg-gray-50 dark:bg-black flex items-center justify-center p-4">
-      <div className="w-full max-w-2xl bg-white dark:bg-black shadow-lg rounded-lg overflow-hidden">
-        <div className="text-center p-4">
-        <div className="mx-auto flex items-center justify-center mb-4 overflow-hidden">
-          <Image
-            src="/wolfie-check.png"
-            alt="Quiz topic"
-            width={60}
-            height={60}
-            className="object-cover"
-            style={{margin: '0em'}}
-          />
-        </div>
-        <h4 className="font-normal" style={{marginTop: '0'}}>Time for a Quiz!</h4>
-        <p className="text-sm text-gray-500 dark:text-gray-400">
-          Wolfie wants to test your knowledge. {quizInfo.correctAnswers.length === 1 ? "Select the correct answer." : "Select all correct answers."}
-        </p>
-      </div>
-      <div className="px-6 py-4">
-        <div className="text-center mb-4">
-          <h2 className="text-lg font-medium text-gray-800 dark:text-white" style={{marginTop: '0'}}>{quizInfo.question}</h2>
-        </div>
-        <div className="space-y-3">
-          {quizInfo.options.map((option, index) => (
-            <div 
-              key={uuidv4()}
-              className={`flex items-center p-3 rounded-lg border transition-colors cursor-pointer ${
-                isAnswerChecked
-                  ? selectedAnswers.includes(index)
-                    ? quizInfo.correctAnswers.includes(index)
-                      ? 'border-avax-green bg-green-50 dark:bg-green-900/30 dark:border-green-700'
-                      : 'border-avax-red bg-red-50 dark:bg-red-900/30 dark:border-red-700'
-                    : 'border-gray-200 bg-white dark:border-gray-700 dark:bg-black'
-                  : selectedAnswers.includes(index)
-                    ? 'border-[#3752ac] bg-[#3752ac] bg-opacity-10 dark:bg-opacity-30'
-                    : 'border-gray-200 dark:border-gray-700 hover:bg-gray-50 dark:hover:bg-gray-900'
-              }`}
-              onClick={() => handleAnswerSelect(index)}
-            >
-              <span className={`w-6 h-6 shrink-0 flex items-center justify-center ${quizInfo.correctAnswers.length === 1 ? 'rounded-full' : 'rounded-md'} mr-3 text-sm ${
-                isAnswerChecked
-                  ? selectedAnswers.includes(index)
-                    ? quizInfo.correctAnswers.includes(index)
-                      ? 'bg-avax-green text-white'
-                      : 'bg-avax-red text-white'
-                    : 'bg-gray-200 dark:bg-gray-700 text-gray-600 dark:text-gray-300'
-                  : selectedAnswers.includes(index)
-                    ? 'bg-[#3752ac] text-white'
-                    : 'bg-gray-200 dark:bg-gray-700 text-gray-600 dark:text-gray-300'
-              }`}>
-                {quizInfo.correctAnswers.length === 1 
-                  ? String.fromCharCode(65 + index)
-                  : (selectedAnswers.includes(index) ? '✓' : '')}
-              </span>
-              <span className="text-sm text-gray-600 dark:text-gray-300">{option}</span>
-            </div>
-          ))}
-        </div>
-        {renderAnswerFeedback()}
-      </div>
-      <div className="px-6 py-4 flex justify-center">
-        {!isAnswerChecked ? (
-          <button 
-            className={cn(
-              buttonVariants({ variant: 'default'}),
-            )}
-            onClick={checkAnswer}
-            disabled={selectedAnswers.length === 0}
-          >
-            Check Answer
-          </button>
-        ) : (
-          !isCorrect && (
-            <button
-              className={cn(
-                buttonVariants({ variant: 'secondary' }),
-              )}
-              onClick={handleTryAgain}
-            >
-              Try Again!
-            </button>
-          )
-        )}
-      </div>
-    </div>
-    </div>
-  );
-};
-
-export default Quiz;
\ No newline at end of file
diff --git a/components/quizzes/quizData.json b/components/quizzes/quizData.json
deleted file mode 100644
index 5965501d..00000000
--- a/components/quizzes/quizData.json
+++ /dev/null
@@ -1,981 +0,0 @@
-{
-  "courses": {
-    "avalanche-fundamentals": {
-      "title": "Avalanche Fundamentals",
-      "quizzes": ["101", "102", "103", "104", "105", "106", "107", "108", "109", "110", "111", "112", "113", "114", "115", "116", "117"]
-    },
-    "l1-tokenomics": {
-      "title": "L1 Tokenomics",
-      "quizzes": ["201", "202", "203", "204", "205", "206", "207", "208", "209", "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": {
-    "101": {
-      "question": "What is the underlying principle of the Avalanche Consensus family?",
-      "options": [
-        "Repeated Sub-Sampling",
-        "Centralized Election",
-        "Randomly choosing a Validator that decides on the next State",
-        "Proof of Work"
-      ],
-      "correctAnswers": [0],
-      "hint": "Think about how Avalanche Consensus achieves consensus.",
-      "explanation": "The underlying principle of the Avalanche Consensus family is Repeated Sub-Sampling. This means that validators repeatedly sample the network to reach consensus.",
-      "chapter": "Primer on Avalanche Consensus"
-    },
-    "102": {
-      "question": "What is the role of validators in the event of conflicting transactions?",
-      "options": [
-        "Validators choose the transaction that benefits them the most.",
-        "Validators automatically reject all conflicting transactions.",
-        "Validators collectively decide on which of the two conflicting transactions will be accepted by all validators and determine the next state.",
-        "Validators create a new transaction to resolve the conflict."
-      ],
-      "correctAnswers": [2],
-      "hint": "Think about how validators resolve conflicts in a blockchain network.",
-      "explanation": "In the event of conflicting transactions, validators have to collectively decide on which of the two conflicting transactions will be accepted by all validators and determine the next state. They do not act based on personal benefits, they don't reject all conflicting transactions, and they don't create new transactions to resolve conflicts.",
-      "chapter": "Primer on Avalanche Consensus"
-    },
-    "103": {
-      "question": "What is a Double Spending Attack in the context of blockchain?",
-      "options": [
-        "It is when a user attempts to spend more cryptocurrency than they own by creating multiple transactions that reference the same funds.",
-        "It is when a user tries to double the amount of cryptocurrency they own through fraudulent transactions.",
-        "It is when a user performs two transactions at the exact same time to exploit the system.",
-        "It is when a validator duplicates transactions to increase their validation rewards."
-      ],
-      "correctAnswers": [0],
-      "hint": "Think about how a user would attempt to spend more funds than they hold.",
-      "explanation": "A Double Spending Attack is when a user attempts to spend more cryptocurrency than they own by creating multiple transactions that reference the same funds. This kind of attack is a threat to the integrity of the blockchain system.",
-      "chapter": "Primer on Avalanche Consensus"
-    },
-    "104": {
-      "question": "In the Avalanche Consensus protocol, what determines whether a validator changes its preference?",
-      "options": [
-        "A simple majority of sampled validators",
-        "An α-majority of sampled validators",
-        "A unanimous decision from sampled validators",
-        "The validator's initial random choice"
-      ],
-      "correctAnswers": [1],
-      "hint": "Think about the concept of 'α-majority' mentioned in the chapter.",
-      "explanation": "Avalanche consensus dictates that a validator changes its preference if an α-majority of the sampled validators agrees on another option. The α-majority is a key concept in the protocol, allowing for flexible decision-making based on the sampled subset of validators.",
-      "chapter": "Primer on Avalanche Consensus"
-    },
-    "105": {
-      "question": "When does a validator in Avalanche finalize its decision?",
-      "options": [
-        "After a set number of rounds of querying and getting majority consensus.",
-        "After the preference is confirmed by the α-majority for β (Decision Threshold) consecutive rounds.",
-        "As soon as a conflict between transactions arises.",
-        "When all validators in the system have replied with their preference."
-      ],
-      "correctAnswers": [1],
-      "hint": "Think about the process of finalizing a decision in Avalanche Consensus.",
-      "explanation": "In Avalanche, a validator finalizes its decision after its preference is confirmed by the α-majority for β (Decision Threshold) consecutive rounds. It's not a single round process, it doesn't happen immediately when a conflict arises, and it doesn't require replies from all validators in the system.",
-      "chapter": "Primer on Avalanche Consensus"
-    },
-    "106": {
-      "question": "What is the primary purpose of an L1 within the Avalanche network?",
-      "options": [
-        "Increasing token value",
-        "Mining cryptocurrency",
-        "Enabling specialized blockchain use cases"
-      ],
-      "correctAnswers": [2],
-      "hint": "Think about how L1s are designed to be customizable and optimized for specific use cases.",
-      "explanation": "The primary purpose of an L1 within the Avalanche network is to enable specialized blockchain use cases. Each L1 is designed to be optimized for specific use cases, thereby boosting the network's overall performance.",
-      "chapter": "Multi-Chain Architecture"
-    },
-    "107": {
-      "question": "The addition of a new decentralized application (dApp) on a single-chain system causes more competition over the block space of that chain.",
-      "options": [
-        "True",
-        "False"
-      ],
-      "correctAnswers": [0],
-      "hint": "Think about how each new dApp vies for the same block space in a single-chain system.",
-      "explanation": "Each new dApp vies for the same block space in a single-chain system, leading to unnecessary overcrowding of the chain. Multi-chain systems alleviate this issue.",
-      "chapter": "Multi-Chain Architecture"
-    },
-    "108": {
-      "question": "In case of a security breach on the Ethereum mainnet, all Layer 2 solutions are potentially affected.",
-      "options": [
-        "True",
-        "False"
-      ],
-      "correctAnswers": [0],
-      "hint": "Think about how Layer 2 solutions delegate security to the Ethereum mainnet.",
-      "explanation": "Layer 2 solutions delegate security to the Ethereum mainnet. Hence, a security breach on the mainnet could potentially affect all Layer 2 solutions.",
-      "chapter": "Multi-Chain Architecture"
-    },
-    "109": {
-      "question": "In the soda dispenser analogy, what does the 'state' of the machine represent? (Select all that apply)",
-      "options": [
-        "The soda flavors",
-        "The current balance",
-        "The number of cans available per flavor",
-        "The location of the machine"
-      ],
-      "correctAnswers": [1, 2],
-      "hint": "Think about what information the machine needs to keep track of to function properly.",
-      "explanation": "In the soda dispenser analogy, the 'state' of the machine represents the current balance, total revenue, and the number of cans available per brand.",
-      "chapter": "Virtual Machines & Blockchains"
-    },
-    "110": {
-      "question": "In the soda dispenser analogy, what of the following are operations of the machine? (Select all that apply)",
-      "options": [
-        "Inserting coins",
-        "The current balance",
-        "The location of the machine",
-        "Selecting a soda flavour"
-      ],
-      "correctAnswers": [0, 3],
-      "hint": "Think about what actions a user can take when interacting with the machine.",
-      "explanation": "In the soda dispenser analogy, the operations of the machine include inserting coins and selecting a soda flavor.",
-      "chapter": "Virtual Machines & Blockchains"
-    },
-    "111": {
-      "question": "What are the advantages of implementing state machines? (Select all that apply)",
-      "options": [
-        "Increased network speed",
-        "Decreased transaction costs",
-        "Reproducibility",
-        "Clear interface"
-      ],
-      "correctAnswers": [2, 3],
-      "hint": "Think about how state machines simplify interactions and ensure consistency.",
-      "explanation": "State machines, like the virtual machines in a blockchain, have a clear interface that makes it straightforward to interact with them. They are also reproducible, meaning multiple identical instances can be created.",
-      "chapter": "Virtual Machines & Blockchains"
-    },
-    "112": {
-      "question": "In blockchain systems, what role do validators play? (Select all that apply)",
-      "options": [
-        "They reach consensus on the sequence in which transactions are carried out",
-        "They determine the prices of the digital assets",
-        "They regulate the blockchain's electricity usage",
-        "They operate one or more instances of the virtual machines"
-      ],
-      "correctAnswers": [0, 3],
-      "hint": "Think about the role validators play in maintaining the blockchain's integrity.",
-      "explanation": "Validators in blockchain systems operate one or more instances of virtual machines and reach consensus on the sequence in which transactions are carried out.",
-      "chapter": "Virtual Machines & Blockchains"
-    },
-    "113": {
-      "question": "How do the validators make sure that they all have the same view on the state?",
-      "options": [
-        "By assigning each validator a unique part of the blockchain to monitor",
-        "Through the execution of operations on the local instance of the VM by all validators in the same order",
-        "Through the manual checking of each transaction by a centralized authority"
-      ],
-      "correctAnswers": [1],
-      "hint": "Think about how validators ensure that they all have the same view of the blockchain's state.",
-      "explanation": "Validators ensure they all have the same view on the state by executing operations on their local instance of the VM in the same order. This ensures consistency across the network.",
-      "chapter": "Virtual Machines & Blockchains"
-    },
-    "114": {
-      "question": "What is a Virtual Machine (VM) in the context of blockchain?",
-      "options": [
-        "A decentralized computer that can execute a program in a controlled environment",
-        "A physical machine that runs a blockchain network",
-        "A machine that dispenses soda"
-      ],
-      "correctAnswers": [0],
-      "hint": "Think about how a VM operates in a blockchain system.",
-      "explanation": "A Virtual Machine (VM) in the context of blockchain is like a decentralized computer that can execute a program in a controlled environment. It defines the application-level logic of a blockchain.",
-      "chapter": "Virtual Machines & Blockchains"
-    },
-    "115": {
-      "question": "How many VMs can Avalanche run?",
-      "options": [
-        "Only the Avalanche Virtual Machine",
-        "EVM and AVM",
-        "There is no limit to how many virtual machines can run on Avalanche. Everyone can create a modified VM catering best to their needs"
-      ],
-      "correctAnswers": [2],
-      "hint": "Think about the flexibility of Avalanche's architecture.",
-      "explanation": "Avalanche is designed to be highly flexible, allowing for an unlimited number of custom Virtual Machines to be created and run on the network.",
-      "chapter": "Virtual Machine Customization"
-    },
-    "116": {
-      "question": "Can a Virtual Machine (VM) be used to create multiple blockchains?",
-      "options": [
-        "Yes, the same VM can be used to create multiple blockchains",
-        "No, each blockchain requires a unique VM",
-        "Yes, but only if the blockchains are part of different networks"
-      ],
-      "correctAnswers": [0],
-      "hint": "Think about how a VM can be customized to create different blockchains.",
-      "explanation": "You can think of a Virtual Machine (VM) as a blueprint for a blockchain, where the same VM can be used to create multiple blockchains. Each of these blockchains adheres to the same rules but remains logically independent from the others.",
-      "chapter": "Virtual Machine Customization"
-    },
-    "117": {
-      "question": "How does Avalanche handle the modification of Virtual Machines (VMs)?",
-      "options": [
-        "Customization is challenging and requires a wide consensus among network participants.",
-        "Customization is not allowed as it can compromise the security of the blockchain.",
-        "Avalanche offers an easy API for VM developers.",
-        "Avalanche does not support customization of VMs."
-      ],
-      "correctAnswers": [2],
-      "hint": "Think about how Avalanche allows developers to modify Virtual Machines.",
-      "explanation": "Unlike one-chain-fits all systems, which requires a wide consensus to make changes, Avalanche allows for straightforward customization of Virtual Machines, making it more adaptable to unique use cases.",
-      "chapter": "Virtual Machine Customization"
-    },
-    "118": {
-      "question": "Which of the following best describes the role of a native token in an EVM-based blockchain?",
-      "options": [
-        "It is used only for staking and governance within the blockchain.",
-        "It serves as both a means of value transfer and as the gas token for executing transactions and smart contracts.",
-        "It is used exclusively for purchasing NFTs on the blockchain.",
-        "It has no functional role other than being a store of value."
-      ],
-      "correctAnswers": [1],
-      "hint": "Consider both value transfer and execution costs in the network.",
-      "explanation": "In an EVM-based blockchain, the native token serves as both a means of value transfer within the network and as the gas token for executing transfers or smart contracts. Some blockchains optionally choose to also use the native token as their staking and governance token.",
-      "chapter": "Interchain Token Transfer"
-    },
-    "119": {
-      "question": "What is the purpose of marking a function as 'payable' in Solidity?",
-      "options": [
-        "It allows the function to receive ERC-20 tokens.",
-        "It enables the function to execute without gas fees.",
-        "It allows the function to receive native blockchain tokens.",
-        "It prevents the function from modifying state variables."
-      ],
-      "correctAnswers": [2],
-      "hint": "Think about how functions handle incoming funds.",
-      "explanation": "In Solidity, marking a function as 'payable' allows it to accept native blockchain tokens like ETH or AVAX. Without 'payable', the function cannot receive native tokens.",
-      "chapter": "Interchain Token Transfer"
-    },
-    "120": {
-      "question": "What is the purpose of the `approve()` function in the ERC-20 token standard?",
-      "options": [
-        "It allows an address to transfer tokens to another address directly.",
-        "It grants an allowance for another account to spend the balance of an account.",
-        "It returns the total supply of the token.",
-        "It checks the balance of a specific address."
-      ],
-      "correctAnswers": [1],
-      "hint": "Consider how a spender gets permission to spend tokens from an owner's account.",
-      "explanation": "The `approve()` function allows an owner to authorize a spender to withdraw tokens from the owner's account, up to a specified limit, enabling the spender to use `transferFrom()` to transfer tokens.",
-      "chapter": "Interchain Token Transfer"
-    },
-    "121": {
-      "question": "Why is it necessary to call the `approve()` function before transferring ERC-20 tokens to a smart contract?",
-      "options": [
-        "Because it sets the gas fee for the transaction.",
-        "It is not necessary; tokens can be transferred without approval.",
-        "To check the balance of the smart contract.",
-        "To authorize the smart contract to transfer tokens from your account."
-      ],
-      "correctAnswers": [3],
-      "hint": "Consider how a smart contract gets permission to spend tokens from your account.",
-      "explanation": "The `approve()` function allows a user to authorize a smart contract to withdraw tokens from their account up to a specified limit. This enables the smart contract to use `transferFrom()` to transfer tokens on behalf of the user.",
-      "chapter": "Interchain Token Transfer"
-    },
-    "122": {
-      "question": "Why are native tokens wrapped into ERC-20 tokens like wAVAX or wETH?",
-      "options": [
-        "To increase their transaction speed on the blockchain.",
-        "To reduce the supply of the native token.",
-        "To represent native assets as ERC-20 tokens for compatibility with DeFi applications.",
-        "To convert them into stablecoins pegged to fiat currencies."
-      ],
-      "correctAnswers": [2],
-      "hint": "Consider how wrapping affects interoperability within the EVM ecosystem.",
-      "explanation": "Wrapping native tokens into ERC-20 tokens allows them to conform to the ERC-20 standard, making them compatible with decentralized applications, exchanges, and smart contracts that require ERC-20 tokens. This enhances interoperability and usability within the blockchain ecosystem.",
-      "chapter": "Interchain Token Transfer"
-    },
-    "123": {
-      "question": "Which of the following best describes the 'Lock & Mint' mechanism in asset bridging?",
-      "options": [
-        "Locking assets on the source blockchain and minting equivalent tokens on the target blockchain.",
-        "Burning assets on both the source and target blockchains simultaneously.",
-        "Using custodians to manage and transfer assets between blockchains.",
-        "Releasing assets without the need for smart contracts or locking mechanisms."
-      ],
-      "correctAnswers": [0],
-      "hint": "Consider how assets are secured on one chain and represented on another.",
-      "explanation": "In the 'Lock & Mint' mechanism, assets are locked in a smart contract on the source blockchain, and an equivalent amount of wrapped tokens are minted on the target blockchain. This allows the asset's value to be transferred and used on a different blockchain.",
-      "chapter": "Interchain Token Transfer"
-    },
-    "124": {
-      "question": "Which type of smart contract exploit allows attackers to repeatedly withdraw funds before the contract's state is updated?",
-      "options": [
-        "Reentrancy Attacks",
-        "Arithmetic Errors",
-        "Logic Flaws",
-        "Phishing Attacks"
-      ],
-      "correctAnswers": [0],
-      "hint": "Consider exploits involving recursive calls to a contract.",
-      "explanation": "Reentrancy attacks exploit a contract's ability to call itself before the initial function call is completed, allowing attackers to repeatedly withdraw funds before the contract's state is updated.",
-      "chapter": "Interchain Token Transfer"
-    },
-    "125": {
-      "question": "Which statement is true about token transfers in the Avalanche Interchain Token Transfer Design?",
-      "options": [
-        "Only ERC20 tokens can be transferred; native tokens are not supported.",
-        "Transfers must involve the same token type on both home and remote chains.",
-        "Any combination of ERC20 and native tokens can be transferred between home and remote chains.",
-        "Token transfers require approval from network administrators."
-      ],
-      "correctAnswers": [2],
-      "hint": "Consider the flexibility of token types allowed in transfers.",
-      "explanation": "The Avalanche Interchain Token Transfer Design supports transferring tokens with any combination of ERC20 and native tokens between home and remote chains, including ERC20 to ERC20, ERC20 to Native, Native to ERC20, and Native to Native.",
-      "chapter": "Interchain Token Transfer"
-    },
-    "126": {
-      "question": "What is the purpose of the `_tokenMultiplier` in the `TokenRemote` contract when bridging assets between chains with different decimal systems?",
-      "options": [
-        "It adjusts the token amount to match the decimal system of the target chain by multiplying or dividing as necessary.",
-        "It locks the tokens on the source chain before transfer.",
-        "It handles the minting of new tokens on the target chain.",
-        "It calculates the transaction fees for cross-chain transfers."
-      ],
-      "correctAnswers": [0],
-      "hint": "Consider how token amounts are scaled between chains with different decimal places.",
-      "explanation": "The `_tokenMultiplier` is used to scale the token amounts when transferring between chains with different decimal systems. It is calculated based on the difference in decimals between the home and remote tokens and ensures that the token value remains consistent across chains.",
-      "chapter": "Interchain Token Transfer"
-    },
-    "127": {
-      "question": "Can there be multiple TokenRemotes for a single TokenHome?",
-      "hint": "Think about how tokens are transferred between chains and where they originate from.",
-      "options": [
-        "Yes",
-        "No"
-      ],
-      "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/components/signatureSchemes.tsx b/components/signatureSchemes.tsx
deleted file mode 100644
index 62ab0101..00000000
--- a/components/signatureSchemes.tsx
+++ /dev/null
@@ -1,283 +0,0 @@
-"use client";
-const bls = require("@noble/bls12-381");
-import React, { useState } from "react";
-import { CodeBlock, Pre } from "fumadocs-ui/components/codeblock";
-import { buttonVariants } from "./ui/button";
-import { Input } from "./ui/input";
-
-const bufferToHex = (buffer: ArrayBufferLike): string => {
-  return [...new Uint8Array(buffer)]
-    .map((b) => b.toString(16).padStart(2, "0"))
-    .join("");
-};
-
-const checkSig = async (
-  signature: string,
-  publicKey: string,
-  message: string
-) => {
-  try {
-    let res = await bls.verify(
-      signature,
-      new TextEncoder().encode(message),
-      publicKey
-    );
-    return res;
-  } catch (error) {
-    console.error(error);
-    return false;
-  }
-};
-
-export const GenerateKeysButton: React.FC = () => {
-  const [privKey, setPrivKey] = useState<string | null>(null);
-  const [pubKey, setPubKey] = useState<string | null>(null);
-  const generateKeys = () => {
-    const privKey = new Uint8Array(32);
-    crypto.getRandomValues(privKey);
-    const pubKey = bufferToHex(bls.getPublicKey(privKey));
-    setPrivKey(bufferToHex(privKey.buffer));
-    setPubKey(pubKey);
-    return { privKey, pubKey };
-  };
-
-  return (
-    <div>
-      <button className={buttonVariants()} onClick={generateKeys}>
-        Generate Keys
-      </button>
-
-      {privKey && (
-        <CodeBlock title="🗝️ Private Key" lang="bash" allowCopy={true}>
-          <Pre>{privKey}</Pre>
-        </CodeBlock>
-      )}
-
-      {pubKey && (
-        <CodeBlock title="🔑 Public Key:" lang="bash" allowCopy={true}>
-          <Pre>{pubKey}</Pre>
-        </CodeBlock>
-      )}
-    </div>
-  );
-};
-
-export const SignMessageButton: React.FC = () => {
-  const [privKey, setPrivKey] = useState<string | null>(null);
-  const [message, setMessage] = useState<string | null>(null);
-  const [signature, setSignature] = useState<string | null>(null);
-
-  const signMessage = async () => {
-    if (!privKey || !message) {
-      return;
-    }
-    setSignature(
-      bufferToHex(await bls.sign(new TextEncoder().encode(message), privKey))
-    );
-  };
-
-  return (
-    <div>
-      <Input
-        id="privatekey"
-        label="🗝️ Private Key"
-        description="Enter private key to sign message with"
-        placeholder="3a408d0..."
-        onChange={(e) => setPrivKey(e.target.value)}
-      />
-
-      <Input
-        id="message"
-        label="📝 Message"
-        description="Enter any Message you want to sign with the Private Key"
-        placeholder="Hello"
-        onChange={(e) => setMessage(e.target.value)}
-      />
-
-      <button
-        className={buttonVariants()}
-        onClick={signMessage}
-        disabled={!privKey || !message}
-      >
-        Sign Message
-      </button>
-
-      {signature && (
-        <CodeBlock title="🔏 Signature:" lang="bash" allowCopy={true}>
-          <Pre>{signature}</Pre>
-        </CodeBlock>
-      )}
-    </div>
-  );
-};
-
-export const VerifySignatureButton: React.FC<{ aggregated?: boolean }> = ({
-  aggregated,
-}) => {
-  const [pubKey, setPubKey] = useState<string | null>(null);
-  const [message, setMessage] = useState<string | null>(null);
-  const [signature, setSignature] = useState<string | null>(null);
-  const [isValid, setIsValid] = useState<boolean | null>(null);
-
-  const verifySignature = async () => {
-    if (signature && pubKey && message) {
-      checkSig(signature, pubKey, message).then((res) => {
-        console.log(res);
-        if (res) {
-          setIsValid(res);
-        } else {
-          setIsValid(false);
-        }
-      });
-    }
-  };
-
-  return (
-    <div>
-      <Input
-        id="pubKey"
-        label={`🔑 ${aggregated ? "Aggregated " : ""}Public Key`}
-        description="Enter the Public Key that signed the Message."
-        placeholder="8f65ab..."
-        onChange={(e) => setPubKey(e.target.value)}
-      />
-
-      <Input
-        id="message"
-        label="📝 Message"
-        description="Enter the Message that was signed."
-        placeholder="Hello"
-        onChange={(e) => setMessage(e.target.value)}
-      />
-
-      <Input
-        id="signature"
-        label={`🔏 ${aggregated ? "Aggregated " : ""}Signature`}
-        description="Enter the Signature of the Message."
-        placeholder="8495e11..."
-        onChange={(e) => setSignature(e.target.value)}
-      />
-
-      <button
-        className={buttonVariants()}
-        onClick={verifySignature}
-        disabled={!signature || !pubKey || !message}
-      >
-        Verify Signature
-      </button>
-
-      {isValid !== null && (
-        <p>{isValid ? "✅ Signature is valid!" : "❌ Signature is invalid!"}</p>
-      )}
-    </div>
-  );
-};
-
-export const AggregateSignaturesButton: React.FC = () => {
-  const [signature1, setSignature1] = useState<string | null>(null);
-  const [signature2, setSignature2] = useState<string | null>(null);
-  const [aggregatedSignature, setAggregatedSignature] = useState<string | null>(
-    null
-  );
-  const [showAggregatedSignature, setShowAggregatedSignature] = useState(false);
-
-  return (
-    <div>
-      <Input
-        id="signature"
-        label="🔏 First Signature"
-        description="Enter the first Signature of the Message."
-        placeholder="8495e11..."
-        onChange={(e) => setSignature1(e.target.value)}
-      />
-      <Input
-        id="signature2"
-        label="🔏 Second Signature"
-        description="Enter the second Signature of the Message."
-        placeholder="a3d1e34..."
-        onChange={(e) => setSignature2(e.target.value)}
-      />
-      <button
-        className={buttonVariants()}
-        onClick={() => {
-          if (signature1 && signature2) {
-            setAggregatedSignature(
-              bufferToHex(bls.aggregateSignatures([signature1, signature2]))
-            );
-            setShowAggregatedSignature(true);
-          }
-        }}
-      >
-        Aggregate Signatures
-      </button>
-
-      {showAggregatedSignature && (
-        <>
-          {aggregatedSignature && (
-            <CodeBlock
-              title="🔏 Aggregated Signature:"
-              lang="bash"
-              allowCopy={true}
-            >
-              <Pre>{aggregatedSignature}</Pre>
-            </CodeBlock>
-          )}
-        </>
-      )}
-    </div>
-  );
-};
-
-export const AggregatePublicKeysButton: React.FC = () => {
-  const [pubKey1, setPubKey1] = useState<string | null>(null);
-  const [pubKey2, setPubKey2] = useState<string | null>(null);
-  const [aggregatedPubKey, setAggregatedPubKey] = useState<string | null>(null);
-  const [showAggregatedPubKey, setShowAggregatedPubKey] = useState(false);
-
-  return (
-    <div>
-      <Input
-        id="pubkey1"
-        label="🔑 First Public Key"
-        description="Enter the first Public Key to aggregate."
-        placeholder="04ae67..."
-        onChange={(e) => setPubKey1(e.target.value)}
-      />
-      <Input
-        id="pubkey2"
-        label="🔑 Second Public Key"
-        description="Enter the second Public Key to aggregate."
-        placeholder="04ae67..."
-        onChange={(e) => setPubKey2(e.target.value)}
-      />
-
-      <button
-        className={buttonVariants()}
-        onClick={() => {
-          if (pubKey1 && pubKey2) {
-            setAggregatedPubKey(
-              bufferToHex(bls.aggregatePublicKeys([pubKey1, pubKey2]))
-            );
-            setShowAggregatedPubKey(true);
-          }
-        }}
-      >
-        Aggregate Public Keys
-      </button>
-
-      {showAggregatedPubKey && (
-        <>
-          {aggregatedPubKey && (
-            <CodeBlock
-              title="🔑 Aggregated Public Key:"
-              lang="bash"
-              allowCopy={true}
-            >
-              <Pre>{aggregatedPubKey}</Pre>
-            </CodeBlock>
-          )}
-        </>
-      )}
-    </div>
-  );
-};
diff --git a/components/theme-switch.tsx b/components/theme-switch.tsx
deleted file mode 100644
index b09609ba..00000000
--- a/components/theme-switch.tsx
+++ /dev/null
@@ -1,40 +0,0 @@
-'use client';
-
-import { cva } from 'class-variance-authority';
-import { Circle } from 'lucide-react';
-import { useState, type ReactNode } from 'react';
-import { cn } from '@/utils/cn';
-
-const itemVariants = cva(
-  'inline-flex items-center gap-2 rounded-md bg-secondary px-4 py-2 text-sm font-medium text-muted-foreground',
-  {
-    variants: {
-      active: {
-        true: 'text-secondary-foreground',
-      },
-    },
-  },
-);
-
-export function ThemeSwitch(props: {
-  children: ReactNode;
-  style: string;
-}): React.ReactElement {
-  const [active, setActive] = useState(false);
-
-  return (
-    <div className="flex flex-row flex-wrap gap-3">
-      <button
-        type="button"
-        className={cn(itemVariants({ active }))}
-        onClick={() => {
-          setActive((prev) => !prev);
-        }}
-      >
-        <Circle className={cn('size-4', active && 'fill-primary')} />
-        {props.children}
-      </button>
-      {active ? <style>{props.style}</style> : null}
-    </div>
-  );
-}
diff --git a/components/themes.js b/components/themes.js
deleted file mode 100644
index e9ef7e50..00000000
--- a/components/themes.js
+++ /dev/null
@@ -1,19 +0,0 @@
-const blueTheme = `:root { --background: 0 0% 100%; --foreground: 222.2 47.4%
-11.2%; --muted: 210 40% 96.1%; --muted-foreground: 215.4 16.3% 46.9%; --popover:
-0 0% 100%; --popover-foreground: 222.2 47.4% 11.2%; --card: 210 40% 98%;
---card-foreground: 222.2 47.4% 11.2%; --border: 214.3 31.8% 91.4%; --input:
-214.3 31.8% 91.4%; --primary: 222.2 47.4% 11.2%; --primary-foreground: 210 40%
-98%; --secondary: 210 40% 96.1%; --secondary-foreground: 222.2 47.4% 11.2%;
---accent: 210 40% 96.1%; --accent-foreground: 222.2 47.4% 11.2%; --destructive:
-0 100% 50%; --destructive-foreground: 210 40% 98%; --ring: 215 20.2% 65.1%; }
-
-.dark { --background: 224 71% 4%; --foreground: 213 31% 91%; --muted: 223 47%
-11%; --muted-foreground: 215.4 16.3% 56.9%; --popover: 224 47.4% 6%;
---popover-foreground: 215 20.2% 65.1%; --card: 216 71% 6%; --card-foreground:
-213 31% 91%; --border: 216 34% 17%; --input: 216 34% 17%; --primary: 210 40%
-98%; --primary-foreground: 222.2 47.4% 1.2%; --secondary: 222.2 47.4% 11.2%;
---secondary-foreground: 210 40% 98%; --accent: 216 34% 14%; --accent-foreground:
-210 40% 98%; --destructive: 0 63% 31%; --destructive-foreground: 210 40% 98%;
---ring: 216 34% 17%; }`;
-
-export { blueTheme };
diff --git a/components/tracker.tsx b/components/tracker.tsx
deleted file mode 100644
index 2f4816cf..00000000
--- a/components/tracker.tsx
+++ /dev/null
@@ -1,81 +0,0 @@
-'use client';
-import { useEffect } from 'react';
-import { usePathname } from 'next/navigation';
-
-const IndexedDBComponent: React.FC = () => {
-  const currentPath = usePathname();
-
-  useEffect(() => {
-    const request = indexedDB.open("PathDatabase", 1);
-
-    request.onerror = function (event: any) {
-      console.error("Database error:", event.target.errorCode);
-    };
-
-    request.onupgradeneeded = function (event: any) {
-      const db = event.target.result as IDBDatabase;
-      const objectStore = db.createObjectStore("paths", { keyPath: "id", autoIncrement: true });
-      objectStore.createIndex("path", "path", { unique: false });
-    };
-
-    request.onsuccess = function (event: any) {
-      const db = event.target.result as IDBDatabase;
-      const transaction = db.transaction(["paths"], "readwrite");
-      const objectStore = transaction.objectStore("paths");
-      const index = objectStore.index("path");
-
-      const getRequest = index.get(currentPath);
-
-      getRequest.onsuccess = function (event: any) {
-        if (event.target.result) {
-          console.log("Path already exists in Academy DB:", currentPath);
-        } else {
-          const addRequest = objectStore.add({ path: currentPath });
-
-          addRequest.onsuccess = function () {
-            console.log("Path has been added to Academy DB:", currentPath);
-          };
-
-          addRequest.onerror = function (event: any) {
-            console.error("Error adding path:", event.target.errorCode);
-          };
-        }
-      };
-
-      getRequest.onerror = function (event: any) {
-        console.error("Error checking path:", event.target.errorCode);
-      };
-
-      const getAllRequest = objectStore.getAll();
-
-      getAllRequest.onsuccess = function (event: any) {
-        const paths = event.target.result as { path: string }[];
-        paths.forEach(item => {
-          const sidebarItem = document.querySelector(`aside a[href="${item.path}"]`);
-          
-          if (sidebarItem) {
-            // Check if a checkmark already exists
-            const existingCheckmark = sidebarItem.querySelector('.lucide-check');
-            
-            // If no checkmark exists, append a new one
-            if (!existingCheckmark) {
-              sidebarItem.innerHTML += `
-                <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="#3752AC" stroke-width="1" stroke-linecap="round" stroke-linejoin="round" class="lucide lucide-check ml-auto shrink-0"><path d="M20 6 9 17l-5-5"></path></svg>
-              `;
-            }
-          }
-          
-        });
-      };
-
-      getAllRequest.onerror = function (event: any) {
-        console.error("Error retrieving all paths:", event.target.errorCode);
-      };
-    };
-  }, [currentPath]);
-
-  return null;
-};
-
-export default IndexedDBComponent;
-
diff --git a/components/ui/button.tsx b/components/ui/button.tsx
deleted file mode 100644
index c330b59f..00000000
--- a/components/ui/button.tsx
+++ /dev/null
@@ -1,29 +0,0 @@
-import { cva } from 'class-variance-authority';
-
-const buttonVariants = cva(
-  'inline-flex items-center justify-center rounded-md text-sm font-medium ring-offset-background transition-colors focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring disabled:pointer-events-none disabled:opacity-50',
-  {
-    variants: {
-      variant: {
-        default: 'bg-primary text-primary-foreground hover:bg-primary/90',
-        outline:
-          'border bg-gradient-to-t from-primary/10 shadow-inner shadow-primary/40 hover:bg-accent hover:text-accent-foreground',
-        secondary:
-          'border bg-secondary text-secondary-foreground hover:bg-secondary/80',
-        ghost: 'hover:bg-accent hover:text-accent-foreground',
-        link: 'text-primary underline-offset-4 hover:underline',
-      },
-      size: {
-        default: 'h-10 px-4 py-2',
-        sm: 'h-9 rounded-md px-3',
-        lg: 'h-11 px-6',
-      },
-    },
-    defaultVariants: {
-      variant: 'default',
-      size: 'default',
-    },
-  },
-);
-
-export { buttonVariants };
diff --git a/components/ui/icon.tsx b/components/ui/icon.tsx
deleted file mode 100644
index e733a9da..00000000
--- a/components/ui/icon.tsx
+++ /dev/null
@@ -1,14 +0,0 @@
-import type { LucideIcon } from 'lucide-react';
-import { TerminalIcon } from 'lucide-react';
-
-export function create({
-  icon: Icon,
-}: {
-  icon?: LucideIcon;
-}): React.ReactElement {
-  return (
-    <div className="rounded-md border p-1 shadow-sm">
-      {Icon ? <Icon /> : <TerminalIcon />}
-    </div>
-  );
-}
diff --git a/components/ui/input.tsx b/components/ui/input.tsx
deleted file mode 100644
index 26b74911..00000000
--- a/components/ui/input.tsx
+++ /dev/null
@@ -1,15 +0,0 @@
-export const Input: React.FC<{id: string, label?: string , description?: string , placeholder?: string , onChange: (e: React.ChangeEvent<HTMLInputElement>) => void }> = ({ id, label, description, placeholder, onChange }) => {
-  return (
-    <div className="mb-8">
-        {label && <label className="block text-sm font-medium">{label}</label>}
-        {description && <p className="text-sm mb-0 mt-1">{description}</p>}
-        <input 
-            type="text" 
-            id="first_name" 
-            placeholder={placeholder}
-            onChange={onChange}
-            className="mt-2 block w-full p-2.5 bg-muted border border-b text-sm rounded-lg focus:ring-[#2a3f85] focus:border-[#2a3f85]  dark:focus:ring-[#2a3f85] dark:focus:border-[#2a3f85]"/>
-    </div>
-
-  )
-}
\ No newline at end of file
diff --git a/components/youtube.tsx b/components/youtube.tsx
deleted file mode 100644
index e132ac55..00000000
--- a/components/youtube.tsx
+++ /dev/null
@@ -1,12 +0,0 @@
-export default function YouTube ({ id } : { id : string }){
-    return (
-      <div>
-        <iframe
-          className="aspect-video w-full"
-          src={"https://www.youtube.com/embed/" + id}
-          title="YouTube Video Player"
-          allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
-        ></iframe>
-      </div>
-    );
-  };
\ No newline at end of file
diff --git a/content/common/avalanche-starter-kit/clean-network.mdx b/content/common/avalanche-starter-kit/clean-network.mdx
deleted file mode 100644
index 107c72e8..00000000
--- a/content/common/avalanche-starter-kit/clean-network.mdx
+++ /dev/null
@@ -1,5 +0,0 @@
-To clean your local Avalanche network and remove all data, run the following command:
-
-```bash
-avalanche network clean
-```
\ No newline at end of file
diff --git a/content/common/avalanche-starter-kit/create-default-blockchain.mdx b/content/common/avalanche-starter-kit/create-default-blockchain.mdx
deleted file mode 100644
index 4f61bcd1..00000000
--- a/content/common/avalanche-starter-kit/create-default-blockchain.mdx
+++ /dev/null
@@ -1,257 +0,0 @@
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-> In the following commands, make sure to substitute the name of your Avalanche L1 for `<name>` (including the `<>`). You can choose whatever name you want, but I recommend using `myblockchain` as the name to avoid the need for some manual configuration.
-
-<Steps>
-<Step>
- 
-### Start Avalanche L1 Configuration
-To create an Avalanche L1 configuration run the following command:
-
-```bash
-avalanche blockchain create <name> --sovereign=false
-```
-
-For example:
-
-```bash
-avalanche blockchain create myblockchain --sovereign=false
-```
- 
-</Step>
-
-<Step>
- 
-### Select Virtual Machine
-You will be prompted a wizard to configure your Avalanche L1. In the first question, select `Subnet-EVM`:
-
-```bash
-? Which Virtual Machine would you like to use?: 
-  ▸ Subnet-EVM
-    Custom VM
-    Explain the difference
-```
- 
-</Step>
-
-<Step>
- 
-### Select Default EVM Configuration
-In the second question, select `I want to use defaults for a test environment`:
-
-```
-? Do you want to use default values for the Blockchain configuration?: 
-  ▸ I want to use defaults for a test environment
-    I want to use defaults for a production environment
-    I don't want to use default values
-    Explain the difference
-```
-
-After the completing the configuration, you should see something like this:
-
-```
-@martineckardt ➜ /workspaces/avalanche-starter-kit (main) $ avalanche blockchain create myblockchain
-✔ Subnet-EVM
-✔ I want to use defaults for a test environment
-Chain ID: 9999
-Token Symbol: TOK
-✔ Token Symbol: TOK
-prefunding address 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC with balance 1000000000000000000000000
-Installing subnet-evm-v0.6.8...
-subnet-evm-v0.6.8 installation successful
-✓ Successfully created blockchain configuration
-```
-
-This command creates the config files `genesis.json` and `sidecar.json` inside: `~/.avalanche-cli/subnets/<name>`. If you want, you can retrieve the current config with the following command:
-
-```bash
-avalanche blockchain describe <name>
-```
-
-</Step>
-
-<Step>
- 
-### To deploy your Avalanche L1, run
-
-```bash
-avalanche blockchain deploy <name>
-```
-
-So in our case:
-
-```bash
-avalanche blockchain deploy myblockchain
-```
-
-When prompted select `Local Network` to deploy on. 
-
-```
-? Choose a network for the operation: 
-  ▸ Local Network
-    Devnet
-    Fuji Testnet
-    Mainnet
-```
-
-After the deployment your should see something like this:
-
-```
-@martineckardt ➜ /workspaces/avalanche-starter-kit (main) $ avalanche blockchain deploy myblockchain
-✔ Local Network
-Deploying [myblockchain] to Local Network
-Backend controller started, pid: 5317, output at: /home/vscode/.avalanche-cli/runs/server_20240808_164902/avalanche-cli-backend.log
-Installing avalanchego-v1.11.10...
-avalanchego-v1.11.10 installation successful
-
-Booting Network. Wait until healthy...
-Node logs directory: /home/vscode/.avalanche-cli/runs/network_20240808_164903/node<i>/logs
-Network ready to use.
-
-Deploying Blockchain. Wait until network acknowledges...
-
-Teleporter Messenger successfully deployed to c-chain (0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf)
-Teleporter Registry successfully deployed to c-chain (0x17aB05351fC94a1a67Bf3f56DdbB941aE6c63E25)
-
-Teleporter Messenger successfully deployed to myblockchain (0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf)
-Teleporter Registry successfully deployed to myblockchain (0x82EeEf8e31D4Bf95916219D7949D66c468Ac0681)
-
-using awm-relayer version (v1.3.3)
-Installing AWM-Relayer v1.3.3
-Executing AWM-Relayer...
-
-Blockchain ready to use
-
-+---------------------------------------------------------------------------------------------------------------+
-|                                                  MYBLOCKCHAIN                                                 |
-+---------------+-----------------------------------------------------------------------------------------------+
-| Name          | myblockchain                                                                                  |
-+---------------+-----------------------------------------------------------------------------------------------+
-| VM ID         | qDNV9vtxZYYNqm7TN1mYBuaaknLdefDbFK8bFmMLTJQJKaWjV                                             |
-+---------------+-----------------------------------------------------------------------------------------------+
-| VM Version    | v0.6.8                                                                                        |
-+---------------+--------------------------+--------------------------------------------------------------------+
-| Local Network | ChainID                  | 9999                                                               |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | SubnetID                 | 26eqgD4Kt1MvTKXC9BDjEwBAfhcBcHCKj2EXjR2UuFpSWoAHhw                 |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | Owners (Threhold=1)      | P-custom18jma8ppw3nhx5r4ap8clazz0dps7rv5u9xde7p                    |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | BlockchainID (CB58)      | 2B7uAsN3XhsjLMrLxbP65QmwiUxyY4Ge5xsReMMPKawABuXW1B                 |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | BlockchainID (HEX)       | 0x9aac23fef6508687ff42bb779b3484a72ced0ac1fb07baefa7d5b6d6fdf9a46e |
-+---------------+--------------------------+--------------------------------------------------------------------+
-
-+-------------------------------------------------------------------------------------------+
-|                                         TELEPORTER                                        |
-+---------------+------------------------------+--------------------------------------------+
-| Local Network | Teleporter Messenger Address | 0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf |
-|               +------------------------------+--------------------------------------------+
-|               | Teleporter Registry Address  | 0x82EeEf8e31D4Bf95916219D7949D66c468Ac0681 |
-+---------------+------------------------------+--------------------------------------------+
-
-+--------------------------+
-|           TOKEN          |
-+--------------+-----------+
-| Token Name   | TOK Token |
-+--------------+-----------+
-| Token Symbol | TOK       |
-+--------------+-----------+
-
-+------------------------------------------------------------------------------------------------------------------------------------------+
-|                                                         INITIAL TOKEN ALLOCATION                                                         |
-+--------------------------+------------------------------------------------------------------+----------------+---------------------------+
-| DESCRIPTION              | ADDRESS AND PRIVATE KEY                                          | AMOUNT (10^18) | AMOUNT (WEI)              |
-+--------------------------+------------------------------------------------------------------+----------------+---------------------------+
-| Main funded account EWOQ | 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC                       | 1000000        | 1000000000000000000000000 |
-|                          | 56289e99c94b6912bfc12adc093c9b51124f0dc54ac7a766b2bc5ccf558d8027 |                |                           |
-+--------------------------+------------------------------------------------------------------+----------------+---------------------------+
-| cli-teleporter-deployer  | 0x9D6D757c9466C2c05aa5e5DDa98e019112a44c59                       | 600            | 600000000000000000000     |
-| Teleporter Deploys       | 86dbf5d3ebd8426f7fac2f83093310da978596290a77eecde31b981bd3089dfd |                |                           |
-+--------------------------+------------------------------------------------------------------+----------------+---------------------------+
-
-+----------------------------------------------------------------------+
-|                      INITIAL PRECOMPILE CONFIGS                      |
-+------------+-----------------+-------------------+-------------------+
-| PRECOMPILE | ADMIN ADDRESSES | MANAGER ADDRESSES | ENABLED ADDRESSES |
-+------------+-----------------+-------------------+-------------------+
-| Warp       | n/a             | n/a               | n/a               |
-+------------+-----------------+-------------------+-------------------+
-
-+---------------------------------------------------------------------------------------------------------------------------------------+
-|                                                         MYBLOCKCHAIN RPC URLS                                                         |
-+-----------+---------------------------------------------------------------------------------------------------------------------------+
-| Localhost | http://127.0.0.1:9650/ext/bc/myblockchain/rpc                                                                             |
-|           +---------------------------------------------------------------------------------------------------------------------------+
-|           | http://127.0.0.1:9650/ext/bc/2B7uAsN3XhsjLMrLxbP65QmwiUxyY4Ge5xsReMMPKawABuXW1B/rpc                                       |
-+-----------+---------------------------------------------------------------------------------------------------------------------------+
-| Codespace | https://humble-tribble-q7qvgwr6j44265v6-9650.app.github.dev/ext/bc/myblockchain/rpc                                       |
-|           +---------------------------------------------------------------------------------------------------------------------------+
-|           | https://humble-tribble-q7qvgwr6j44265v6-9650.app.github.dev/ext/bc/2B7uAsN3XhsjLMrLxbP65QmwiUxyY4Ge5xsReMMPKawABuXW1B/rpc |
-+-----------+---------------------------------------------------------------------------------------------------------------------------+
-
-+----------------------------------------------------------------------------------------------------------------------------------------+
-|                                                                  NODES                                                                 |
-+-------+------------------------------------------+-----------------------+-------------------------------------------------------------+
-| NAME  | NODE ID                                  | LOCALHOST ENDPOINT    | CODESPACE ENDPOINT                                          |
-+-------+------------------------------------------+-----------------------+-------------------------------------------------------------+
-| node1 | NodeID-7Xhw2mDxuDS44j42TCB6U5579esbSt3Lg | http://127.0.0.1:9650 | https://humble-tribble-q7qvgwr6j44265v6-9650.app.github.dev |
-+-------+------------------------------------------+-----------------------+-------------------------------------------------------------+
-| node2 | NodeID-MFrZFVCXPv5iCn6M9K6XduxGTYp891xXZ | http://127.0.0.1:9652 | https://humble-tribble-q7qvgwr6j44265v6-9652.app.github.dev |
-+-------+------------------------------------------+-----------------------+-------------------------------------------------------------+
-| node3 | NodeID-NFBbbJ4qCmNaCzeW7sxErhvWqvEQMnYcN | http://127.0.0.1:9654 | https://humble-tribble-q7qvgwr6j44265v6-9654.app.github.dev |
-+-------+------------------------------------------+-----------------------+-------------------------------------------------------------+
-| node4 | NodeID-GWPcbFJZFfZreETSoWjPimr846mXEKCtu | http://127.0.0.1:9656 | https://humble-tribble-q7qvgwr6j44265v6-9656.app.github.dev |
-+-------+------------------------------------------+-----------------------+-------------------------------------------------------------+
-| node5 | NodeID-P7oB2McjBGgW2NXXWVYjV8JEDFoW9xDE5 | http://127.0.0.1:9658 | https://humble-tribble-q7qvgwr6j44265v6-9658.app.github.dev |
-+-------+------------------------------------------+-----------------------+-------------------------------------------------------------+
-
-+-------------------------------------------------------------------------------------------------------+
-|                                           WALLET CONNECTION                                           |
-+-----------------+-------------------------------------------------------------------------------------+
-| Network RPC URL | https://humble-tribble-q7qvgwr6j44265v6-9650.app.github.dev/ext/bc/myblockchain/rpc |
-|                 | Please make sure to set visibility of port 9650 to public                           |
-+-----------------+-------------------------------------------------------------------------------------+
-| Network Name    | myblockchain                                                                        |
-+-----------------+-------------------------------------------------------------------------------------+
-| Chain ID        | 9999                                                                                |
-+-----------------+-------------------------------------------------------------------------------------+
-| Token Symbol    | TOK                                                                                 |
-+-----------------+-------------------------------------------------------------------------------------+
-| Token Name      | TOK Token                                                                           |
-+-----------------+-------------------------------------------------------------------------------------+
-```
-
-</Step>
-
-<Step>
-
-### Update foundry Configuration (custom blockchain name only)
-
-If you chose a different name then `myblockchain` head to the `foundry.toml` file and add the rpc endpoint:
-
-```toml
-// [!code word:yourblockchainname]
-[rpc_endpoints]
-local-c = "http://localhost:9650/ext/bc/C/rpc"
-myblockchain = "http://localhost:9650/ext/bc/myblockchain/rpc"
-yourblockchainname = "http://localhost:9650/ext/bc/yourblockchainname/rpc" 
-fuji-c = "https://api.avax-test.network/ext/bc/C/rpc"
-
-```
-</Step>
-
-<Step>
- 
-### Make RPC-Endpoint publicly accessible
-
-The final part of the output shows the wallet connection details. You can use these to connect your wallet like Core or Metasmask to you newly created Avalanche L1.
-
-import PublishPort from "@/content/common/codespaces/publish-port.mdx";
-
-<PublishPort />
- 
-</Step>
-
-</Steps>
-
diff --git a/content/common/avalanche-starter-kit/delete-blockchain.mdx b/content/common/avalanche-starter-kit/delete-blockchain.mdx
deleted file mode 100644
index fae2a328..00000000
--- a/content/common/avalanche-starter-kit/delete-blockchain.mdx
+++ /dev/null
@@ -1,5 +0,0 @@
-
-
-```bash
-avalanche subnet delete myblockchain
-```
\ No newline at end of file
diff --git a/content/common/avalanche-starter-kit/foundry-quickstart.mdx b/content/common/avalanche-starter-kit/foundry-quickstart.mdx
deleted file mode 100644
index 7f4ec9bf..00000000
--- a/content/common/avalanche-starter-kit/foundry-quickstart.mdx
+++ /dev/null
@@ -1,150 +0,0 @@
-Foundry serves as a comprehensive toolchain for smart contract development. It handles dependency management, project compilation, testing, deployment, and facilitates interaction with the blockchain through both command-line interface and Solidity scripts. 
-
-In this course we will mainly use three commands:
-
-- **forge create:** Deploying smart contracts
-- **cast send:** Issuing transactions interacting with a smart contract
-- **cast call:** Read-only operations on the blockchain
-
-Let's look at these three in a little more detail for this example contract:
-
-```solidity
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.0;
-
-contract NumberStorage {
- 
-    uint256 num;
-  
-    function getNum() public view returns(uint) {
-        return num; 
-    }
-  
-    function setNum(uint _num) public {
-        num = _num;
-    }
-  
-}
-```
-
-## forge create
-
-This command can be used to deploy smart contracts from a solidity file. The syntax is:
-
-```bash
-forge create [options] contract
-```
-
-An example usage could look something like this:
-
-```
-forge create --rpc-url local-c --private-key $PK src/my-contracts/NumberStorage.sol:NumberStorage 
-```
-
-Let's look at the different parameters:
-
-- **--rpc-url:** The URL of the RPC server that the transaction will be sent to. Every blockchain can have multiple RPC servers. You will learn more about what RPCs are below.
-- **--private-key:** The private key that will be used for signing the transaction for the smart contract deployment
-- **contract:** The path to the contract is in the format `<path>:<contract>`, e.g. src/Contract.sol:Contract. A single solidity file can contain multiple contracts, therefore we have to also specify the contract name and not only the path to the file here.
-
-## cast send
-When we want to sign and publish a transaction we will use cast send. We can either issue simple value transfers or call smart contracts The syntax is:
-
-```bash
-cast send [options] to [sig] [args…]
-```
-
-An example usage could look something like this:
-
-```bash
-cast send --rpc-url local-c --private-key $PK 0x17aB05351fC94a1a67Bf3f56DdbB941aE6c63E25 "setNum(uint)" 42
-```
-
-Let's look at the different parameters:
-- **--rpc-url:** See above
-- **--private-key:** See above
-- **to:** address of an account or a smart contract
-- **sig:** The function signature of a function of the smart contract, e.g. "setNum(uint)"
-- **args:** The arguments of that function (can be multiple or none)
-
-## cast call
-
-Call a read-only function of a smart contract. We do not have to issue a transaction for reading state from the blockchain, since the state won't change. Therefore we don't have to pay for a transaction and don't need a private key. The syntax is:
-
-```bash
-cast call [options] to sig [args…]
-```
-
-An example usage could look something like this:
-
-```bash
-cast call --rpc-url local-c 0x17aB05351fC94a1a67Bf3f56DdbB941aE6c63E25 "getNum()(uint)"
-```
-
-Let's look at the different parameters:
-- **--rpc-url:** See above
-- **--private-key:** See above
-- **to:** address of an account or a smart contract
-- **sig:** The function signature of a function of the smart contract, e.g. "getNum()(uint)". In this example our function does not have any arguments and returns a single value of type uint.
-- **args:** The arguments of that function (can be multiple or none)
-
-
-## Private Key Management with Foundry
-
-We need to pay for the fees of transactions that manipulate the state (deploying a contract, sending tokens or calling a non-view function of a smart contract). The ewoq address is an address where the private key is commonly known:
-
-**Address:** 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-**Private Key:** 56289e99c94b6912bfc12adc093c9b51124f0dc54ac7a766b2bc5ccf558d8027
-
-> Do not send any funds on any public blockchain to the ewoq address. The funds will most likely be lost immediately.
-
-When you create an Avalanche L1 you will be offered an option to configure the initial token allocation. The second option will allocate 1m tokens to that address so you can easily deploy all contracts and pay for the transactions from that address:
-
-```bash
-? How would you like to distribute funds: 
-    Airdrop 1 million tokens to a newly generate address (stored key)
-  ▸ Airdrop 1 million tokens to the default ewoq address (do not use in production)
-    Customize your airdrop
-    Go back to previous step
-```
-
-The private key for the ewoq address is already stored in the environment variable $PK in the Avalanche Starter Kit. Therefore, we can easily access it by using the following flag for the transactions:
-
-```bash
---private-key $PK
-```
-
-This address is obviously not suitable for any production use, since the private key is publicly known. We will look into how we can manage key for the deployment to the Fuji Testnet and the Mainnet later in this course.
-
-
-## RPC URLs
-
-To issue our transactions, we need to send them to an RPC server. You can put the RPC URL directly after the --rpc-url flag. Foundry also allows to configure aliases for the URLs to make it more simple for you to send the transactions in shorter commands.
-
-```bash
---rpc-url local-c
-```
-
-These aliases are defined in the foundry.toml file in the root of the Avalanche Starter Kit.
-
-```toml
-[rpc_endpoints]
-local-c = "http://localhost:9650/ext/bc/C/rpc"
-myblockchain = "http://localhost:9650/ext/bc/myblockchain/rpc"
-fuji-c = "https://api.avax-test.network/ext/bc/C/rpc"
-dispatch = "https://subnets.avax.network/dispatch/testnet/rpc"
-```
-
-The RPC URLs defined by default are the following:
-- **local-c:** The C-Chain of your local Avalanche network
-- **myblockchain:** An Avalanche L1 on your local Avalanche network called myblockchain
-- **fuji-c:** The C-Chain of the Fuji Testnet
-- **dispatch:** An Avalanche L1 on the Fuji Testnet called Dispatch. It was specifically created for testing Avalanche Interchain Messaging dApps. 
-
-The ability to use an RPC with the name of our L1 comes from the alias API in our nodes. You can read more about it [here](https://docs.avax.network/api-reference/admin-api#methods).
-
-Feel free to add more RPC URLs to Avalanche L1s you create. You can also add more aliases for the RPC URLs to make it easier for you to send transactions to them.
-
-## Learn more about Foundry
-
-Foundry has an extensive documentation collected in the [Foundry Book](https://book.getfoundry.sh/).
\ No newline at end of file
diff --git a/content/common/avalanche-starter-kit/networks.mdx b/content/common/avalanche-starter-kit/networks.mdx
deleted file mode 100644
index cf91f504..00000000
--- a/content/common/avalanche-starter-kit/networks.mdx
+++ /dev/null
@@ -1,27 +0,0 @@
-## Networks
-We can deploy an Avalanche L1 to a network of validators. This means we either run these validators on our own or we convince a subset of the existing validators of the Avalanche network to validate our Avalanche L1.
-
-These validators validate the Avalanche L1 according to our rules and will get compensated with transaction fees. A validator can validate as many Avalanche L1s as they like. However, in practice hardware usually limits it to around 5 Avalanche L1s per Validator.
-
-Depending on our use case, we can choose a network to deploy on:
-
-### Mainnet
-
-When our Avalanche L1 goes into production, we want to run it on mainnet. To run a validator on mainnet, we have to stake 2,000 AVAX on each.
-
-### Testnet (Fuji)
-
-When we want to test our Avalanche L1, we can deploy it to the Fuji Testnet. The easiest way to do this is to run a Fuji Node. On Testnet, it only costs 1 AVAX to run a node. That AVAX can be obtained for free from the Testnet Faucet we used in the Avalanche Fundamentals course. All tokens on the Testnet are valueless.
-
-When deploying the Avalanche L1 to Fuji, anyone can interact with it, so long as at least one validator is online. This is great for more intense testing with multiple parties. Further, the Avalanche L1 can interact with other Avalanche L1s deployed in Fuji to test more complex behavior.
-
-
-### Local Network
-
-For our purposes, it is sufficient to run a small local network of 5 nodes on our machine exclusive to us. This has advantages:
-
-- It is very fast to set up
-- We have full control over all tokens of the network and can arbitrarily create testnet tokens for our testing
-- We can work offline, if needed
-
-By selecting “Local Network” during your deployment earlier, you have deployed your first Avalanche L1 on the local network.
\ 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
deleted file mode 100644
index 32d6923e..00000000
--- a/content/common/avalanche-starter-kit/pause-and-resume.mdx
+++ /dev/null
@@ -1,103 +0,0 @@
-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/avalanche-starter-kit/set-up.mdx b/content/common/avalanche-starter-kit/set-up.mdx
deleted file mode 100644
index 92eae0f3..00000000
--- a/content/common/avalanche-starter-kit/set-up.mdx
+++ /dev/null
@@ -1,79 +0,0 @@
-import Link from 'next/link';
-import { cn } from '@/utils/cn';
-import { buttonVariants } from '@/components/ui/button.tsx'
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-The Avalanche Starter Kit contains everything you need to get started quickly with Avalanche. Among other tools it contains Avalanche CLI. With that you can set up a local network, create a Avalanche L1, customize the Avalanche L1/VM configuration, and so on. 
-
-In this course we will run the Avalanche Starter Kit in a hosted environment on Github. This is the most quick way to get started.
-
-<Steps>
-<Step>
-
-### Open the Avalanche Starter Kit Github Repository:
-
-<Link
-    href="https://github.com/ava-labs/avalanche-starter-kit"
-    className={cn(
-    buttonVariants({ variant: 'default', className: 'mt-4' }),
-    )}
-    target='_blank'
->Open Avalanche Starter Kit</Link>
-
-</Step>
-<Step>
-
-### Create a Codespace
-- Click the green **Code** button
-- Switch to the **Codespaces** tab
-- Click **Create Codespace on main** or if you already have a Codespace click the plus (**+**) button
-
-The Codespace will open in a new tab. Wait a few minutes until it's fully built.
-
-</Step>
-<Step>
-
-### Verify everything is working correctly
-
-Open the terminal with `` Ctrl + ` `` or by opening it through the menu:
-
-![](/common-images/avalanche-starter-kit/new-terminal.png)
-
-Now enter avalanche -h to verify everything is working:
-
-```bash
-avalanche -h
-```
-
-As a result you should see the help of Avalanche CLI:
-
-```
-Avalanche-CLI is a command-line tool that gives developers access to
-everything Avalanche. This release specializes in helping developers
-build and test Avalanche L1s.
-
-To get started, look at the documentation for the subcommands or jump right
-in with avalanche blockchain create myNewAvalanche L1.
-
-Usage:
-  avalanche [command]
-
-Available Commands:
-  config                Modify configuration for Avalanche-CLI
-  help                  Help about any command
-  key                   Create and manage testnet signing keys
-```
-
-</Step>
-<Step>
-
-### Optional: Open Codespace locally in Visual Studio Code
-
-You can switch any time from the browser IDE to Visual Studio Code:
-
-![](/course-images/codespaces/open-locally.png)
-
-The first time you switch, you will be asked to install the [Codespaces extension](https://marketplace.visualstudio.com/items?itemName=GitHub.codespaces) and connect VS Code to you GitHub account, if it is not already connceted.
-
-</Step>
-</Steps>
\ No newline at end of file
diff --git a/content/common/codespaces/close-and-reopen-codespace.mdx b/content/common/codespaces/close-and-reopen-codespace.mdx
deleted file mode 100644
index da4870d1..00000000
--- a/content/common/codespaces/close-and-reopen-codespace.mdx
+++ /dev/null
@@ -1,10 +0,0 @@
-## Closing
-
-The codespace time out after 30 minutes of inactivity by default. So if you are not too worried about the 30 hour/month limit, just close the window or the tab. Alternatively, you can open the command prompt (Cmd + Shift + P) and issue the Codespace: Stop Current Codespace.
-
-![](/common-images/codespaces/stop-codespace.png)
-
-## Reopen Codespaces
-You can see your Codespaces on [github.com/codespaces/](https://github.com/codespaces/). There you can stop them, reopen them and delete them.
-
-![](/common-images/codespaces/list-codespaces.png)
\ No newline at end of file
diff --git a/content/common/codespaces/publish-port.mdx b/content/common/codespaces/publish-port.mdx
deleted file mode 100644
index a5499961..00000000
--- a/content/common/codespaces/publish-port.mdx
+++ /dev/null
@@ -1,9 +0,0 @@
-Since the Avalanche Network is running in a Github Codespace the localhost (127.0.0.1) will only be accessible from inside the Codespace. Connecting your wallet using the localhost RPC URL will not work, since your wallet will be running on your computer, and not the local environment where the network is running (the Codespace cloud). 
-
-Therefore, we need to make the RPC-Endpoint publicly accessible. Click on the little antenna icon in the bottom bar of the Codespace:
-
-![](/common-images/codespaces/ports-open.png)
-
-There select the row with the port 9650 and right-click to open the port:
-
-![](/common-images/codespaces/ports-publish.png)
\ No newline at end of file
diff --git a/content/common/core-wallet/add-blockchain-to-wallet.mdx b/content/common/core-wallet/add-blockchain-to-wallet.mdx
deleted file mode 100644
index 38590e25..00000000
--- a/content/common/core-wallet/add-blockchain-to-wallet.mdx
+++ /dev/null
@@ -1,39 +0,0 @@
-In order to add your blockchain to the wallet, you need to have the following information:
-
-- Network RPC URL
-- Network Name
-- Chain ID
-- Network Token Symbol
-- Network Token Name
-
-You can find this information in the output of the `avalanche blockchain deploy myblockchain` command or by issuing the command `avalanche blockchain describe myblockchain`:
-
-```
-+-------------------------------------------------------------------------------------------------------+
-|                                           WALLET CONNECTION                                           |
-+-----------------+-------------------------------------------------------------------------------------+
-| Network RPC URL | https://humble-tribble-q7qvgwr6j44265v6-9650.app.github.dev/ext/bc/myblockchain/rpc |
-|                 | Please make sure to set visibility of port 9650 to public                           |
-+-----------------+-------------------------------------------------------------------------------------+
-| Network Name    | myblockchain                                                                        |
-+-----------------+-------------------------------------------------------------------------------------+
-| Chain ID        | 9999                                                                                |
-+-----------------+-------------------------------------------------------------------------------------+
-| Token Symbol    | TOK                                                                                 |
-+-----------------+-------------------------------------------------------------------------------------+
-| Token Name      | TOK Token                                                                           |
-+-----------------+-------------------------------------------------------------------------------------+
-```
-
-## Open Add Network Screen
-
-Now, open the Core browser extension and navigate to the screen to add a new network.
-
-<Gallery url1="/common-images/core-wallet/go-to-manage-networks.png" url2="/common-images/core-wallet/go-to-add-network.png" />
-
-Now enter the values from the table of our deployed blockchain.
-
-> Make sure you have published the port `9650` in your Codespace.
-
-
-
diff --git a/content/common/core-wallet/create-wallet.mdx b/content/common/core-wallet/create-wallet.mdx
deleted file mode 100644
index 9a99cd92..00000000
--- a/content/common/core-wallet/create-wallet.mdx
+++ /dev/null
@@ -1,3 +0,0 @@
-<Callout type="warn">We recommend using a separate wallet for testing and keeping your actual crypto funds, just to be sure.</Callout>
-
-Follow the steps in Core to create a wallet. Since we will be handling only valueless testnet tokens, we do not need to use cold storage.
\ No newline at end of file
diff --git a/content/common/core-wallet/faucet.mdx b/content/common/core-wallet/faucet.mdx
deleted file mode 100644
index a9d587ec..00000000
--- a/content/common/core-wallet/faucet.mdx
+++ /dev/null
@@ -1,9 +0,0 @@
-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**
-
-If you are not able to claim Testnet Tokens in the faucet, please reach out in the <a
-    href="https://t.me/avalancheacademy"
-    target='_blank' >
-    Avalanche Academy Telegram Chat
-</a>, so our Developer Relations team can send you some Fuji AVAX.
diff --git a/content/common/core-wallet/import-ewoq-account.mdx b/content/common/core-wallet/import-ewoq-account.mdx
deleted file mode 100644
index fa4eb70a..00000000
--- a/content/common/core-wallet/import-ewoq-account.mdx
+++ /dev/null
@@ -1,19 +0,0 @@
-The ewoq address is an address where the private key is commonly known. It makes testing easier, since we can preconfigure the private key and don't have to create a new one every time.
-
-**Address:** 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-
-**Private Key:** 56289e99c94b6912bfc12adc093c9b51124f0dc54ac7a766b2bc5ccf558d8027
-
-> Do not send any funds on any public blockchain to the ewoq address. The funds will most likely be lost immediately.
-
-To add the private key to your core wallet, open the core extension and navigate to the `Account Manager`. Then click the `arrow button` and select `Import Private Key`.
-
-<Gallery url1="/common-images/core-wallet/go-to-account-manager.png" url2="/common-images/core-wallet/go-to-import-private-key.png" />
-
-There enter the private key and click on `Import Private Key`.
-
-<Gallery url1="/common-images/core-wallet/import-account.png" url2="/common-images/core-wallet/account-advanced-options.png" />
-
-You can also change the account name. Click on the three dots, then `View Details` and then `edit` at the top right. 
-
-> We highly recommend setting the name to something like `Do not use` to avoid accidentally using the ewoq account for any real funds.
\ No newline at end of file
diff --git a/content/common/core-wallet/install.mdx b/content/common/core-wallet/install.mdx
deleted file mode 100644
index b97917ee..00000000
--- a/content/common/core-wallet/install.mdx
+++ /dev/null
@@ -1,7 +0,0 @@
-Core extension is compatible with Google Chrome. Head to the chrome web Store and add it to your browser: [**Core Crypto Wallet & NFT Extension**](https://chromewebstore.google.com/detail/core-crypto-wallet-nft-ex/agoakfejjabomempkjlepdflaleeobhb)
-
-<YouTube id="X3sVqXHdhnw" />
-
-After the installation, make sure you pin the extension, since we will use it a lot in the coming courses.
-
-![](/common-images/core-wallet/pin-extension.png)
\ No newline at end of file
diff --git a/content/common/core-wallet/metamask.mdx b/content/common/core-wallet/metamask.mdx
deleted file mode 100644
index 8e4a89f6..00000000
--- a/content/common/core-wallet/metamask.mdx
+++ /dev/null
@@ -1,9 +0,0 @@
-If you've added both Metamask and Core Wallet to your browser, you could face some problems. But to fix them, you don't need to remove Metamask. Just follow the below steps to disable the Metamask extension:
-
-1. Open the extensions page in your browser. You can also type `chrome://extensions/` in your address bar and press enter.
-2. Scroll through your list of installed extensions, or use the search bar at the top of the page, to find the Metamask extension.
-3. Once you find Metamask, you will see a toggle switch next to it. Click on this switch to disable the extension.
-
-When the switch is in the off position, Metamask is disabled, and you should be all set.
-
-![](/course-images/customizing-evm/31.png)
diff --git a/content/common/core-wallet/testnet-mode.mdx b/content/common/core-wallet/testnet-mode.mdx
deleted file mode 100644
index 883c2862..00000000
--- a/content/common/core-wallet/testnet-mode.mdx
+++ /dev/null
@@ -1,5 +0,0 @@
-Since we do not want to play with real funds, we will switch to the Fuji Testnet, an exact replica of the Avalanche's Mainnet architecture with the difference that its tokens are valueless.
-
-To switch to Testnet Mode, open the Core browser extension, click on the burger menu, then Advanced, and finally activate Testnet Mode.
-
-<Gallery url1="/common-images/core-wallet/go-to-menu.png" url2="/common-images/core-wallet/go-to-advanced.png" />
\ No newline at end of file
diff --git a/content/common/cryptography/multi-signature-schemes-demo.mdx b/content/common/cryptography/multi-signature-schemes-demo.mdx
deleted file mode 100644
index 94f7ee2b..00000000
--- a/content/common/cryptography/multi-signature-schemes-demo.mdx
+++ /dev/null
@@ -1,77 +0,0 @@
-import { Steps, Step } from 'fumadocs-ui/components/steps';
-import { GenerateKeysButton, SignMessageButton, VerifySignatureButton, AggregateSignaturesButton, AggregatePublicKeysButton, VerifyAggregateSignatureButton } from '@/components/signatureSchemes'
-
-Let's explore the use of a Multi-Signature Scheme. We'll take the following steps:
-
-- **Generate Two Key Pairs**: We will generate two key pairs.
-- **Sign Message**: We create two Signatures of the same Message with the two Secret Keys.
-- **Aggregate Signatures**: We aggregate the two Signatures to a single Signature.
-- **Aggregate Public Keys**: We aggregate the two Public Keys to a single Public Key.
-- **Verify aggregated Signature**: We verify the Signature with the aggregated Public Key.
-
-<Steps>
-<Step>
-
-### Generate First Key
-Start by generating a Key Pair consisting of a Public and Secret Key.
-
-<GenerateKeysButton />
-
-</Step>
-
-<Step>
-
-### Sign the Messages
-Now use the generated Secret Key to sign a Message.
-
-<SignMessageButton />
-
-</Step>
-<Step>
-
-### Generate Second Key
- In a real-world setting these key pairs would be created by independent actors, but for the sake of the exercise we will play multiple actors here.
-    
-<GenerateKeysButton />
-
-
-</Step>
-<Step>
-
-### Sign the Message with the second Key
-
-Make sure to pick exactly the same Message for both Signatures, e.g. "Per consensum ad astra".
-
-<SignMessageButton />
-
-</Step>
-<Step>
-
-### Aggregate Signatures
-
-We can now utilize the signature aggregation to create an aggregated Signature. In this exercise we are only aggregating two signatures, but we could do this with hundreds or thousands. Side fact: It does not matter in which order the signatures are aggrated.
-
-<AggregateSignaturesButton />
-
-</Step>
-<Step>
-
-### Aggregate Public Keys
-To verify an aggregated Signature, we also need to aggregate the Public Keys that correspond to the Private Keys that were used to sign the message. Analogous to the signatures we can aggregate many more than just two Public Keys and also here the order does not matter.
-
-<AggregatePublicKeysButton />
-
-</Step>
-<Step>
-
-### Verify the Aggregated Signature
-
-Anyone, that has access to the aggregated Public Key can now verify the Signature of the Message. Therefore, the Authenticity, Non-Repudiation and Integrity of the Message can be trusted in an efficient way for a large number of signers.
-
-<VerifySignatureButton aggregated={true} />
-
-</Step>
-</Steps>
-
-Congrats on going through the exercise and experiencing hands-on how we can utilize Signature Aggregation. You will see in the next chapter about Avalanche Warp Messaging; how Mutli-Signature schemes can enable secure and efficient cross-L1 communication.
-
diff --git a/content/common/cryptography/multi-signature-schemes.mdx b/content/common/cryptography/multi-signature-schemes.mdx
deleted file mode 100644
index 2ef61db6..00000000
--- a/content/common/cryptography/multi-signature-schemes.mdx
+++ /dev/null
@@ -1,16 +0,0 @@
-Multi-signature schemes, also known as multi-sigs, are cryptographic methods enabling multiple parties to collectively authorize a specific action or operation, typically by requiring a predefined number of authorized participants to provide their digital signatures. In a multi-signature scheme, each authorized party possesses their own private key, and to validate the action. A specified subset of these parties must produce their unique signatures.
-
-![](/common-images/cryptography/multi-signature-schemes.png)
-
-This is useful in scenarios where a group of participants want to collectively sign a message, but only a subset of them are needed to do so.
-
-Multi-signature schemes enhance security by reducing the reliance on a single entity, mitigating risks associated with compromised keys, and enabling shared control over various cryptographic processes. These schemes find applications in a wide range of cryptographic and security contexts, where they help ensure trust, distribute control, and minimize the impact of potential vulnerabilities.
-
-## BLS  Multi-Signature Scheme
-
-The [BLS (Boneh-Lynn-Shacham) multi-signature scheme](https://iacr.org/archive/asiacrypt2001/22480516.pdf) is notable for its compact size, making it a highly efficient for blockchain application. Furthermore, it supports signature and public key aggregation.  
-
-- Signature aggregation compresses all signatures into a single short signature, which makes the transportation and verification much more efficient.
-- Public Key aggregation allows the verification algorithm to only use a short aggregated public key. 
-
-The BLS multi-signature scheme has applications in various cryptographic protocols, such as secure multi-party computation, distributed key generation, threshold decryption, and more. They are particularly useful in decentralized systems like blockchain networks, where multiple parties may need to collaboratively sign messages or perform other cryptographic operations.
\ No newline at end of file
diff --git a/content/common/cryptography/signature-key-aggregation.mdx b/content/common/cryptography/signature-key-aggregation.mdx
deleted file mode 100644
index 74914b8f..00000000
--- a/content/common/cryptography/signature-key-aggregation.mdx
+++ /dev/null
@@ -1,29 +0,0 @@
-Signature and public key aggregation combines multiple signatures of the same message into a single short signature, which makes transportation and verification much more efficient.
-
-Let's look at an example. We want to sign the following message:
-
-```bash title="Message"
-Per consensum ad astra
-```
-
-Using a private key we create the following signature:
-
-```bash
-a9c400aaf55071eedd5d151932d5cfe847ab3a5ad544521f9a3810ebb59b27c9913c86449405d3dff86c54fcc62ec48a19b182c7c87008619e88e281048f7c58b5c2cb07a1dfcf1a0e43a3678fb9efa04c218140fe5ec02d92c8eb9fbbdf312b
-```
-
-Looks good so far, but let's now think about a message signed by a large portion of the Primary Network validators on Avalanche Mainnet. That would result in hundreds if not thousands of signatures attached to a small message.
-
-- Short message = 64 bytes
-- 1 Signature = 96 Bytes
-- 1000 signatures = 96,000 Bytes
-
-This large data size would quickly become a bottleneck in the transport of the message. However, we can use the Signature Aggregation feature of BLS Multi-Signatures:
-
-![](/common-images/cryptography/signature-aggregation.png)
-
-This more compact aggregated signature makes it much easier to send the message to a large group of validators on the destination chain to verify the authenticity of messages.
-
-We must do the same for the public keys of the signers. In our verify method we input the aggregated public key with the aggregated signature. Let's try this in the next activity.
-
-![](/common-images/cryptography/multi-signature-schemes-methods.png)
\ No newline at end of file
diff --git a/content/common/cryptography/signature-schemes-demo.mdx b/content/common/cryptography/signature-schemes-demo.mdx
deleted file mode 100644
index afd58fb6..00000000
--- a/content/common/cryptography/signature-schemes-demo.mdx
+++ /dev/null
@@ -1,37 +0,0 @@
-import { GenerateKeysButton, SignMessageButton, VerifySignatureButton } from '@/components/signatureSchemes'
-import { Steps, Step } from 'fumadocs-ui/components/steps'
-
-Let's get our hands dirty and use a signature scheme. We'll take the following steps:
-
-- **Generate Key Pair**: We will generate a key pair consisting of a Public and a Secret Key.
-- **Sign Message**: We create a Signature by signing the Message with the Secret Key.
-- **Verify Signature**: We verify the Signature of a Message with the Public Key.
-
-<Steps>
-<Step>
-
-### Generate Keys
-Start by generating a Key Pair consisting of a Public and a Secret Key.
-
-<GenerateKeysButton />
-
-</Step>
-<Step>
-
-### Sign a Message
-
-Now use the generated Secret Key to sign a Message. Pick any message you want to sign, e.g. "Per consensum ad astra".
-
-<SignMessageButton />
-
-</Step>
-<Step>
-
-### Verify the Signature
-
-Anyone, that has access to your Public Key corresponding to the Private Key used for signing the message can now verify the signature of the Message. Therefore, the Authenticity, Non-Repudiation and Integrity of the Message can be trusted.
-
-<VerifySignatureButton />
-
-</Step>
-</Steps>
\ No newline at end of file
diff --git a/content/common/cryptography/signature-schemes.mdx b/content/common/cryptography/signature-schemes.mdx
deleted file mode 100644
index a101dc68..00000000
--- a/content/common/cryptography/signature-schemes.mdx
+++ /dev/null
@@ -1,66 +0,0 @@
-import { buttonVariants } from '@/components/ui/button';
-import { cn } from '@/utils/cn';
-
-Signature schemes are cryptographic schemes, that allow us to sign some piece of data, and someone else can verify our signature. Think of signature schemes as a very modern version of signing for example a contract, which does not rely on your unique hand movement, but on math. There are many different signature schemes. They vary in efficiency and security. 
-
-The main goal of signature schemes is to ensure the authenticity, non-repudiation, and integrity of digital messages.
-
-- **Authenticity:** Authenticity ensures that the signature authenticates the origin of the message and verifies that it was indeed created by the claimed sender. A valid signature on a message proves that the signer owns the private key associated with the public key used for the signature.
-
-- **Non-Repudiation:** Non-repudiation ensures that the signer cannot deny their involvement in the transaction. In other words, they cannot later claim that they didn't authorize or sign the message. Therefore, signing the message is a binding commitment.
-
-- **Integrity:** Integrity ensures that the message has not been tampered with or modified during transmission. Validating a changed message, no matter how small the difference, with the signature will not be successful. 
-
-## Public and Private Key
-
-These signatures are generated using a private key known only to the sender. They can be verified by anyone who possesses the corresponding public key associated with the sender. This dual-key structure, consisting of a private key for signing and a public key for verification, forms the basis of asymmetric or public-key cryptography.
-
-## Methods of Signature Schemes:
-
-Signature schemes consist of three methods:
-
-![](/common-images/cryptography/signature-scheme-methods.png)
-
-- **Generate Key Pair() => Private Key, Public Key:** This algorithm is used to generate a pair of keys for the user. One key is the private key, which is kept secret, and the other is the public key, which is made available to others. The private key is used for signing messages, while the public key is used to verify the signatures. 
-- **Sign(Message, Private Key) => Signature:** This algorithm is used by the owner of the private key to create a digital signature for a message. The signature is generated based on the private key and the content of the message. The signature is typically appended to the message before transmission.
-- **Verify(Message, Signature, Public Key) => Valid/Invalid:** This algorithm is used to verify the authenticity of a received message with the public key of the sender and its associated signature. The result is that the signature is either valid or invalid for the given private key.
-
-In some signature schemes, there may also be a "recover" algorithm:
-
-- **Recover(Message, Signature) => Public Key:** This algorithm can be used to recover the public key corresponding to the private key that has been used to create the signature for a message.
-
-The signature can be verified by comparing the public key returned by the recover algorithm with the public key of the message's sender. If there is an exact match, the signature is valid.
-
-In the following activity, you can interact with a signature scheme to learn more.
-
-## Formats of Keys and Signatures
-
-Using these methods we can create keys and signatures. But what does that mean? At the end of the day, signatures and keys are just (very long) series of bits (0 and 1s) that can be interpreted as numbers and represented as [hexadecimal strings](https://www.youtube.com/watch?v=WGN4NWICTpQ).
-
-```bash title="Example Private Key"
-0c29dd3d37fc2f1f26609d4088023b25618cdded6fc7b4eb75d75898aba2cd3a
-```
-
-```bash title="Example Public Key"
-b470edf87dc8decad6a39ed105a6a6411b88275c6a0ac06c0dea3144980eaf0635fabda79ceda360583acd0802adb27e
-```
-
-```bash title="Example Signature"
-8efb19ca904a1d061a84070d5bad61ce1ea44d0e1d9c0a2ecced89692a5546ea39bb02ff1563186767d0903901d5304c126c2ad97dc2efe97c2d528039aff266e9337646498e90b089a4ebfa624e2f353aceca545b7f14b7c2707f3340bd6827
-```
-
-## Interactive Demo
-
-Before you start, understand the inputs (blue), the algorithms (red), and outputs (green). Follow the lines to see how they are connected. Then follow these steps:
-
-- Generate a new Key Pair and check out Private Key and the Public Key / Address.
-- Sign a message and view the signature. See that the signature is valid.
-- Change the message and see what values change and if the signature is valid.
-
-<a
-    href="https://sandbox.eth.build/wofCrGxhc3Rfbm9kZV9pZMONASvEgcSDxIVsaW5rxItkw4zDusKlxIfEiXPCnMKLwqLEjMOMw73CpHR5cGXCrElucHV0L0LEr3RvbsKjcG9zwpI8w4zCoMKkc2l6ZcKSw4zDpFTCpWbEgmdzwoHCqWNvbMSCcHNlZMOCwqVvcsSJcgHCpG3EiGUAwqbElcSudHPCkcKDwqRuYW1lxL7Ep8Spw7_CpMSUxJbDgMKnb8SvxaXEusWpxavFrcWvxKhlw7_CpcW0a8Wnw4zDmsW8xazFrsSmxoDCrm51bWJlcixib8WQZWFuxoPElcaFw4DCqnByb8SpcnRpZXPCg8KldmFsdWXCtUdlbsaTYXRlIE5ldyBLZXkgUGFpcsKlxqZ0bGXCpsSydMS0xpvFj3VudB3CpXNoYcSpBMKKxKLEmcO8xozEqcKvQ3LEqMS0L8a-x4DHgseExLfEucKSxI5exL3Ev8WBZcKCwqEwxI4VwqExS8WIxYpzwoDFmMWaxpMDxZ7FoMWixaTEr8W7xarGisKtW8ahacasxrcga8a_Xcefx4rEhHLElWfFs8adw4DGicWtwqhnxrPGtca3yJbFssaExofFt8W5yIjCk8ifZcKryI7IkMa4yJN5yJbCpsiYyJrGnMSWxLrDjMOuw4zDtciuxqB1YsSUY8iSxr_Itsi4bmfIusaFwpDIrsKnYWRkcsaoc8mJdMiZyYvJjci8w6_DjMOyxqDGosakxqbGqMKByaHIj8a2Zcenw5lCMHg4Nzg0ZTgwZjJhODVmZGIzYjA0Y2NiZDI5NTEyMGUwYzcyZTJjOTQ3NTgyxpLKgDPJtMqXyoIxNTlkN2XKomM4x5vEjMSOFMiWwrBEaXNwxIJ5L1RleHRByZVhx6vEusONAsK8UMexxYLHrQFcyYzFiWHFi8e_xZnFmwXIhMSJyIbErciIxajIisW-yZjJmsibyKjDtciqdMW6y5bFvcaLxbDIl8mZyLnGhHPGn8ahxqPGk8mkxYzHhmnHiMivUMiZyLLGvca_yqrEjQEHyJbCrseix6RvL1JlxY92xpPKvsuGfMuAwrzLhMezx7XDikMhMzPHuS7HvMuLx77IgMWbCMuRxaHFo8uUxabCksiuwqlbxa1zc8uLZciVy6TIt8umyYvInMSWw4zDqciuwqtbxYBnxat0dcmVzKvGgMyty5rMsGvEmsuey6DJkMmSyZTJlsuZy6fGnci8w6fDjMOzyaHLrMalxqdzwoLCp8ymzKjIosK2VGjKsSDNnmEgzZjMqSDGt8SEwqnMt8y5zLtlwoDLucSOD8iWxKvMoMSxxLPEtcyIMsuATsyNxYTDnVzMl8WLxY3Fj8WRx5jFlMWWzJrGkwDMncuTzYXLl8ujxoDIp8idzYTIiMyizo3Fv8WxyZzCkcOMw6zIrs6WZcaOxpDGksaUxpbGmMaayZzLqsmiy63NlMaqxqzGrsSqU2nMuCBNyZbMqcuwy7LHi821x4_FuMeSEM2uARXKrsqwyrLKtMq2yrjKusq8zIjMi8SOw4LNu8SOy4jNv8yZy47Gk8u8xZ_LksyfzozLos6dzL_Ims2Bw4zDts6SxabLocaKz5rJismMy6jOmcO6zZHJo82UwoHOtseJwqnOr8y4xrbNq86-AsiWwq_PgsqzYcq1QcmTyZXMp8-JAsOGxI4Oz40BVk_PkMuNyIFyBs6Kz5fLlc6cyJbOiciow6_PrmXCqlDJg8mFy7d5z6rOqcaowoTCq8mEb2NrxqfOr8WCMsiwxIJjZWjFkMWbwqDQl8Kp0JrJhGnJhsa-xqvGrcavw5kqya4zybg5ZTkxOWNmyplk0Yg4ZDUwMsmzMWUxMGE1yb8wMzU10YRlNGZiwonHnMSOC8-3z7nPhM-9zYjQgMS4yr_LgcuAwqjQhkBQ0IrOh3IJ0I_Ih8-h0JLLpNCUxp3DjMOn0J_Nk9Ch0KNs0KXQp2XQqcqS0Kxh0K7QsGzQstCXwqfRqs-_c9C7zq3QvtGA0YLRhNGG0Ywy0YvRidGO0ZDRktGU0ZbRmMqc0ZzRntGgYs6-EsiWwrFDxLXJmcWQL9KxbmTLsWnNttGtx60CYsONA1zMjce0MMOMx7QxzJbLisuM0bYK0bnMoMiJy6LCoUHIlsKtz6Usxo_GkcaTz53DssiuwqFC05TTltOYzqHPncOzz6DTkMaKxKZyxq_IlsKnzqPHic6lz6fDjMO0yK7CpWXMhseSyKbOptKCy67Cg9OS0pl4N2HRmtGHODbEicqY0YfKjMm8yqPKhcqHZtGFZDNhNmU2NDHKqMmTN9Oe0780MtGJYsqCybY2MTbJu8qP0Y02YtSqMNStYmPJudSlNmFlxpnKlMqXwqJPUMKiPT3EocqrARPTlNGoz7svV8a2Y2jPiQMC04BS0IYXR9G1z5Jy0abPlcye0brFp8KEzpXQk8-dw7TGg2HGkmzCoNOmwpHVm8-Z0JPOptWg1aLQs8eHx4nCpVbGrcSM07vPrNCXwq_Psc2qyZUg1bHElGTUv8u6yIPLpMKry79wx6XVuM-JAWjEjsKQ04PHtcOMw63HuXbVk9CMBNOOxbrClMiuwqzIjcu1yanItMy9xKnPm8yvyKjDrsmB1ptvdsSMxpPWn8ulzYDGhMiezo3MpM2jyKLWq9ahy5vRv8OhyK7Hscy4yKbPncOs06bWmM6NyZHPvs2JzKzPpc6myZDWsmXNismby6jWr8uizajOsNW514rXhcyuz6bNjM6Zw7bIrsi315HFldO5143Ql8Ks1bjOss60yKLVtMaowoXNl9ekZc2bzZ1zzZ_Xrs2h14nNpcaodMmnyLLJq8mteDYyyp3Rj2YzOMqFNzfUj8mw1Jg4MWRm0Yk20Zo2M9SUYsqZyqjUmDY3NDNkyozYgdiP1KQy0ZxkONGF2KI21IXCqMur1qjFm8K6aMeNxZM6Ly9hdcSEyJrImdiLy7FoLsWPbdeQz7LMusmVw4DCqNiyxLTVuMOCzr7WlcukwqrErMWlz4XKucyIKMSOwqTNu8SkNNaTxZvPttWXzovQkdWc0b3NgcW2xbjLn9mb1ajXlMuayZzFhMOhzLLXpnPQotCk0KbQqMey0KvPutKO0LHGk8KvxrPGt3LXs8q5IGjGk2XSks6zzKfOtc6sxq_XrM2ezaDNoteq17PEhMmcwp3ClsaHxKQAw4zDvAHDv9qPw6HEjgQAxI7VjNa12o_Dp8SOB9qbAQsAANqPw6namdqj2qLans6aza_aowMD2pbIvdqT2rDFos-l2o_JnsO81Y0BAtqm2o_DstqT2rwSANOV15XTl86gxpPaj8Oz2qHaoxIB24bLmtuI05ly2o_DtMSO24TEjhPav8i_2rXKrNq315Xaj8O22pzavBXboMua2o_Duse32qsB1rXCpmfGonXFk8KQwqbFj25mzrDCgMKnzIZyxYDEtcOLP8OZwpncg9yDwpo"
-    target='_blank'
-    className={cn(buttonVariants({ size: 'lg' }))}
->
-    Open the Demo
-</a>
diff --git a/content/common/evm-precompiles/allowlist.mdx b/content/common/evm-precompiles/allowlist.mdx
deleted file mode 100644
index 46188153..00000000
--- a/content/common/evm-precompiles/allowlist.mdx
+++ /dev/null
@@ -1,50 +0,0 @@
-The AllowList allows a precompile to enforce permissions on addresses. The AllowList is not a contract itself, but a helper structure providing a control mechanism for wrapping contracts. It provides an AllowListConfig to the precompile so that it can take an initial configuration from genesis/upgrade.
-
-Precompiles using an Allow List have two roles: Admin, Manager and Enabled. For each role, a list of addresses can be defined.  
-
-![](/common-images/evm-precompiles/allowlist-roles.png)
-
-- Enabled addresses can perform the permissioned behavior (issuing transactions, deploying contracts, etc.), but cannot modify other roles.
-- Manager addresses can use the precompile, and can change enabled addresses
-- Admin addresses have the same rights, but can also add/remove other Admin, Manager and Enabled addresses.
-
-These addresses are not necessarily owned by a single entity, but can also be managed by a multi-sig or DAO.
-
-AllowList adds adminAddresses and enabledAddresses fields to precompile contract configurations. For instance, txAllowList precompile contract configuration looks like this:
-
-```json
-"txAllowListConfig": {
-  "blockTimestamp": 0,
-  "adminAddresses": ["0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC","0x0000...", "... and more"],
-  "enabledAddresses": ["... and even more"]
-}
-```
-
-AllowList configuration affects only the related precompile. For instance, the admin address in txAllowList does not affect admin addresses in other activated precompiles.
-
-## Interacting with the AllowList from Solidity
-
-The AllowList Solidity interface is defined below. AllowList is not an actual contract but just an interface. It's not callable by itself. This is used by other precompiles.
-
-```solidity
-pragma solidity ^0.8.0;
-
-interface IAllowList {
-  // Set [addr] to have the admin role over the precompile contract.
-  function setAdmin(address addr) external;
-  
-  // Set [addr] to be enabled on the precompile contract.
-  function setEnabled(address addr) external;
-
-  // Set [addr] to have the manager role over the precompile contract.
-  function setManager(address addr) external;
-
-  // Set [addr] to have no role for the precompile contract.
-  function setNone(address addr) external;
-  
-  // Read the status of [addr].
-  function readAllowList(address addr) external view returns (uint256 role);
-}
-```
-
-`readAllowList(addr)` will return a `uint256` with a value of `0`, `1`, `2` or `3`, corresponding to the roles None, Enabled, Admin and Manager respectively.
\ No newline at end of file
diff --git a/content/common/evm-precompiles/contract-deployer-allowlist.mdx b/content/common/evm-precompiles/contract-deployer-allowlist.mdx
deleted file mode 100644
index d07636ea..00000000
--- a/content/common/evm-precompiles/contract-deployer-allowlist.mdx
+++ /dev/null
@@ -1,7 +0,0 @@
-The Contract Deployer Allowlist allows an Avalanche L1 to restrict who can deploy smart contracts to the chain. This is useful for preventing unwanted behavior. If an address is not on the allowlist, the chain will reject any contract deployment from that address.
-
-> This is different than the Transaction Allowlist. The Transaction Allowlist restricts who can issue transactions to the chain, while the Contract Deployer Allowlist restricts who can deploy smart contracts to the chain.
-
-This can be used to implement a permissioned chain, where only certain addresses are allowed to deploy smart contracts. This can be useful for enterprise use cases, where only certain entities are allowed to deploy smart contracts or usecases that require every service provider to go through a KYB-process before offering services on the blockchain.
-
-This also allows for an Avalanche L1 to make sure that no other blockchain application just deploys on the L1 and it can be exclusively for a specific use case.
\ No newline at end of file
diff --git a/content/common/evm-precompiles/native-minter.mdx b/content/common/evm-precompiles/native-minter.mdx
deleted file mode 100644
index 9594112d..00000000
--- a/content/common/evm-precompiles/native-minter.mdx
+++ /dev/null
@@ -1,60 +0,0 @@
-
-The Native Minter Precompile allows for fine-grained permissioning which address can mint more native tokens. There can be rich permissioning structures around precompiles with three roles. 
-
-![](/common-images/evm-precompiles/allowlist-roles.png)
-
-These addresses are not necessarily owned by a single entity, but can also be managed by a multi-sig or DAO.
-
-## Initial permissions
-
-If the native minter precompile is activated, the initial addresses can be set in genesis.
-
-```json
-{
-  "config": {
-    "contractNativeMinterConfig": {
-      "blockTimestamp": 0,
-      "adminAddresses": ["0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC"]
-    }
-  }
-}
-```
-
-If only an enabled address is set, only that address can mint native tokens. Allowing another address to mint native tokens would require a network upgrade.
-
-## Interacting with the NativeMinter from Solidity
-
-The Stateful Precompile contract powering the ContractNativeMinter adheres to the following Solidity interface at `0x0200000000000000000000000000000000000001`:
-
-```solidity title="Native Minter"
-//SPDX-License-Identifier: MIT
-pragma solidity ^0.8.0;
-
-interface INativeMinter is IAllowList {
-  event NativeCoinMinted(address indexed sender, address indexed recipient, uint256 amount);
-
-  // Mint [amount] number of native coins and send to [addr]
-  function mintNativeCoin(address addr, uint256 amount) external;
-}
-
-interface IAllowList {
-  event RoleSet(uint256 indexed role, address indexed account, address indexed sender, uint256 oldRole);
-
-  // Enabled addresses can mint native tokens
-  function setEnabled(address addr) external;  
-
-  // Admins can mint native tokens and enable/disable addresses
-  function setManager(address addr) external;
-  
-  // Admins can mint native tokens and enable/disable addresses and give/revoke manager and admin rights
-  function setAdmin(address addr) external;
-
-  // Revoke the role from that address
-  function setNone(address addr) external;
-
-  // Read the status of [addr].
-  function readAllowList(address addr) external view returns (uint256 role);
-}
-```
-
-mintNativeCoin takes an address and amount of native coins to be minted. The amount denotes the amount in minimum denomination of native coins (10^18). For example, if you want to mint 1 native coin (in AVAX), you need to pass 1 * 10^18 as the amount. A NativeCoinMinted event is emitted with the sender, recipient and amount when a native coin is minted.
\ No newline at end of file
diff --git a/content/common/evm-precompiles/precompiles.mdx b/content/common/evm-precompiles/precompiles.mdx
deleted file mode 100644
index f7df77c7..00000000
--- a/content/common/evm-precompiles/precompiles.mdx
+++ /dev/null
@@ -1,32 +0,0 @@
-Precompiled contracts are a way to execute code written in the low-level coding language Go from the EVM. Go is much faster and more efficient than Solidity.
-
-If you are familiar with Python programming, you might be familiar with a similar concept. Many Python functions and libraries are written in the programming language C, since it is much more efficient than Python. Python developers can import these precompile modules and call these functions just as if they were written in Python. The only difference is that the modules are faster and more efficient.
-
-![Precompiles](/common-images/evm-precompiles/precompiles.png)
-
-Precompiles can be called from a Solidity smart contract in the same way, as if they were another contract written in Solidity. The EVM keeps a list of addresses reserved and mapped to the precompiles. When a smart contract calls a function of a contract with an address on that list, the EVM executes the precompile written in Go instead of the smart contract.
-For instance, if we mapped the address 0x030...01 to the SHA256 precompile that hashes its input using the SHA256 Hash Function, we can call the Precompile like this:
-
-```solidity
-// SPDX-License-Identifier: MIT
-
-pragma solidity >=0.8.0;
-
-interface ISHA256 {
-
-  	// Computes the SHA256 hash of value
-	function hashWithSHA256(string memory value) external view returns(bytes32 hash);
-  
-}
-
-contract MyContract {
-    
-    ISHA256 mySHA256Precompile = ISHA256(0x0300000000000000000000000000000000000001);
-
-    function doSomething() public {
-        bytes32 hash = mySHA256Precompile.hashWithSHA256("test");
-    }
-}
-```
-
-In the code above we are calling the precompile with the address we are defining the interface of our SHA256 precompile and calling it in our contract MyContract. Note that there is no implementation of the precompile in solidity itself. This will only work if we implemented this precompile in Go and registered at the address `0x030...01`. 
\ No newline at end of file
diff --git a/content/common/evm-precompiles/transaction-allowlist.mdx b/content/common/evm-precompiles/transaction-allowlist.mdx
deleted file mode 100644
index 08ef02f3..00000000
--- a/content/common/evm-precompiles/transaction-allowlist.mdx
+++ /dev/null
@@ -1,3 +0,0 @@
-The Transaction Allowlist allows an Avalanche L1 to restrict who can issue transactions to the chain. This is useful for preventing unwanted behavior. If an address is not on the allowlist, the chain will reject any transactions from that address.
-
-This can be used to implement a permissioned chain, where only certain addresses are allowed to interact with the chain. This can be useful for enterprise use cases, where only certain entities are allowed to interact with the chain or usecases that require every user to go through a KYC-process.
\ No newline at end of file
diff --git a/content/common/intro/course-chat.mdx b/content/common/intro/course-chat.mdx
deleted file mode 100644
index 76c782a4..00000000
--- a/content/common/intro/course-chat.mdx
+++ /dev/null
@@ -1,16 +0,0 @@
-import { buttonVariants } from '@/components/ui/button';
-import { cn } from '@/utils/cn';
-
-## Engage with fellow learners and the DevRel Team
-
-Are you finding the learning material interesting? Have a question? Want to share an idea?
-
-Join our Avalanche Academy Telegram community and connect with your fellow learners!
-
-<a
-    href="https://t.me/avalancheacademy"
-    target='_blank'
-    className={cn(buttonVariants({ size: 'lg' }))}
->
-    Join Telegram Course Chat
-</a>
\ No newline at end of file
diff --git a/content/common/intro/instructors.mdx b/content/common/intro/instructors.mdx
deleted file mode 100644
index 1dbb1d1c..00000000
--- a/content/common/intro/instructors.mdx
+++ /dev/null
@@ -1,43 +0,0 @@
-import instructors from '@/content/common/intro/instructors.tsx'
-
-Meet your instructors, the Developer Relations team at Ava Labs, who are passionate about bringing the power of Avalanche to your fingertips. With their deep understanding of blockchain technology and a passion for simplifying complex concepts, they're here to provide you with a comprehensive and engaging learning experience.
-
-<div class="grid gap-8 mb-6 lg:mb-16 md:grid-cols-3">
-    { instructors.map(instructor => 
-        <div key={instructor.name} class="p-5 bg-gray-50 rounded-lg shadow flex flex-col dark:bg-gray-800 dark:border-gray-700">
-            <a href={instructor.twitter} target='_blank' >
-                <img className="w-full aspect-square rounded-lg m-0" width={100} height={100} src={`/common-images/intro/instructors/${instructor.name.toLowerCase().replaceAll(" ", "-")}.jpeg`} alt="" />
-            </a>
-
-                <h3 class="text-l font-bold tracking-tight">
-                    <a href="#">{instructor.name}</a>
-                </h3>
-                <p class="text-sm text-gray-500 dark:text-gray-400 mb-4 flex-grow">{instructor.title}</p>
-                {/*<p class="mt-3 mb-4 font-light text-gray-500 dark:text-gray-400">TBD</p>*/}
-                <div class="flex space-x-4 sm:mt-0">
-                    <a href={instructor.twitter} target='_blank' class="text-gray-500 hover:text-gray-900 dark:hover:text-white">
-                        <svg class="w-5 h-5" fill="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path d="M8.29 20.251c7.547 0 11.675-6.253 11.675-11.675 0-.178 0-.355-.012-.53A8.348 8.348 0 0022 5.92a8.19 8.19 0 01-2.357.646 4.118 4.118 0 001.804-2.27 8.224 8.224 0 01-2.605.996 4.107 4.107 0 00-6.993 3.743 11.65 11.65 0 01-8.457-4.287 4.106 4.106 0 001.27 5.477A4.072 4.072 0 012.8 9.713v.052a4.105 4.105 0 003.292 4.022 4.095 4.095 0 01-1.853.07 4.108 4.108 0 003.834 2.85A8.233 8.233 0 012 18.407a11.616 11.616 0 006.29 1.84" /></svg>
-                    </a>
-
-                    <a href={instructor.linkedin} target='_blank' class="text-gray-500 hover:text-gray-900 dark:hover:text-white">
-
-                        <svg class="w-5 h-5" fill="currentColor" viewBox="0 0 30 30">
-                            <path d="M24,4H6C4.895,4,4,4.895,4,6v18c0,1.105,0.895,2,2,2h18c1.105,0,2-0.895,2-2V6C26,4.895,25.105,4,24,4z M10.954,22h-2.95 v-9.492h2.95V22z M9.449,11.151c-0.951,0-1.72-0.771-1.72-1.72c0-0.949,0.77-1.719,1.72-1.719c0.948,0,1.719,0.771,1.719,1.719 C11.168,10.38,10.397,11.151,9.449,11.151z M22.004,22h-2.948v-4.616c0-1.101-0.02-2.517-1.533-2.517 c-1.535,0-1.771,1.199-1.771,2.437V22h-2.948v-9.492h2.83v1.297h0.04c0.394-0.746,1.356-1.533,2.791-1.533 c2.987,0,3.539,1.966,3.539,4.522V22z"></path>
-                        </svg>
-                    </a>
-
-                    <a href={instructor.github} target='_blank' class="text-gray-500 hover:text-gray-900 dark:hover:text-white">
-                        <svg class="w-5 h-5" fill="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path fill-rule="evenodd" d="M12 2C6.477 2 2 6.484 2 12.017c0 4.425 2.865 8.18 6.839 9.504.5.092.682-.217.682-.483 0-.237-.008-.868-.013-1.703-2.782.605-3.369-1.343-3.369-1.343-.454-1.158-1.11-1.466-1.11-1.466-.908-.62.069-.608.069-.608 1.003.07 1.531 1.032 1.531 1.032.892 1.53 2.341 1.088 2.91.832.092-.647.35-1.088.636-1.338-2.22-.253-4.555-1.113-4.555-4.951 0-1.093.39-1.988 1.029-2.688-.103-.253-.446-1.272.098-2.65 0 0 .84-.27 2.75 1.026A9.564 9.564 0 0112 6.844c.85.004 1.705.115 2.504.337 1.909-1.296 2.747-1.027 2.747-1.027.546 1.379.202 2.398.1 2.651.64.7 1.028 1.595 1.028 2.688 0 3.848-2.339 4.695-4.566 4.943.359.309.678.92.678 1.855 0 1.338-.012 2.419-.012 2.747 0 .268.18.58.688.482A10.019 10.019 0 0022 12.017C22 6.484 17.522 2 12 2z" clip-rule="evenodd" /></svg>
-                    </a>
-
-                    
-
-                    {/*<a href="#" target='_blank' class="text-gray-500 hover:text-gray-900 dark:hover:text-white">
-                        <svg class="w-5 h-5" fill="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path fill-rule="evenodd" d="M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10c5.51 0 10-4.48 10-10S17.51 2 12 2zm6.605 4.61a8.502 8.502 0 011.93 5.314c-.281-.054-3.101-.629-5.943-.271-.065-.141-.12-.293-.184-.445a25.416 25.416 0 00-.564-1.236c3.145-1.28 4.577-3.124 4.761-3.362zM12 3.475c2.17 0 4.154.813 5.662 2.148-.152.216-1.443 1.941-4.48 3.08-1.399-2.57-2.95-4.675-3.189-5A8.687 8.687 0 0112 3.475zm-3.633.803a53.896 53.896 0 013.167 4.935c-3.992 1.063-7.517 1.04-7.896 1.04a8.581 8.581 0 014.729-5.975zM3.453 12.01v-.26c.37.01 4.512.065 8.775-1.215.25.477.477.965.694 1.453-.109.033-.228.065-.336.098-4.404 1.42-6.747 5.303-6.942 5.629a8.522 8.522 0 01-2.19-5.705zM12 20.547a8.482 8.482 0 01-5.239-1.8c.152-.315 1.888-3.656 6.703-5.337.022-.01.033-.01.054-.022a35.318 35.318 0 011.823 6.475 8.4 8.4 0 01-3.341.684zm4.761-1.465c-.086-.52-.542-3.015-1.659-6.084 2.679-.423 5.022.271 5.314.369a8.468 8.468 0 01-3.655 5.715z" clip-rule="evenodd" /></svg>
-                    </a>*/}
-                </div>
-            </div>
-
-    )}
-    
-</div>  
diff --git a/content/common/intro/instructors.tsx b/content/common/intro/instructors.tsx
deleted file mode 100644
index 0cdf051d..00000000
--- a/content/common/intro/instructors.tsx
+++ /dev/null
@@ -1,81 +0,0 @@
-type Instructor = {
-    name: string;
-    title: string;
-    
-    twitter: string;
-    linkedin: string;
-    github: string;
-};
-
-const instructors: Instructor[] = [
-    {
-        name: "Martin Eckardt",
-        title: "Director of Developer Relations",
-
-        twitter: "https://x.com/martin_eckardt",
-        linkedin: "https://www.linkedin.com/in/eckardt/",
-        github: "https://github.com/martineckardt",
-    },
-    {
-        name: "Andrea Vargas",
-        title: "Sr. Developer Relations Engineer",
-
-        twitter: "https://x.com/Andyvargtz",
-        linkedin: "https://www.linkedin.com/in/andyvargtz/",
-        github: "https://github.com/andyvargtz",
-    },
-    {
-        name: "Ash",
-        title: "Developer Relations Engineer",
-
-        twitter: "https://x.com/ashngmi",
-        linkedin: "https://www.linkedin.com/in/andyvargtz/",
-        github: "https://github.com/ashucoder9",
-    },
-    {
-        name: "Owen Wahlgren",
-        title: "Developer Relations Engineer",
-
-        twitter: "https://x.com/owenwahlgren",
-        linkedin: "https://www.linkedin.com/in/owenwahlgren/",
-        github: "https://github.com/owenwahlgren",
-    },
-    {
-        name: "Sarp",
-        title: "Sr. Developer Relations Engineer",
-
-        twitter: "https://x.com/satatocom",
-        linkedin: "https://www.linkedin.com/in/sarptaylan/",
-        github: "https://github.com/0xstt",
-    },
-    {
-        name: "Aaron Buchwald",
-        title: "HyperSDK Lead Engineer",
-
-        twitter: "https://x.com/AaronBuchwald",
-        linkedin: "",
-        github: "",
-    },
-    {
-        name: "Ilya",
-        title: "Sr. Developer Relations Engineer",
-
-        twitter: "https://x.com/containerman17",
-        linkedin: "",
-        github: "",
-    },
-    {
-        name: "Rodrigo Villar",
-        title: "Developer Relations Engineer",
-
-        twitter: "https://x.com/rrodrigovillar",
-        linkedin: "",
-        github: "",
-    }
-];
-
-export function getInstructorsByNames(names:string[]) : Instructor[] {
-    return instructors.filter((instructor) => names.includes(instructor.name));
-}
-
-export default instructors;
\ No newline at end of file
diff --git a/content/common/multi-chain-architecture/etna-upgrade-motivation.mdx b/content/common/multi-chain-architecture/etna-upgrade-motivation.mdx
deleted file mode 100644
index 019bafa9..00000000
--- a/content/common/multi-chain-architecture/etna-upgrade-motivation.mdx
+++ /dev/null
@@ -1,73 +0,0 @@
-The Etna upgrade will be the largest network upgrade of Avalanche to date. This upgrade will introduce a new concept called Layer 1 blockchains (L1s), which will replace the current Subnet model. In this article we will discuss the current limitations of Subnets, and how the changes suggested in [ACP-77](https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/77-reinventing-subnets/README.md) will address these limitations in the Etna Upgrade.
-
-<YouTube id="6t2agl0J0OU" />
-
-## How Subnets Work Today
-
-The Avalanche network has a large set of validators who all participate in running and validating the Primary Network. The Primary Network consists of the C-Chain, P-Chain, and X-Chain, and is where most of the transactions on Avalanche are processed.
-
-A blockchain has a limited capacity for computation and data storage. Therefore, the transactions it can process in a given time frame are limited. We can use the analogy of a highway to visualize this concept. A highway can only handle a certain number of cars at a time. If too many cars try to enter the highway at once, traffic congestion will occur and they have to wait to enter the highway.
-
-![Subnets](/common-images/multi-chain-architecture/etna-upgrade/subnets.png)
-
-In order to scale horizontally and to offer more blockspace, a subset of validators can opt-in to validate an additional blockchain in parallel with the Primary Network: we call this a Subnet. The idea is similiar to building many highways in parallel and create additional space for cars to drive on. This allows for more transactions to be processed in parallel, and therefore increases the overall throughput of the network.
-
-## Etna Upgrade
-
-With the Etna upgrade, Subnets will become their own **Layer 1** blockchains. Instead of using a subset of Primary Network Validators, new L1s can now use a distinct set of validators.
-
-![L1s](/common-images/multi-chain-architecture/etna-upgrade/l1s.png)
-
-This change maintains the short time of finality and high throughput Avalanche Subnets are known for while also enabling a new set of features with options for completely customizable staking options, gas tokens, and governance.
-
-### Economic Barriers
-
-The Primary Network currently has a staking requirement of **2,000 AVAX per validator**. If we assume a price of $20 per AVAX, a Subnet would have to have each of its validators stake AVAX worth $40,000 in addition to its own staking requirements. This is a significant economic barrier for the creation of new Subnets.
-
-![Staking Requirements](/common-images/multi-chain-architecture/etna-upgrade/subnets-staking-requirements.png)
-
-This model has created a significant economic barrier for the creation of new Subnets as validators must meet the 2,000 AVAX requirement, and a majority of Subnets prefer to run with a minimum of 5 validators.
-
-The Etna upgrade will remove the requirement for L1 validators to validate the Primary Network and fulfill its staking requirements. Therefore, they do not need to stake 2,000 AVAX on the Primary Network, and instead only abide by the staking requirements defined by the L1 they wish to validate.
-
-![L1 Staking Requirements](/common-images/multi-chain-architecture/etna-upgrade/l1s-staking-requirement.png)
-
-To use the interoperability features of Avalanche, L1 validators will still need to register their validator set with the P-Chain of the Primary Network. For this each L1 validator will need to pay a continous fee. This fee is independent of the number of transactions on the L1, the number of cross-chain messages, and the number of validators of the L1. Current estimations are that this fee will be around 1 to 10 AVAX per month per validator.
-
-This will remove the significant economic barrier, giving more sovereignty to L1 creators and validators, while preserving interoperability and economic security for the Primary Network.
-
-### Running Costs
-
-Currently, validators must validate the Primary Network in addition to each Subnet they are validating. This can lead to higher running costs for validators as they must maintain machines that can handle the load of all their blockchains.
-
-![Subnet Running Cost](/common-images/multi-chain-architecture/etna-upgrade/subnet-running-cost.png)
-
-With the Etna upgrade, validators will only need to validate the L1. This will lead to lower running costs for validators as they will not need to maintain machines that can handle the load of both the Subnets and the Primary Network.
-
-![L1 Running Cost](/common-images/multi-chain-architecture/etna-upgrade/l1-running-cost.png)
-
-### Compliance
-
-Many Institutions that want to adopt blockchain are struggling with exposure to public permissionless blockchains. The Primary Network is a public permissionless blockchain, and as such, it is not suitable to build on for many institutions. While institutions can launch their own Subnet as a private, proof of authority blockchain, they are still exposed to the Primary Network in some manner.
-
-![Subnet Compliance](/common-images/multi-chain-architecture/etna-upgrade/subnets-compliance.png)
-
-This exposure can be circumvented by performing a partial sync of the Primary Network, but is an incomplete solution. Since the validator sets of L1s will be distinct and separate from the Primary Network, institutions will be able to launch independent L1s (be it public or private) that are not required to participate in the Primary Network.
-
-![L1 Compliance](/common-images/multi-chain-architecture/etna-upgrade/l1s-compliance.png)
-
-### Fault Isolation
-
-Occasionaly, there can be very high demand or a fault on the Primary Network. Because Subnet validators must also validate the Primary Network, their machines are exposed to the same congestion which can have a consequential effects on Subnet performance.
-
-![Fault Isolation](/common-images/multi-chain-architecture/etna-upgrade/subnets-primary-network-congestion.png)
-
-After the Etna upgrade validator sets are distinct. Therefore, congestion and faults on the Primary Network will not affect the performance of L1s and vice versa.
-
-![L1s Fault Isolation](/common-images/multi-chain-architecture/etna-upgrade/l1s-primary-network-faults.png)
-
-## Conclusion
-
-The Etna upgrade is the largest network upgrade of Avalanche to date. This change will enable more developers to get inexpensive block space for their applications, provide better fault isolation, while also enabling institutions to launch their own L1s with better compliance.
-
-You can learn more in depth about ACP-77 by reading the [ACP-77 Proposal](https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/77-reinventing-subnets/README.md).
diff --git a/content/common/multi-chain-architecture/transaction-fees.mdx b/content/common/multi-chain-architecture/transaction-fees.mdx
deleted file mode 100644
index 07e49c93..00000000
--- a/content/common/multi-chain-architecture/transaction-fees.mdx
+++ /dev/null
@@ -1,51 +0,0 @@
-NFT collectors, DeFi traders, and blockchain gamers have independently spent significant sums to execute their transactions. These unrelated activities converge on the blockchain, competing for the finite capacity of the next blockspace. In an effort to avoid delays or being outpaced by others, participants can be compelled to pay substantial fees to secure prompt transaction processing.
-
-But why are there transaction fees (also commonly known as gas fees) at all? Let's recap the reason for fees and how they work.
-
-In the Ethereum Virtual Machine (EVM), transaction fees play a crucial role in regulating access to the limited processing resources within the blockchain network. The blockchain has a limit of how much computation it can process in a given time frame. Imagine the Ethereum network as a highway with lanes representing block space. Each transaction is like a vehicle that needs space on these lanes.
-
-![](/course-images/multi-chain-architecture/transaction-fees/low-demand.png)
-
-Now, just like on a highway during rush hour, if too many vehicles try to access the lanes at once, congestion occurs, slowing down the entire system. To prevent this congestion, Ethereum employs dynamic transaction fees. These fees keep users from issuing transactions during times of high demand, much like a flexible toll system on a highway. When traffic is light, the tolls remain low, allowing for smooth flow. However, as more vehicles (transactions) enter the highway (the blockchain), and it becomes congested, the tolls (transaction fees) rise.
-
-![](/course-images/multi-chain-architecture/transaction-fees/high-demand.png)
-
-When the transaction fees are high users will rethink the urgency or importance of their transactions, much like how drivers might reconsider their travel plans or opt for alternative routes when faced with higher tolls. Ultimately, this dynamic fee structure helps to maintain a balanced flow of transactions, preventing bottlenecks and ensuring the network operates efficiently even during periods of high demand.
-
-These fees can vary quite significantly over time. The following chart is showing the 7-day average of transaction fees on Ethereum:
-
-<iframe width="100%" height="420" style={{border: 0}} src="https://www.theblock.co/data/on-chain-metrics/ethereum/average-transaction-fee-on-ethereum/embed" title="Average Transaction Fee on Ethereum (7DMA)"></iframe>
-
-## The Unit Gas 
-
-Not every transaction costs the same because they vary in complexity. Simple transactions, like sending tokens from one wallet to another have much lower fees than for example interacting with smart contracts executing complicated operations.
-
-Going back to our highway analogy, think of having the highway operator charge different fees for motorbikes, cars and buses on the highway. Larger vehicles take up more space and require more effort to process, so they have higher fees.
-
-## Business Models of web3 dApps
-
-These fluctuating fees can be a huge danger to the business model of many web3 dApps. Let's look at a simple example protocol, where users can swap two stablecoins:
-
-![](/course-images/multi-chain-architecture/transaction-fees/stablecoin-swap.png)
-
-The users using these dApps will face multiple fees. In our example the fee structure could look something like this:
-
-![](/course-images/multi-chain-architecture/transaction-fees/swap-fees-low.png)
-
-In our example the users are paying three kinds of fees:
-
-- **Transaction Fee:** The fee to execute their transaction on the blockchain
-- **Protocol Fee:** A fee to the creator/owner of the stablecoin swap protocol
-- **Liquidity Provider Fee:** In this example we also include a fee for external liquidity provider. Many protocols incentivize external entities to participate in the protocol (by for example providing liquidity).
-
-The users don't really care how the fees are split between the different parties involved in the execution of the swap. At the end of the day they are looking at the overall cost for their intention.
-
-![](/course-images/multi-chain-architecture/transaction-fees/user-price-expectation.png)
-
-Some time passes now and the activity increases on the chain. The cause may be an NFT drop or a bull market. Due to rising activity and demand for the limited block space the transaction fees increase:
-
-![](/course-images/multi-chain-architecture/transaction-fees/swap-fees-high.png)
-
-Even though nothing about the protocol has changed and the increased chain activity may not even affect you in any other way, much less users will use the protocol now.
-
-Many blockchain ecosystems are working on isolating fees, meaning not having a single fee market for unrelated activities on the chain. In the coming section we will look at how Avalanche achieves fee isolation.
\ No newline at end of file
diff --git a/content/common/primary-network/p-chain.mdx b/content/common/primary-network/p-chain.mdx
deleted file mode 100644
index b5ec5055..00000000
--- a/content/common/primary-network/p-chain.mdx
+++ /dev/null
@@ -1,7 +0,0 @@
-In the Avalanche Network, the P-Chain of the Primary Network is responsible for all validator and Avalanche L1-level operations. The P-Chain supports the creation of new blockchains and Avalanche L1s, the addition of validators to Avalanche L1s, staking operations, and other platform-level operations. 
-
-![P-Chain](/common-images/primary-network/p-chain.png)
-
-Each Avalanche validator can register a BLS public key alongside its NodeID on the Avalanche P-Chain. Validators of Avalanche L1s can stake different amounts of the Avalanche L1's staking token. Through the P-Chain, we can determine a weighted set of BLS Public Keys that correspond to the validators of each Avalanche L1 on the Avalanche Network.
-
-Anyone can see on the P-Chain the current weighted validator sets of every Avalanche L1 and how the set has evolved over time.
\ No newline at end of file
diff --git a/content/course/archive/06-setup-core-wallet.mdx b/content/course/archive/06-setup-core-wallet.mdx
deleted file mode 100644
index cd20d4e1..00000000
--- a/content/course/archive/06-setup-core-wallet.mdx
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Setup Core Wallet
-description: Learn how to setup Core Wallet.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-## Install the Browser Extension
-
-import InstallCoreExtension from "@/content/common/core-wallet/install.mdx"
-
-<InstallCoreExtension />
-
-## Create a New Wallet
-
-Open the core extension and follow the instructions to create a new wallet. You can also follow the below video guide.
-
-<YouTube id="eczkjrGG_As" />
-
-## Managing MetaMask and Core Extensions
-
-import Metamask from "@/content/common/core-wallet/metamask.mdx"
-
-<Metamask />
\ No newline at end of file
diff --git a/content/course/archive/teleporter/01-incentivize-relayer/xx_05-create-configuration.mdx b/content/course/archive/teleporter/01-incentivize-relayer/xx_05-create-configuration.mdx
deleted file mode 100644
index 8666f6b9..00000000
--- a/content/course/archive/teleporter/01-incentivize-relayer/xx_05-create-configuration.mdx
+++ /dev/null
@@ -1,74 +0,0 @@
----
-title: Create Configuration
-description: TBD
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-Alright, now let's create a configuration file for the AWM Relayer.
-
-## Get the Sample Relayer Config
-
-You can get the sample relayer config from the [AWM Relayer GitHub repository](https://github.com/ava-labs/awm-relayer/blob/main/sample-relayer-config.json).
-
-## General Config
-
-We will use the local node running on port 9650 for both the P-Chain and Info API.
-
-```json
-{ 
-  "p-chain-api": {
-    "base-url": "http://127.0.0.1:9650",
-  },
-  "info-api": {
-    "base-url": "http://127.0.0.1:9650",
-  }
-}
-```
-
-## Source Blockchain Configs
-
-```bash
-avalanche primary describe
-```
-
-```json
-{
-  "source-blockchains": [
-    {
-      "subnet-id": "...",
-      "blockchain-id": "...",
-      "vm": "evm",
-      "rpc-endpoint": {
-        "base-url": "http://...",
-        "query-parameters": null,
-        "http-headers": null
-      },
-      "ws-endpoint": {
-        "base-url": "ws://127.0.0.1:9650/ext/bc/epm5fG6Pn1Y5rBHdTe36aZYeLqpXugreyHLZB5dV81rVTs7Ku/ws",
-        "query-parameters": null,
-        "http-headers": null
-      },
-      "message-contracts": {
-        "0x0000000000000000000000000000000000000000": {
-          "message-format": "off-chain-registry",
-          "settings": {
-            "teleporter-registry-address": "0x17aB05351fC94a1a67Bf3f56DdbB941aE6c63E25"
-          }
-        },
-        "0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf": {
-          "message-format": "teleporter",
-          "settings": {
-            "reward-address": "0x4Fc7Cddd060e4AE86A1DB54dE877C0b3441d5EbD"
-          }
-        }
-      },
-      "supported-destinations": null,
-      "process-historical-blocks-from-height": 0,
-      "allowed-origin-sender-addresses": null
-    }
-  ]
-}
-```
-
diff --git a/content/course/archive/teleporter/01-incentivize-relayer/xx_06-create-a-wallet.mdx b/content/course/archive/teleporter/01-incentivize-relayer/xx_06-create-a-wallet.mdx
deleted file mode 100644
index be3069bb..00000000
--- a/content/course/archive/teleporter/01-incentivize-relayer/xx_06-create-a-wallet.mdx
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Create a Wallet
-description: TBD
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-Since our AWM Relayer will submit the incoming warp messages as transactions on the destination Avalanche L1, it will need to have a wallet with the native gas token of the destination chain to sign these transactions. It is best practice to create a new wallet for your relayer. The private key will be needed as part of your relayer's config file.
-
-You can create this wallet however you like. One way to create a wallet is using foundry's `cast` command:
-
-```bash
-cast wallet new
-```
-
-<Callout type="warn">Never use this wallet outside of this testing environment. Do not store any funds of real value in this wallet.</Callout>
-
-
-
-
diff --git a/content/course/avacloudapis/02-overview/01-about.mdx b/content/course/avacloudapis/02-overview/01-about.mdx
deleted file mode 100644
index 4a36e463..00000000
--- a/content/course/avacloudapis/02-overview/01-about.mdx
+++ /dev/null
@@ -1,37 +0,0 @@
----
-title: Features
-description: Learn about the features of the AvaCloud API.
-updated: 2024-09-03
-authors: [owenwahlgren]
-icon: Book
----
-
-## What is the Data API?
-
-The Data API provides web3 application developers with multi-chain data related to Avalanche’s primary network, Avalanche L1s, and Ethereum. With the Data API, you can easily build products that leverage real-time and historical transaction and transfer history, native and token balances, and various types of token metadata.
-
-### Data API Features
-- **Extensive L1 Support**: Gain access to data from over 100+ L1s across both mainnet and testnet. If an L1 is listed on the [Avalanche Explorer](https://subnets.avax.network/stats/), you can query its data using the Data API.
-- **Transactions and UTXOs**: Easily retrieve details related to transactions, UTXOs, and token transfers from Avalanche EVMs, Ethereum, and Avalanche’s Primary Network (P-Chain, X-Chain and C-Chain).
-- **Blocks**: Retrieve latest blocks and block details
-- **Balances**: Fetch balances of native, ERC-20, ERC-721, and ERC-1155 tokens along with relevant metadata.
-- **Tokens**: Augment your user experience with asset details.
-- **Staking**: Get staking related data for active and historical validations.
-
-## What is the Metrics API?
-The Metrics API equips web3 developers with a robust suite of tools to access and analyze on-chain activity across Avalanche’s primary network, Avalanche L1s, and other supported EVM chains. This API delivers comprehensive metrics and analytics, enabling you to seamlessly integrate historical data on transactions, gas consumption, throughput, staking, and more into your applications.
-
-The Metrics API, along with the Data API are the driving force behind every graph you see on the [Avalanche Explorer](https://subnets.avax.network/stats/). From transaction trends to staking insights, the visualizations and data presented are all powered by these APIs, offering real-time and historical insights that are essential for building sophisticated, data-driven blockchain products.
-
-### Metrics API Features
-- **Chain Throughput**: Retrieve detailed metrics on gas consumption, Transactions Per Second (TPS), and gas prices, including rolling windows of data for granular analysis.
-- **Cumulative Metrics**: Access cumulative data on addresses, contracts, deployers, and transaction counts, providing insights into network growth over time.
-- **Staking Information**: Obtain staking-related data, including the number of validators and delegators, along with their respective weights, across different subnets.
-- **Blockchains and Subnets**: Get information about supported blockchains, including EVM Chain IDs, blockchain IDs, and subnet associations, facilitating multi-chain analytics.
-- **Composite Queries**: Perform advanced queries by combining different metric types and conditions, enabling detailed and customizable data retrieval.
-
-## What is the AvaCloudSDK?
-
-The [AvaCloud SDK](https://developers.avacloud.io/avacloud-sdk/getting-started) provides web3 application developers with multi-chain data related to Avalanche’s primary network, Avalanche L1s, and Ethereum. With the Data API, you can easily build products that leverage real-time and historical transaction and transfer history, native and token balances, and various types of token metadata.
-
-The SDK is currently available in TypeScript, with more languages coming soon. If you are interested in a language that is not listed, please reach out to us in the [`#dev-tools`](https://discord.com/login?redirect_to=%2Flogin%3Fredirect_to%3D%252Fchannels%252F578992315641626624%252F1280920394236297257) channel in the [Avalanche Discord](https://discord.com/invite/avax).
diff --git a/content/course/avacloudapis/02-overview/02-apis-vs-rpc.mdx b/content/course/avacloudapis/02-overview/02-apis-vs-rpc.mdx
deleted file mode 100644
index b033b93c..00000000
--- a/content/course/avacloudapis/02-overview/02-apis-vs-rpc.mdx
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: APIs vs RPCs
-description: Learn how the AvaCloud Data API differs from RPC calls
-updated: 2024-09-03
-authors: [owenwahlgren]
-icon: Book
----
-
-Blockchain RPCs and APIs both facilitate interactions with a network, but they differ significantly in how they operate.
-
-### RPCs
-**Blockchain RPCs** allow you to communicate directly with a blockchain node, performing tasks like querying data or submitting transactions. These are low-level, synchronous calls, requiring a deep understanding of the blockchain's structure and specific commands.
-
-To get a more comprehensive understanding of Ethereum's JSON-RPC API, you can refer to the [official Ethereum documentation](https://ethereum.org/en/developers/docs/apis/json-rpc/).
-
-### APIs
-**Blockchain APIs**, like the AvaCloud Data API, abstract away much of the complexity. They offer higher-level, user-friendly endpoints that streamline interactions, making it easier to build and manage blockchain applications without needing in-depth knowledge of the underlying blockchain protocols.
-
-To get a more comprehensive understanding of the AvaCloud Data API, you can refer to the [official AvaCloud Data API documentation](https://developers.avacloud.io/data-api/overview).
-
-### Example Use Case
-For example, querying a user's ERC-20 portfolio using an RPC involves a series of complex calls to retrieve and parse raw blockchain data. 
-Using just RPCs, you would need to:
-
-1. Query every block on the network for transaction logs.
-2. Parse each transaction log to identify ERC-20 token transfers.
-3. Extract the ERC-20 token contract address.
-4. For each ERC-20 token contract, query the user's address to get the balance.
-5. Parse and aggregate the data to present the user's portfolio.
-
-While it may seem simple in theory, this process can be time-consuming and error-prone, especially when dealing with multiple blockchains.
-
-With the AvaCloud Data API, you could simply use a dedicated endpoint such as: 
-```bash
-curl --request GET \
-  --url https://glacier-api.avax.network/v1/chains/{chainId}/addresses/{address}/balances:listErc20 \
-  --header 'x-glacier-api-key: <api-key>'
-```
-
-to get a neatly formatted response with the user's ERC-20 portfolio, significantly reducing development time and complexity.
-
-```json
-{
-  "nextPageToken": "<string>",
-  "erc20TokenBalances": [
-    {
-      "address": "0x71C7656EC7ab88b098defB751B7401B5f6d8976F",
-      "name": "Wrapped AVAX",
-      "symbol": "WAVAX",
-      "decimals": 18,
-      "logoUri": "https://images.ctfassets.net/gcj8jwzm6086/5VHupNKwnDYJvqMENeV7iJ/fdd6326b7a82c8388e4ee9d4be7062d4/avalanche-avax-logo.svg",
-      "ercType": "ERC-20",
-      "price": {
-        "currencyCode": "usd",
-        "value": "42.42"
-      },
-      "chainId": "43114",
-      "balance": "2000000000000000000",
-      "balanceValue": {
-        "currencyCode": "usd",
-        "value": "42.42"
-      }
-    }
-  ]
-}
-```
\ No newline at end of file
diff --git a/content/course/avacloudapis/02-overview/03-dataapi-endpoints.mdx b/content/course/avacloudapis/02-overview/03-dataapi-endpoints.mdx
deleted file mode 100644
index 691ccc37..00000000
--- a/content/course/avacloudapis/02-overview/03-dataapi-endpoints.mdx
+++ /dev/null
@@ -1,370 +0,0 @@
----
-title: Data API
-description: Learn about AvaCloud Data API.
-updated: 2024-09-03
-authors: [owenwahlgren]
-icon: Book
----
-![](/course-images/avacloudsdk/glacier-data-api.png)
-
-The AvaCloud Data API provides a comprehensive set of endpoints to interact with Avalanche networks. These endpoints allow you to query information about blocks, transactions, assets, and more.
-
-Below are some of the key endpoints available in the Data API.
-A more comphrensive list of Data API endpoints can be found [here](https://developers.avacloud.io/data-api/overview).
-
-## Data API Reference
-### EVM Endpoints
-
-<Accordions>
-<Accordion title="Chains">
-- [List All Chains](https://developers.avacloud.io/data-api/evm-chains/list-chains)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains \
-     --header 'accept: application/json'
-```
-- [Get Chain Information](https://developers.avacloud.io/data-api/evm-chains/get-chain-information)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId} \
-     --header 'accept: application/json'
-```
-</Accordion>
-
-<Accordion title="Blocks">
-- [List Latest Blocks](https://developers.avacloud.io/data-api/evm-chains/list-latest-blocks)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/blocks \
-     --header 'accept: application/json'
-```
-- [Get Block Information](https://developers.avacloud.io/data-api/evm-chains/getblock)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/blocks/{blockId} \
-     --header 'accept: application/json'
-``` 
-
-</Accordion>
-
-<Accordion title="Transactions">
-- [Get Deployment Transaction](https://developers.avacloud.io/data-api/evm-transactions/get-deployment-transaction)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/contracts/{address}/transactions:getDeployment \
-     --header 'accept: application/json'
-```
-- [List Deployed Contracts](https://developers.avacloud.io/data-api/evm-transactions/list-deployed-contracts)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/contracts/{address}/deployments \
-     --header 'accept: application/json'
-```
-- [List ERC Transfers](https://developers.avacloud.io/data-api/evm-transactions/list-erc-transfers)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/tokens/{address}/transfers \
-     --header 'accept: application/json'
-```
-
-- [List Transactions](https://developers.avacloud.io/data-api/evm-transactions/list-transactions)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/addresses/{address}/transactions \
-     --header 'accept: application/json'
-```
-
-- [List Native Transactions](https://developers.avacloud.io/data-api/evm-transactions/list-native-transactions)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/addresses/{address}/transactions:listNative \
-     --header 'accept: application/json'
-```
-
-- [List ERC-20 Transfers](https://developers.avacloud.io/data-api/evm-transactions/list-erc-20-transfers)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/addresses/{address}/transactions:listErc20 \
-     --header 'accept: application/json'
-```
-
-- [List ERC-721 Transfers](https://developers.avacloud.io/data-api/evm-transactions/list-erc-721-transfers)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/addresses/{address}/transactions:listErc721 \
-     --header 'accept: application/json'
-```
-
-- [List ERC-1155 Transfers](https://developers.avacloud.io/data-api/evm-transactions/list-erc-1155-transfers)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/addresses/{address}/transactions:listErc1155 \
-     --header 'accept: application/json'
-```
-- [List Internal Transactions](https://developers.avacloud.io/data-api/evm-transactions/list-internal-transactions)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/addresses/{address}/transactions:listInternals \
-     --header 'accept: application/json'
-```
-
-- [Get Transaction](https://developers.avacloud.io/data-api/evm-transactions/get-transaction)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/transactions/{txHash} \
-     --header 'accept: application/json'
-```
-
-- [List Transactions For a Block](https://developers.avacloud.io/data-api/evm-transactions/list-transactions-for-a-block)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/blocks/{blockId}/transactions \
-     --header 'accept: application/json'
-```
-
-- [List Latest Transactions](https://developers.avacloud.io/data-api/evm-transactions/list-latest-transactions)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/transactions \
-     --header 'accept: application/json'
-```
-</Accordion>
-
-<Accordion title="Balances">
-- [Get Native Token Balance](https://developers.avacloud.io/data-api/evm-balances/get-native-token-balance)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/addresses/{address}/balances:getNative \
-     --header 'accept: application/json'
-```
-- [List ERC-20 Balances](https://developers.avacloud.io/data-api/evm-balances/list-erc-20-balances)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/addresses/{address}/balances:listErc20 \
-     --header 'accept: application/json'
-```
-- [List ERC-721 Balances](https://developers.avacloud.io/data-api/evm-balances/list-erc-721-balances)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/addresses/{address}/balances:listErc721 \
-     --header 'accept: application/json'
-```
-- [List ERC-1155 Balances](https://developers.avacloud.io/data-api/evm-balances/list-erc-1155-balances)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/addresses/{address}/balances:listErc1155 \
-     --header 'accept: application/json'
-```
-- [List Collectible (ERC-721 and ERC-1155) Balances](https://developers.avacloud.io/data-api/evm-balances/list-collectible-erc-721erc-1155-balances)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/addresses/{address}/balances:listCollectibles \
-     --header 'accept: application/json'
-```
-</Accordion>
-
-<Accordion title="Contracts">
-- [Get Contract Metadata](https://developers.avacloud.io/data-api/evm-contracts/get-contract-metadata)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/addresses/{address} \
-     --header 'accept: application/json'
-```
-</Accordion>
-
-<Accordion title="NFTs">
-- [Reindex NFT Metadata](https://developers.avacloud.io/data-api/nfts/reindex-nft-metadata)
-```bash
-curl --request POST \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/nfts/collections/{address}/tokens/tokenId:reindex \
-     --header 'accept: application/json'
-```
-- [List Tokens](https://developers.avacloud.io/data-api/nfts/list-tokens)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/nfts/collections/{address}/tokens \
-     --header 'accept: application/json'
-```
-- [Get Token Details](https://developers.avacloud.io/data-api/nfts/get-token-details)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/chains/{chainId}/nfts/collections/{address}/tokens/tokenId \
-     --header 'accept: application/json'
-```
-
-</Accordion>
-
-</Accordions>
-
-
-
-### Avalanche Primary Network Endpoints
-
-<Accordions>
-<Accordion title="Network, Chains, and L1s">
-- [Get Chain Interactions for Addresses](https://developers.avacloud.io/data-api/primary-network/get-chain-interactions-for-addresses)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/{network}/addresses:listChainIds \
-     --header 'accept: application/json'
-```
-
-- [Get Network Details](https://developers.avacloud.io/data-api/primary-network/get-network-details)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/{network} \
-     --header 'accept: application/json'
-```
-- [List Blockchains](https://developers.avacloud.io/data-api/primary-network/list-blockchains)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/{network}/blockchains \
-     --header 'accept: application/json'
-```
-
-- [List Subnets](https://developers.avacloud.io/data-api/primary-network/list-subnets)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/mainnet/subnets \
-     --header 'accept: application/json'
-```
-- [Get Subnet Details by ID](https://developers.avacloud.io/data-api/primary-network/get-subnet-details-by-id)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/mainnet/subnets/{subnetId} \
-     --header 'accept: application/json'
-```
-</Accordion>
-
-<Accordion title="Validators and Delegators">
-- [List Validators](https://developers.avacloud.io/data-api/primary-network/list-validators)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/mainnet/validators \
-     --header 'accept: application/json'
-```
-- [Get Single Validator Details](https://developers.avacloud.io/data-api/primary-network/get-single-validator-details)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/mainnet/validators/{nodeId} \
-     --header 'accept: application/json'
-```
-- [List Delegators](https://developers.avacloud.io/data-api/primary-network/list-delegators)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/mainnet/delegators \
-     --header 'accept: application/json'
-```
-</Accordion>
-
-<Accordion title="Blocks">
-- [Get Block](https://developers.avacloud.io/data-api/primary-network-blocks/get-block)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/mainnet/blockchains/11111111111111111111111111111111LpoYY/blocks/{blockId} \
-     --header 'accept: application/json'
-```
-- [List Blocks Proposed by Node](https://developers.avacloud.io/data-api/primary-network-blocks/list-blocks-proposed-by-node)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/mainnet/blockchains/11111111111111111111111111111111LpoYY/nodes/{nodeId}/blocks \
-     --header 'accept: application/json'
-```
-
-- [List Latest Blocks](https://developers.avacloud.io/data-api/primary-network-blocks/list-latest-blocks)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/mainnet/blockchains/11111111111111111111111111111111LpoYY/blocks \
-     --header 'accept: application/json'
-```
-</Accordion>
-
-<Accordion title="Vertices">
-- [List Vertices](https://developers.avacloud.io/data-api/primary-network-vertices/list-vertices)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/mainnet/blockchains/2oYMBNV4eNHyqk2fjjV5nVQLDbtmNJzq5s3qs3Lo6ftnC6FByM/vertices \
-     --header 'accept: application/json'
-```
-- [Get Vertex](https://developers.avacloud.io/data-api/primary-network-vertices/get-vertex)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/mainnet/blockchains/2oYMBNV4eNHyqk2fjjV5nVQLDbtmNJzq5s3qs3Lo6ftnC6FByM/vertices/vertexHash \
-     --header 'accept: application/json'
-```
-- [List Vertices by Height](https://developers.avacloud.io/data-api/primary-network-vertices/list-vertices-by-height)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/mainnet/blockchains/2oYMBNV4eNHyqk2fjjV5nVQLDbtmNJzq5s3qs3Lo6ftnC6FByM/vertices:listByHeight \
-     --header 'accept: application/json'
-```
-</Accordion>
-
-<Accordion title="Transactions">
-- [Get Transaction](https://developers.avacloud.io/data-api/primary-network-transactions/get-transaction)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/{network}/blockchains/{blockchainId}/transactions/{txHash} \
-     --header 'accept: application/json'
-```
-- [List Latest Transactions](https://developers.avacloud.io/data-api/primary-network-transactions/list-latest-transactions)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/{network}/blockchains/{blockchainId}/transactions \
-     --header 'accept: application/json'
-```
-- [List Staking Transactions](https://developers.avacloud.io/data-api/primary-network-transactions/list-staking-transactions)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/mainnet/blockchains/11111111111111111111111111111111LpoYY/transactions:listStaking \
-     --header 'accept: application/json'
-```
-
-- [List Asset Transactions](https://developers.avacloud.io/data-api/primary-network-transactions/list-asset-transactions)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/mainnet/blockchains/2oYMBNV4eNHyqk2fjjV5nVQLDbtmNJzq5s3qs3Lo6ftnC6FByM/assets/{assetId}/transactions \
-     --header 'accept: application/json'
-```
-
-</Accordion>
-
-<Accordion title="Balances and UTXOs">
-- [List UTXOs](https://developers.avacloud.io/data-api/primary-network-utxos/list-utxos)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/mainnet/blockchains/11111111111111111111111111111111LpoYY/utxos \
-     --header 'accept: application/json'
-```
-- [Get Balances](https://developers.avacloud.io/data-api/primary-network-balances/get-balances)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/mainnet/blockchains/11111111111111111111111111111111LpoYY/balances \
-     --header 'accept: application/json'
-```
-</Accordion>
-
-<Accordion title="Rewards">
-- [List Pending Rewards](https://developers.avacloud.io/data-api/primary-network-rewards/list-pending-rewards)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/mainnet/rewards:listPending \
-     --header 'accept: application/json'
-```
-- [List Historical Rewards](https://developers.avacloud.io/data-api/primary-network-rewards/list-historical-rewards)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/mainnet/rewards \
-     --header 'accept: application/json'
-```
-</Accordion>
-
-<Accordion title="Assets">
-- [Get Asset Details](https://developers.avacloud.io/data-api/primary-network/get-asset-details)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/networks/mainnet/blockchains/2oYMBNV4eNHyqk2fjjV5nVQLDbtmNJzq5s3qs3Lo6ftnC6FByM/assets/{assetId} \
-     --header 'accept: application/json'
-```
-</Accordion>
-</Accordions>
diff --git a/content/course/avacloudapis/02-overview/04-webhooks.mdx b/content/course/avacloudapis/02-overview/04-webhooks.mdx
deleted file mode 100644
index e9b697c8..00000000
--- a/content/course/avacloudapis/02-overview/04-webhooks.mdx
+++ /dev/null
@@ -1,140 +0,0 @@
----
-title: Webhooks API
-description: Learn about AvaCloud Webhooks API.
-updated: 2024-09-03
-authors: [owenwahlgren]
-icon: Book
----
-## What is a Webhook?
-
-A webhook is a communication mechanism to provide applications with real-time information. It delivers data to other applications as it happens, meaning you get data immediately, unlike typical APIs where you would need to poll for data to get it in "real-time". This makes webhooks much more efficient for both providers and consumers. Webhooks work by registering a URL to send notifications once certain events occur.
-You can create receiver endpoints in your server in any programming language and those will have an associated URL. This object contains all the relevant information about what just happened, including the type of event and the data associated with that event.
-
-## What are AvaCloud Webhooks?
-
-With the Webhooks API, you can monitor real-time events on the Avalanche C-Chain and L1s. For example, you can monitor smart contract events, track NFT transfers, and observe wallet-to-wallet transactions.
-
-![](/course-images/avacloudsdk/glacier-webhooks.png)
-
-### Key Features:
-- **Real-time notifications:** Receive immediate updates on specified on-chain activities without polling.
-- **Customizable:** Specify the desired event type to listen for, customizing notifications according to individual requirements.
-- **Secure:** Employ shared secrets and signature-based verification to guarantee that notifications originate from a trusted source.
-- **Broad Coverage:** Support for C-chain mainnet, testnet, and subnets within the Avalanche ecosystem, ensuring wide-ranging monitoring capabilities.
-
-### Use Cases:
-- **NFT Marketplace Transactions:** Get alerts for NFT minting, transfers, auctions, bids, sales, and other interactions within NFT marketplaces.
-- **Wallet Notifications:** Receive alerts when an address performs actions such as sending, receiving, swapping, or burning assets.
-- **DeFi Activities:** Receive notifications for various DeFi activities such as liquidity provisioning, yield farming, borrowing, lending, and liquidations.
-
-## Webhooks API Reference
-
-<Accordions>
-
-<Accordion title="Create a webhook">
-[Create a new webhook](https://developers.avacloud.io/webhooks-api/webhooks/create-a-webhook)
-```bash
-curl --request POST \
-     --url https://glacier-api.avax.network/v1/webhooks \
-     --header 'accept: application/json' \
-     --header 'content-type: application/json' \
-     --data '
-{
-  "eventType": "address_activity"
-}
-```
-</Accordion>
-
-<Accordion title="List webhooks">
-[Lists webhooks for the user.](https://developers.avacloud.io/webhooks-api/webhooks/list-webhooks)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/webhooks \
-     --header 'accept: application/json'
-```
-
-</Accordion>
-
-<Accordion title="Get a webhook by ID">
-[Retrieves a webhook by ID.](https://developers.avacloud.io/webhooks-api/webhooks/get-a-webhook-by-id)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/webhooks/id \
-     --header 'accept: application/json'
-```
-
-</Accordion>
-
-<Accordion title="Deactivate a webhook">
-[Deactivates a webhook by ID.](https://developers.avacloud.io/webhooks-api/webhooks/deactivate-a-webhook)
-```bash
-curl --request DELETE \
-     --url https://glacier-api.avax.network/v1/webhooks/id \
-     --header 'accept: application/json'
-```
-
-</Accordion>
-
-<Accordion title="Update a webhook">
-[Updates an existing webhook.](https://developers.avacloud.io/webhooks-api/webhooks/update-a-webhook)
-```bash
-curl --request PATCH \
-     --url https://glacier-api.avax.network/v1/webhooks/id \
-     --header 'accept: application/json' \
-     --header 'content-type: application/json'
-```
-</Accordion>
-
-<Accordion title="Generate a shared secret">
-[Generates a new shared secret.](https://developers.avacloud.io/webhooks-api/webhooks/generate-a-shared-secret)
-```bash
-curl --request POST \
-     --url https://glacier-api.avax.network/v1/webhooks:generateOrRotateSharedSecret \
-     --header 'accept: application/json'
-```
-
-</Accordion>
-
-<Accordion title="Get a shared secret">
-[Get a previously generated shared secret.](https://developers.avacloud.io/webhooks-api/webhooks/get-a-shared-secret)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/webhooks:getSharedSecret \
-     --header 'accept: application/json'
-```
-
-</Accordion>
-
-<Accordion title="Add addresses to webhook">
-[Add addresses to webhook.](https://developers.avacloud.io/webhooks-api/webhooks/add-addresses-to-webhook)
-```bash
-curl --request PATCH \
-     --url https://glacier-api.avax.network/v1/webhooks/id/addresses \
-     --header 'accept: application/json' \
-     --header 'content-type: application/json'
-```
-</Accordion>
-
-<Accordion title="Remove addresses to webhook">
-[Remove addresses from webhook.](https://developers.avacloud.io/webhooks-api/webhooks/remove-addresses-from-webhook)
-```bash
-curl --request DELETE \
-     --url https://glacier-api.avax.network/v1/webhooks/id/addresses \
-     --header 'accept: application/json' \
-     --header 'content-type: application/json'
-```
-
-</Accordion>
-
-<Accordion title="List addresses by webhook">
-[List adresses by webhook.](https://developers.avacloud.io/webhooks-api/webhooks/list-adresses-by-webhook)
-```bash
-curl --request GET \
-     --url https://glacier-api.avax.network/v1/webhooks/id/addresses \
-     --header 'accept: application/json'
-```
-
-</Accordion>
-
-
-</Accordions>
\ No newline at end of file
diff --git a/content/course/avacloudapis/03-environment-setup/01-avacloud-account.mdx b/content/course/avacloudapis/03-environment-setup/01-avacloud-account.mdx
deleted file mode 100644
index 6f033b9f..00000000
--- a/content/course/avacloudapis/03-environment-setup/01-avacloud-account.mdx
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: Create API Key
-description: Get an API key for AvaCloud
-updated: 2024-09-03
-authors: [owenwahlgren]
-icon: Book
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-
-## Get an AvaCloud API Key
-
-In order to utilize your accounts rate limits, you will need to make API requests with an API key. You can generate API Keys from the [AvaCloud portal](https://app.avacloud.io/glacier-api/).
-
-<Steps>
-
-<Step>
-Create an account on [AvaCloud](https://avacloud.io).
-</Step>
-
-<Step>
-Click on the `Web3 Data API` [tab](https://app.avacloud.io/glacier-api/).
-![](/course-images/avacloudsdk/create-api-key.png)
-</Step>
-
-<Step>
-Click `+ Add API Key` and create a new name for your API key.
-![](/course-images/avacloudsdk/name-api-key.png)
-</Step>
-
-<Step>
-**Save your API key** in a secure location. We will need it in the next step.
-![](/course-images/avacloudsdk/grab-api-key.png)
-</Step>
-
-</Steps>
-
-After generating the API keys the AvaCloud page should look like this:
-![](/course-images/avacloudsdk/final-api-key.png)
-
-Once you've created and retrieved the key, you will be able to make authenticated queries by passing in your API key in the `x-glacier-api-key` header of your HTTP request.
-
-An example curl request to the Data API:
-
-```bash
-curl -H "Content-Type: Application/json" -H "x-glacier-api-key: <your_api_key>" \
-  "https://glacier-api.avax.network/v1/chains"
-```
\ No newline at end of file
diff --git a/content/course/avacloudapis/03-environment-setup/02-setup-starter-kit.mdx b/content/course/avacloudapis/03-environment-setup/02-setup-starter-kit.mdx
deleted file mode 100644
index bdf6aa05..00000000
--- a/content/course/avacloudapis/03-environment-setup/02-setup-starter-kit.mdx
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: Setup AvaCloudSDK Starter Kit
-description: Set up the AvaCloudSDK Starter Kit in a GitHub Codespace
-updated: 2024-09-03
-authors: [owenwahlgren]
-icon: Book
----
-import Link from 'next/link';
-import { cn } from '@/utils/cn';
-import { buttonVariants } from '@/components/ui/button.tsx'
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-In this course we will run the AvaCloudSDK Starter Kit in a Github Codepsace. This is the quickest way to get started.
-
-The `AvaCloudSDK Starter Kit` contains everything we need to get started quickly with the AvaCloud API. 
-
-<Steps>
-<Step>
-
-### Open the AvaCloudSDK Starter Kit Github Repository:
-**Make sure you are on the `follow-along` branch!**
-
-<Link
-    href="https://github.com/ava-labs/glacier-starter-kit/tree/follow-along"
-    className={cn(
-    buttonVariants({ variant: 'default', className: 'mt-4' }),
-    )}
-    target='_blank'
->Open AvaCloudSDK Starter Kit</Link>
-
-</Step>
-<Step>
-
-### Create a Codespace
-- Click the green **Code** button
-- Switch to the **Codespaces** tab
-- Click **Create Codespace on main** or if you already have a Codespace click the plus (**+**) button
-
-The Codespace will open in a new tab. Wait a few minutes until it's fully built.
-
-</Step>
-<Step>
-
-### Verify everything is working correctly
-
-Open the terminal with `` Ctrl + ` `` or by opening it through the menu:
-
-![](/course-images/avacloudsdk/terminal.png)
-
-</Step>
-<Step>
-
-### Set the `AVACLOUD_API_KEY` environment variable
-Create a `.env` file in the root of the project and add your API key from [the previous step](/course/avacloudapis/03-environment-setup/01-avacloud-account):
-
-```bash
-AVACLOUD_API_KEY=ac_rGIKESl9_9DWuLfJJQLSV5nlzbKR7eHxym6XW3XEQJeNBDRxI...
-```
-
-</Step>
-<Step>
-### Start the NextJS app
-Now we can run the NextJS app in hot reload mode:
-    
-```bash
-yarn dev
-```
-
-It should preview within the Codespace:
-![](/course-images/avacloudsdk/site-running.png)
-
-</Step>
-<Step>
-
-
-
-### Optional: Open Codespace locally in Visual Studio Code
-
-You can switch any time from the browser IDE to Visual Studio Code:
-
-![](/course-images/avacloudsdk/vs-code.png)
-
-The first time you switch, you will be asked to install the [Codespaces extension](https://marketplace.visualstudio.com/items?itemName=GitHub.codespaces) and connect VS Code to you GitHub account, if it is not already connceted.
-
-</Step>
-</Steps>
\ No newline at end of file
diff --git a/content/course/avacloudapis/03-environment-setup/03-what-we-build.mdx b/content/course/avacloudapis/03-environment-setup/03-what-we-build.mdx
deleted file mode 100644
index 24fa5bd0..00000000
--- a/content/course/avacloudapis/03-environment-setup/03-what-we-build.mdx
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title: Time to Build!
-description: Learn about what we will build in this course
-updated: 2024-09-03
-authors: [owenwahlgren]
-icon: Book
----
-
-### Finished Setup
-Once your environment is set up, we can start building some applications using the AvaCloud API and the AvaCloudSDK. The home page should look like this:
-![](/course-images/avacloudsdk/preview.png)
-
-### What We Will Build
-Here is a brief overview of what we will be building in this course:
-
-- ERC-20 Balance App
-- Wallet Portfolio App
-- Block Explorer App
-
-Each of these applications will utilize the Data API to get data from the Avalanche network. We will fetch data such as ERC-20 token balances, NFT balances, recent transactions from an address, block information and much more.
\ No newline at end of file
diff --git a/content/course/avacloudapis/04-erc20-token-balance-app/01-overview.mdx b/content/course/avacloudapis/04-erc20-token-balance-app/01-overview.mdx
deleted file mode 100644
index 0657b7a2..00000000
--- a/content/course/avacloudapis/04-erc20-token-balance-app/01-overview.mdx
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Overview
-description: Use the AvaCloud Data API to create a simple web app that displays a user's ERC-20 token balances.
-updated: 2024-09-13
-authors: [owenwahlgren]
-icon: Book
----
-
-In this section we will use the Data API to create a simple web app that displays a user's ERC-20 token portfolio. This app will allow users to input their Avalanche C-Chain address and view a list of their ERC-20 token balances.
-
-![](/course-images/avacloudsdk/balance-app.png)
-We will use two endpoints from the Data API to accomplish this:
-
-- [`data.evm.blocks.getLatestBlocks`](https://developers.avacloud.io/data-api/evm-blocks/list-latest-blocks)
-- [`data.evm.balances.listErc20Balances`](https://developers.avacloud.io/data-api/evm-balances/list-erc-20-balances)
diff --git a/content/course/avacloudapis/04-erc20-token-balance-app/02-understanding-code.mdx b/content/course/avacloudapis/04-erc20-token-balance-app/02-understanding-code.mdx
deleted file mode 100644
index 2245891e..00000000
--- a/content/course/avacloudapis/04-erc20-token-balance-app/02-understanding-code.mdx
+++ /dev/null
@@ -1,115 +0,0 @@
----
-title: Understanding the Code
-description: Before we start coding, let's take a look at the code we will be working with.
-updated: 2024-09-13
-authors: [owenwahlgren]
-icon: Book
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-There will be two main files that we will be working with in this section.
-
-<Steps>
-<Step>
-
-### `Page.tsx`
-This is the code that will be rendered on the client side, as distinguished by `"use client";` at the top of the file. It contains the React components that will be displayed to the user and is responsible for making the API calls to our backend, which in turn calls the Data API.
-
-It is important to understand that when you `"use client"` in a NextJS project, it will be rendered on the client side. This means that the code will be executed in the user's browser and not on the server. This is important to keep in mind when working with sensitive data or when you want to keep your API keys secure.
-
-Besides this, we have two main functions that we will be working with in this file:
-
-<Steps>
-<Step>
-
-```tsx title="src/app/balance-app/page.tsx"
-const handleSetAddress = async () => {
-  //
-  // TODO: Implement handleSetAddress
-  //
-};
-```
-`handleSetAddress` is a simple function that will be called when the user clicks the "Set Address" button. It will ensure the address is valid then set the inputted address to the React State. Next, we call our next function `fetchERC20Balances` to get the user's balance.
-
-</Step>
-<Step>
-
-```tsx title="src/app/balance-app/page.tsx"
-const fetchERC20Balances = async (address: string) => {
-  //
-  // TODO: Implement fetchERC20Balances
-  //
-};
-```
-
-`fetchERC20Balances` is a function that will make a call to our backend to get the user's ERC-20 token balances. It will first get the current block height, then call the `listErc20Balances` method on our backend with the user's address and the block height. It will then return the balances as an array of `Erc20TokenBalance` objects.
-
-</Step>
-</Steps>
-
-</Step>
-<Step>
-
-### `Route.ts`
-This code will be executed on the server side, as distinguished by `"use server";` at the top of the file. It contains the code that will be executed on the server side and is responsible for making the API calls to the Data API.
-
-There are a few key components to understand in this file:
-
-<Steps>
-<Step>
-```tsx title="src/app/api/balance/route.ts"
-import { AvaCloudSDK } from "@avalabs/avacloud-sdk";
-const avaCloudSDK = new AvaCloudSDK({
-  apiKey: process.env.AVACLOUD_API_KEY,
-  chainId: "43114", // Avalanche Mainnet
-  network: "mainnet",
-});
-```
-Here we initialize the `AvaCloudSDK` with our AvaCloud API key and the chainId of `43114` for the Avalanche Mainnet. This will allow us to make calls to the Data API.
-</Step>
-<Step>
-
-```tsx title="src/app/api/balance/route.ts"
-export async function GET(request: Request) {
-  const { searchParams } = new URL(request.url)
-  const method = searchParams.get('method')
-  try {
-    let result
-    switch (method) {
-      case 'getBlockHeight':
-        result = await getBlockHeight()
-        break
-      case 'listErc20Balances':
-        const address: string = searchParams.get('address')!
-        const blockNumber: string = searchParams.get('blockNumber')!
-        result = await listErc20Balances(address, blockNumber);
-        break
-      default:
-        return NextResponse.json({ error: 'Invalid method' }, { status: 400 })
-    }
-    return NextResponse.json(result)
-  } catch (error) {
-    return NextResponse.json({ error: 'Internal Server Error' }, { status: 500 })
-  }
-}
-```
-Here we define the internal API methods for our backend. We have two methods that we will be working with in this section: `getBlockHeight` and `listErc20Balances`. We create both of these methods internally, then forward the request to the Data API. We then return the result to the client.
-</Step>
-<Step>
-```tsx title="src/app/api/balance/route.ts"
-async function getBlockHeight() {
-   //
-   // TODO: Implement getBlockHeight
-   //
-}
-async function listErc20Balances(address: string, blockNumber: string) {
-   //
-   // TODO: Implement listErc20Balances
-   //
-}
-```
-In the next section, we will implement the `listErc20Balances` and `getBlockHeight` function to call the Data API through the AvaCloudSDK.
-</Step>
-</Steps>
-</Step> 
-</Steps> 
\ No newline at end of file
diff --git a/content/course/avacloudapis/04-erc20-token-balance-app/03-modifying-code.mdx b/content/course/avacloudapis/04-erc20-token-balance-app/03-modifying-code.mdx
deleted file mode 100644
index e50e61b9..00000000
--- a/content/course/avacloudapis/04-erc20-token-balance-app/03-modifying-code.mdx
+++ /dev/null
@@ -1,108 +0,0 @@
----
-title: Modifying the Code
-description: Lets modify the code to implement the Data API.
-updated: 2024-09-13
-authors: [owenwahlgren]
-icon: Book
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-In this section we will modify the code to implement the Data API.
-
-### Modify Backend `src/app/api/balance/route.ts`
-
-<Steps>
-<Step>
-First we will implement the `getBlockHeight` function. The goal of this function is to fetch recent blocks from the Data API then to return the highest block in the first position.
-
-<Accordions>
-<Accordion title="Hint">
-Reference the [AvaCloud SDK documentation](https://developers.avacloud.io/data-api/evm-blocks/list-latest-blocks) to see how to fetch the latest blocks.
-</Accordion>
-<Accordion title="Solution">
-```tsx title="src/app/api/balance/route.ts"
-async function getBlockHeight() {
-    const result = await avaCloudSDK.data.evm.blocks.getLatestBlocks({
-        pageSize: 1,
-      });
-    return result.result.blocks[0].blockNumber
-}
-```
-</Accordion>
-</Accordions>
-</Step>
-<Step>
-Next we will implement the `listErc20Balances` function. The goal of this function is to fetch the ERC-20 token balances for a given address at a specific block height.
-<Accordions>
-<Accordion title="Hint">
-Reference the [AvaCloud SDK documentation](https://developers.avacloud.io/data-api/evm-balances/list-erc-20-balances) to see how to fetch ERC-20 token balances.
-Note the `Erc20TokenBalance` type that is imported, we should use this to combine paged results.
-</Accordion>
-<Accordion title="Solution">
-```tsx title="src/app/api/balance/route.ts"
-async function listErc20Balances(address: string, blockNumber: string) {
-    const result = await avaCloudSDK.data.evm.balances.listErc20Balances({
-        blockNumber: blockNumber,
-        pageSize: 10,
-        address: address,
-      });
-    const balances: Erc20TokenBalance[] = [];
-    for await (const page of result) {
-        balances.push(...page.result.erc20TokenBalances);
-    }
-    return balances
-}
-```
-</Accordion>
-</Accordions>
-</Step>
-</Steps>
-### Modify Frontend `src/app/balance-app/page.tsx`
-
-<Steps>
-<Step>
-</Step>
-<Step>
-First we will implement the `fetchERC20Balances` function. The goal of this function is to make a call to our backend to get the user's ERC-20 token balances.
-<Accordions>
-<Accordion title="Hint">
-Make a call to our backend first for the most recent block height, then our `listErc20Balances` API. Finally return the results.
-</Accordion>
-<Accordion title="Solution">
-```tsx title="src/app/balance-app/page.tsx"
-const fetchERC20Balances = async (address: string) => {
-    const blockResult = await fetch("api/balance?method=getBlockHeight");
-    const blockNumber = await blockResult.json();
-    const balanceResult = await fetch("api/balance?method=listErc20Balances&address=" + address + "&blockNumber=" + blockNumber);
-    const balances = await balanceResult.json();
-    return balances as Erc20TokenBalance[];
-};
-```
-</Accordion>
-</Accordions>
-</Step>
-<Step>
-Next we will implement the `handleSetAddress` function. The goal of this function is to set the address in the state and fetch the ERC-20 token balances for that address using our `fetchERC20Balances` function.
-<Accordions>
-<Accordion title="Hint">
-First make sure the address is valid, then update the state for `Address` and `Balances`
-</Accordion>
-<Accordion title="Solution">
-```tsx title="src/app/balance-app/page.tsx"
-const handleSetAddress = async () => {
-    const addressInput = document.getElementById("address") as HTMLInputElement;
-    const address = addressInput.value;
-    const addressPattern = /^0x[a-fA-F0-9]{40}$/;  
-
-    if (addressInput && addressPattern.test(address)) {
-      setAddress(address);
-      setBalances(await fetchERC20Balances(address));
-    }
-};
-```
-</Accordion>
-</Accordions>
-</Step>
-
-
-</Steps>
diff --git a/content/course/avacloudapis/04-erc20-token-balance-app/04-final.mdx b/content/course/avacloudapis/04-erc20-token-balance-app/04-final.mdx
deleted file mode 100644
index 4c225ddc..00000000
--- a/content/course/avacloudapis/04-erc20-token-balance-app/04-final.mdx
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title: Final Result
-description: The final result of the ERC-20 token balance app.
-updated: 2024-09-03
-authors: [owenwahlgren]
-icon: Book
----
-
-If we implemented the code correctly, we should have a working ERC-20 token balance app that displays the user's token balances. The app will look like the following:
-![](/course-images/avacloudsdk/balance-app-init.png)
-
-After setting the address field, the app will display the user's ERC-20 token balances:
-
-![](/course-images/avacloudsdk/balance-app.png)
-
-Notice how the app also displays images for each token. This is done by fetching the token metadata from `listErc20Balances` and displaying the token's logo.
\ No newline at end of file
diff --git a/content/course/avacloudapis/05-wallet-portfolio-app/01-overview.mdx b/content/course/avacloudapis/05-wallet-portfolio-app/01-overview.mdx
deleted file mode 100644
index d65df818..00000000
--- a/content/course/avacloudapis/05-wallet-portfolio-app/01-overview.mdx
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Overview
-description: Use the Data API to create a simple web app that displays data and metrics on a connected wallet.
-updated: 2024-09-13
-authors: [owenwahlgren]
-icon: Book
----
-
-In this section we will expand on the ERC-20 Balance App with NFTs (ERC-721) and ERC-1155 tokens. We will also add a connect wallet button to allow users to connect their own wallet and view their own token balances.
-
-Here is a preview of what we will build:
-![](/course-images/avacloudsdk/nfts.png)
-![](/course-images/avacloudsdk/tokens.png)
-
-We will use a few additional endpoints from the Data API to accomplish this:
-
-- [`data.evm.blocks.listErc721Balances`](https://developers.avacloud.io/data-api/evm-balances/list-erc-721-balances)
-- [`data.evm.balances.listErc1155Balances`](https://developers.avacloud.io/data-api/evm-balances/list-erc-1155-balances)
-- [`data.evm.transactions.listTransactions`](https://developers.avacloud.io/data-api/evm-transactions/list-transactions)
\ No newline at end of file
diff --git a/content/course/avacloudapis/05-wallet-portfolio-app/02-understanding-code.mdx b/content/course/avacloudapis/05-wallet-portfolio-app/02-understanding-code.mdx
deleted file mode 100644
index eb7a4211..00000000
--- a/content/course/avacloudapis/05-wallet-portfolio-app/02-understanding-code.mdx
+++ /dev/null
@@ -1,149 +0,0 @@
----
-title: Understanding the Code
-description: Before we start coding, let's take a look at the code we will be working with.
-updated: 2024-09-13
-authors: [owenwahlgren]
-icon: Book
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-There will be two main files that we will be working with in this section.
-
-<Steps>
-<Step>
-
-### `Page.tsx`
-This is the code that will be rendered on the client side, as distinguished by `"use client";` at the top of the file. It contains the React components that will be displayed to the user and is responsible for making the API calls to our backend, which in turn calls the Data API.
-
-It is important to understand that when you `"use client"` in a NextJS project, it will be rendered on the client side. This means that the code will be executed in the user's browser and not on the server. This is important to keep in mind when working with sensitive data or when you want to keep your API keys secure.
-
-Besides this, we have three main functions that we will be working with in this file:
-
-<Steps>
-<Step>
-```tsx title="src/app/basic-wallet/page.tsx"
-const fetchERC721Balances = async (address: string) => {
-    //
-    // TODO: Implement this!
-    //
-    return [] as Erc721TokenBalance[];
-  }
-```
-`fetchERC721Balances` is a function that will make a call to our backend to get the user's ERC-721 token balances. It will call the `listErc721Balances` method on our backend with the user's address. It will then return the balances as an array of `Erc721TokenBalance` objects.
-
-</Step>
-<Step>
-```tsx title="src/app/basic-wallet/page.tsx"
-const fetchERC1155Balances = async (address: string) => {
-     //
-    // TODO: Implement this!
-    //
-    return [] as Erc1155TokenBalance[];
-  }
-```
-
-`fetchERC1155Balances` is a function that will make a call to our backend to get the user's ERC-1155 token balances. It will call the `listErc1155Balances` method on our backend with the user's address. It will then return the balances as an array of `Erc1155TokenBalance` objects.
-
-</Step>
-<Step>
-```tsx title="src/app/basic-wallet/page.tsx"
-  const fetchRecentTransactions = async (address: string) => {
-    //
-    // TODO: Implement this!
-    //
-    return {} as TransactionDetails;
-  }
-```
-`fetchRecentTransactions` is a function that will make a call to our backend to get the user's recent transactions for all tokens. It will call the `listRecentTransactions` method on our backend with the user's address. It will then return the balances as an object of type `TransactionDetails`.
-
-</Step>
-</Steps>
-
-</Step>
-<Step>
-
-### `Route.ts`
-This code will be executed on the server side, as distinguished by `"use server";` at the top of the file. It contains the code that will be executed on the server side and is responsible for making the API calls to the Data API.
-
-There are a few key components to understand in this file:
-
-<Steps>
-<Step>
-```tsx title="src/app/api/wallet/route.ts"
-import { AvaCloudSDK } from "@avalabs/avacloud-sdk";
-const avaCloudSDK = new AvaCloudSDK({
-  apiKey: process.env.AVACLOUD_API_KEY,
-  chainId: "43114", // Avalanche Mainnet
-  network: "mainnet",
-});
-```
-Here we initialize the `AvaCloudSDK` with our AvaCloud API key and the chainId of `43114` for the Avalanche Mainnet. This will allow us to make calls to the Data API.
-</Step>
-<Step>
-
-```tsx title="src/app/api/wallet/route.ts"
-export async function GET(request: Request) {
-  const { searchParams } = new URL(request.url)
-  const method = searchParams.get('method')
-  let address
-  try {
-    let result
-    switch (method) {
-      case 'listERC721Balances':
-        address = searchParams.get('address')!
-        result = await listERC721Balances(address)
-        break
-      case 'listERC1155Balances':
-        address = searchParams.get('address')!
-        result = await listErc1155Balances(address)
-        break
-      case 'listRecentTransactions':
-        address = searchParams.get('address')!
-        result = await listRecentTransactions(address)
-        break
-      default:
-        return NextResponse.json({ error: 'Invalid method' }, { status: 400 })
-    }
-    return NextResponse.json(result)
-  } catch (error) {
-    return NextResponse.json({ error: 'Internal Server Error' }, { status: 500 })
-  }
-}
-```
-Here we define the internal API methods for our backend. We have two methods that we will be working with in this section: `getBlockHeight`, `listERC721Balances`, `listErc1155Balances` and `listRecentTransactions`. We create all of these methods internally, then forward the request to the Data API. We then return the result to the client.
-</Step>
-<Step>
-```tsx title="src/app/api/wallet/route.ts"
-async function getBlockHeight() {
-    //
-    // TODO: Implement this!
-    //
-    return
-}
-
-const listERC721Balances = async (address: string) => {
-    //
-    // TODO: Implement this!
-    //
-    return
-}
-
-const listErc1155Balances = async (address: string) => {
-    //
-    // TODO: Implement this!
-    //
-    return
-}
-
-const listRecentTransactions = async (address: string) => {
-    //
-    // TODO: Implement this!
-    //
-    return
-}
-```
-In the next section, we will implement these functions to call the Data API through the AvaCloudSDK.
-</Step>
-</Steps>
-</Step> 
-</Steps> 
\ No newline at end of file
diff --git a/content/course/avacloudapis/05-wallet-portfolio-app/03-modifying-code.mdx b/content/course/avacloudapis/05-wallet-portfolio-app/03-modifying-code.mdx
deleted file mode 100644
index 2f7cb2f0..00000000
--- a/content/course/avacloudapis/05-wallet-portfolio-app/03-modifying-code.mdx
+++ /dev/null
@@ -1,238 +0,0 @@
----
-title: Modifying the Code
-description: Lets modify the code to implement the Data API.
-updated: 2024-09-13
-authors: [owenwahlgren]
-icon: Book
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-In this section, we will modify the code to implement the Data API. 
-
-### Modify Backend `src/app/api/wallet/route.ts`
-<Steps>
-<Step>
-First we will implement the `getBlockHeight` function. This function is the same as the one in ERC20 Balance App, but we will repeat it for the sake of the tutorial. The goal of this function is to fetch recent blocks from the Data API then to return the highest block in the first position.
-
-<Accordions>
-<Accordion title="Hint">
-Reference the [AvaCloud SDK documentation](https://developers.avacloud.io/data-api/evm-blocks/list-latest-blocks) to see how to fetch the latest blocks.
-</Accordion>
-<Accordion title="Solution">
-```tsx title="src/app/api/wallet/route.ts"
-async function getBlockHeight() {
-    const result = await avaCloudSDK.data.evm.blocks.getLatestBlocks({
-        pageSize: 1,
-      });
-    return result.result.blocks[0].blockNumber
-}
-```
-</Accordion>
-</Accordions>
-</Step>
-<Step>
-Next we will implement the `listERC721Balances` function. The goal of this function is to fetch the ERC-721 token balances for a given address.
-<Accordions>
-<Accordion title="Hint">
-Reference the [AvaCloud SDK documentation](https://developers.avacloud.io/data-api/evm-balances/list-erc-721-balances) to see how to fetch ERC-721 token balances.
-Note the `Erc721TokenBalance` type that is imported, we should use this to combine paged results.
-</Accordion>
-<Accordion title="Solution">
-```tsx title="src/app/api/wallet/route.ts"
-const listERC721Balances = async (address: string) => {
-    const result = await avaCloudSDK.data.evm.balances.listErc721Balances({
-        pageSize: 10,
-        address: address,
-      });
-    const balances: Erc721TokenBalance[] = [];
-    for await (const page of result) {
-        balances.push(...page.result.erc721TokenBalances);
-    }
-    return balances
-}
-```
-</Accordion>
-</Accordions>
-</Step>
-<Step>
-Now we will implement the `listErc1155Balances` function. The goal of this function is to fetch the ERC-1155 token balances for a given address.
-<Accordions>
-<Accordion title="Hint">
-Reference the [AvaCloud SDK documentation](https://developers.avacloud.io/data-api/evm-balances/list-erc-1155-balances) to see how to fetch ERC-1155 token balances.
-Note the `Erc1155TokenBalance` type that is imported, we should use this to combine paged results.
-</Accordion>
-<Accordion title="Solution">
-```tsx title="src/app/api/wallet/route.ts"
-const listErc1155Balances = async (address: string) => {
-    const result = await avaCloudSDK.data.evm.balances.listErc1155Balances({
-        pageSize: 10,
-        address: address,
-      });
-    const balances: Erc1155TokenBalance[] = [];
-    for await (const page of result) {
-        balances.push(...page.result.erc1155TokenBalances);
-    }
-    return balances
-}
-```
-</Accordion>
-</Accordions>
-</Step>
-
-<Step>
-Finally we will implement the `listRecentTransactions` function. The goal of this function is to fetch recent transactions for a given address given a block start and end.
-<Accordions>
-<Accordion title="Hint">
-Reference the [AvaCloud SDK documentation](https://developers.avacloud.io/data-api/evm-transactions/list-transactions) to see how to fetch recent transactions.
-Note the `TransactionDetails` type that is imported, we should use this to combine and sort paged results.
-</Accordion>
-<Accordion title="Solution">
-```tsx title="src/app/api/wallet/route.ts"
-const listRecentTransactions = async (address: string) => {
-    const blockHeight = await getBlockHeight()
-    const result = await avaCloudSDK.data.evm.transactions.listTransactions({
-        pageSize: 10,
-        startBlock: blockHeight - 100000,
-        endBlock: blockHeight,
-        address: address,
-        sortOrder: "desc",
-      });
-    const transactions: TransactionDetails = {
-        erc20Transfers: [],
-        erc721Transfers: [],
-        erc1155Transfers: [],
-        nativeTransaction: {
-            blockNumber: '',
-            blockTimestamp: 0,
-            blockHash: '',
-            blockIndex: 0,
-            txHash: '',
-            txStatus: '',
-            txType: 0,
-            gasLimit: '',
-            gasUsed: '',
-            gasPrice: '',
-            nonce: '',
-            from: {
-                name: undefined,
-                symbol: undefined,
-                decimals: undefined,
-                logoUri: undefined,
-                address: ''
-            },
-            to: {
-                name: undefined,
-                symbol: undefined,
-                decimals: undefined,
-                logoUri: undefined,
-                address: ''
-            },
-            value: ''
-        },
-    }
-    for await (const page of result) {
-        for (const transaction of page.result.transactions) {
-            if (transaction.erc20Transfers) {
-                if (transactions.erc20Transfers) {
-                    transactions.erc20Transfers.push(...transaction.erc20Transfers);
-                }
-            } 
-            else if (transaction.erc721Transfers) {
-                if (transactions.erc721Transfers) {
-                    transactions.erc721Transfers.push(...transaction.erc721Transfers);
-                }
-            }
-            else if (transaction.erc1155Transfers) {
-                if (transactions.erc1155Transfers) {
-                    transactions.erc1155Transfers.push(...transaction.erc1155Transfers);
-                }
-            }
-        }
-    }
-    return transactions
-}
-```
-</Accordion>
-</Accordions>
-</Step>
-
-
-</Steps>
-### Modify Frontend `src/app/basic-wallet/page.tsx`
-Now we will modify the frontend to make calls to our backend.
-<Steps>
-<Step>
-</Step>
-<Step>
-First we will implement the `fetchERC20Balances` function. The goal of this function is to make a call to our backend to get the user's ERC-20 token balances.
-<Accordions>
-<Accordion title="Hint">
-Make a call to our backend first for the most recent block height, then our `listErc20Balances` API. Finally return the results.
-</Accordion>
-<Accordion title="Solution">
-```tsx title="src/app/basic-wallet/page.tsx"
-const fetchERC20Balances = async (address: string) => {
-    const blockResult = await fetch("api/balance?method=getBlockHeight");
-    const blockNumber = await blockResult.json();
-    const balanceResult = await fetch("api/balance?method=listErc20Balances&address=" + address + "&blockNumber=" + blockNumber);
-    const balances = await balanceResult.json();
-    return balances as Erc20TokenBalance[];
-};
-```
-</Accordion>
-</Accordions>
-</Step>
-<Step>
-Next we will implement the `fetchERC721Balances` function. The goal of this function is to call our `listErc721Balances` function on the backend and return it as a `Erc721TokenBalance` array.
-<Accordions>
-<Accordion title="Hint">
-Make a call to our backend then parse the result as json. Return it as `Erc721TokenBalance[]`.
-</Accordion>
-<Accordion title="Solution">
-```tsx title="src/app/basic-wallet/page.tsx"
-const fetchERC721Balances = async (address: string) => {
-    const result = await fetch(`api/wallet?method=listERC721Balances&address=${address}`);
-    const balances = await result.json();
-    return balances as Erc721TokenBalance[];
-  }
-```
-</Accordion>
-</Accordions>
-</Step>
-
-<Step>
-Now we will implement the `fetchERC1155Balances` function. The goal of this function is to call our `listERC1155Balances` function on the backend and return it as a `Erc1155TokenBalance` array.
-<Accordions>
-<Accordion title="Hint">
-Make a call to our backend then parse the result as json. Return it as `Erc1155TokenBalance[]`.
-</Accordion>
-<Accordion title="Solution">
-```tsx title="src/app/basic-wallet/page.tsx"
-const fetchERC1155Balances = async (address: string) => {
-    const result = await fetch(`api/wallet?method=listERC1155Balances&address=${address}`);
-    const balances = await result.json();
-    return balances as Erc1155TokenBalance[];
-  }
-```
-</Accordion>
-</Accordions>
-</Step>
-
-<Step>
-Finally we will implement the `fetchRecentTransactions` function. The goal of this function is to call our `listRecentTransactions` function on the backend and return it as an object of type `TransactionDetails`.
-<Accordions>
-<Accordion title="Hint">
-Make a call to our backend then parse the result as json. Return it as type of `TransactionDetails`.
-</Accordion>
-<Accordion title="Solution">
-```tsx title="src/app/basic-wallet/page.tsx"
-const fetchRecentTransactions = async (address: string) => {
-    const result = await fetch(`api/wallet?method=listRecentTransactions&address=${address}`);
-    const transactions = await result.json();
-    return transactions as TransactionDetails;
-  }
-```
-</Accordion>
-</Accordions>
-</Step>
-</Steps>
\ No newline at end of file
diff --git a/content/course/avacloudapis/06-block-explorer-app/01-overview.mdx b/content/course/avacloudapis/06-block-explorer-app/01-overview.mdx
deleted file mode 100644
index 14b74c3d..00000000
--- a/content/course/avacloudapis/06-block-explorer-app/01-overview.mdx
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Overview
-description: Use the Data API to create a simple block explorer.
-updated: 2024-09-13
-authors: [owenwahlgren]
-icon: Book
----
-In this section we will build a basic block explorer using the Data API.
-
-![](/course-images/avacloudsdk/explorer.png)
-
-We will use a couple additional endpoints from the Data API to accomplish this:
-
-- [`data.evm.blocks.getLatestBlocks`](https://developers.avacloud.io/data-api/evm-blocks/list-latest-blocks)
-- [`data.evm.transactions.listLatestTransactions`](https://developers.avacloud.io/data-api/evm-transactions/list-latest-transactions)
\ No newline at end of file
diff --git a/content/course/avacloudapis/06-block-explorer-app/02-understanding-code.mdx b/content/course/avacloudapis/06-block-explorer-app/02-understanding-code.mdx
deleted file mode 100644
index 0dd1a233..00000000
--- a/content/course/avacloudapis/06-block-explorer-app/02-understanding-code.mdx
+++ /dev/null
@@ -1,114 +0,0 @@
----
-title: Understanding the Code
-description: Before we start coding, let's take a look at the code we will be working with.
-updated: 2024-10-09
-authors: [owenwahlgren]
-icon: Book
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-There will be two main files that we will be working with in this section.
-
-<Steps>
-<Step>
-
-### `Page.tsx`
-This is the code that will be rendered on the client side, as distinguished by `"use client";` at the top of the file. It contains the React components that will be displayed to the user and is responsible for making the API calls to our backend, which in turn calls the Data API.
-
-It is important to understand that when you `"use client"` in a NextJS project, it will be rendered on the client side. This means that the code will be executed in the user's browser and not on the server. This is important to keep in mind when working with sensitive data or when you want to keep your API keys secure.
-
-Besides this, we have three main functions that we will be working with in this file:
-
-<Steps>
-<Step>
-```tsx title="src/app/basic-explorer/page.tsx"
-const fetchRecentTransactions = async () => {
-    //
-    // TODO: Implement this!
-    //
-    return data as NativeTransaction[]
-  }
-```
-`fetchRecentTransactions` is a function that will make a call to our backend to get the most recent transactions from the chain. It will call the `getRecentTransactions` method on our backend. It will then return the transactions as an array of `NativeTransaction` objects.
-
-</Step>
-<Step>
-```tsx title="src/app/basic-explorer/page.tsx"
-const fetchRecentBlocks = async () => {
-    //
-    // TODO: Implement this!
-    //
-    return data as EvmBlock[]
-  }
-```
-
-`fetchRecentBlocks` is a function that will make a call to our backend to get the most recent blocks from the chain. It will call the `getRecentBlocks` method on our backend. It will then return the blocks as an array of `EvmBlock` objects.
-
-</Step>
-</Steps>
-
-</Step>
-<Step>
-
-### `Route.ts`
-This code will be executed on the server side, as distinguished by `"use server";` at the top of the file. It contains the code that will be executed on the server side and is responsible for making the API calls to the Data API.
-
-There are a few key components to understand in this file:
-
-<Steps>
-<Step>
-```tsx title="src/app/api/explorer/route.ts"
-import { AvaCloudSDK } from "@avalabs/avacloud-sdk";
-const avaCloudSDK = new AvaCloudSDK({
-  apiKey: process.env.AVACLOUD_API_KEY,
-  chainId: "43114", // Avalanche Mainnet
-  network: "mainnet",
-});
-```
-Here we initialize the `AvaCloudSDK` with our AvaCloud API key and the chainId of `43114` for the Avalanche Mainnet. This will allow us to make calls to the Data API.
-</Step>
-<Step>
-
-```tsx title="src/app/api/explorer/route.ts"
-export async function GET(request: Request) {
-  const { searchParams } = new URL(request.url)
-  const method = searchParams.get('method')
-  try {
-    let result
-    switch (method) {
-      case 'getRecentTransactions':
-        result = await getRecentTransactions()
-        break
-      case 'getRecentBlocks':
-        result = await getRecentBlocks()
-        break
-      default:
-        return NextResponse.json({ error: 'Invalid method' }, { status: 400 })
-    }
-    return NextResponse.json(result)
-  } catch (error) {
-    return NextResponse.json({ error: 'Internal Server Error' }, { status: 500 })
-  }
-}
-```
-Here we define the internal API methods for our backend. We have two methods that we will be working with in this section: `getRecentBlocks` and `getRecentTransactions`. We create all of these methods internally, then forward the request to the Data API. We then return the result to the client.
-</Step>
-<Step>
-```tsx title="src/app/api/explorer/route.ts"
-const getRecentBlocks = async () => {
-   //
-    // TODO: Implement this!
-    //
-}
-
-const getRecentTransactions = async () => {
-    //
-    // TODO: Implement this!
-    //
-}
-```
-In the next section, we will implement these functions to call the Data API through the AvaCloudSDK.
-</Step>
-</Steps>
-</Step> 
-</Steps> 
\ No newline at end of file
diff --git a/content/course/avacloudapis/06-block-explorer-app/03-modifying-code.mdx b/content/course/avacloudapis/06-block-explorer-app/03-modifying-code.mdx
deleted file mode 100644
index 4930a249..00000000
--- a/content/course/avacloudapis/06-block-explorer-app/03-modifying-code.mdx
+++ /dev/null
@@ -1,115 +0,0 @@
----
-title: Modifying the Code
-description: Lets modify the code to implement the Data API.
-updated: 2024-10-09
-authors: [owenwahlgren]
-icon: Book
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-In this section we will modify the code to implement the Data API.
-
-### Modify Backend `src/app/api/explorer/route.ts`
-
-<Steps>
-<Step>
-First we will implement the `getRecentBlocks` function. The goal of this function is to fetch recent blocks from the Data API with all its information.
-
-<Accordions>
-<Accordion title="Hint">
-Reference the [AvaCloud SDK documentation](https://developers.avacloud.io/data-api/evm-blocks/list-latest-blocks) to see how to fetch the latest blocks.
-</Accordion>
-<Accordion title="Solution">
-```tsx title="src/app/api/explorer/route.ts"
-const getRecentBlocks = async () => {
-    const result = await avaCloudSDK.data.evm.blocks.getLatestBlocks({
-        pageSize: 1,
-      });
-
-    let count = 0;
-    const blocks: EvmBlock[] = [];
-    for await (const page of result) {
-        if (count === 20) {
-            break;
-        }
-        blocks.push(...page.result.blocks);
-        count++;
-    }
-    return blocks
-}
-```
-</Accordion>
-</Accordions>
-</Step>
-<Step>
-Next we will implement the `getRecentTransactions` function. The goal of this function is to fetch all native token transfers from the Data API.
-<Accordions>
-<Accordion title="Hint">
-Reference the [AvaCloud SDK documentation](https://developers.avacloud.io/data-api/evm-transactions/list-latest-transactions) to see how to fetch latest transactions.
-Note the `NativeTransaction` type that is imported, we should use this to combine paged results.
-</Accordion>
-<Accordion title="Solution">
-```tsx title="src/app/api/explorer/route.ts"
-const getRecentTransactions = async () => {
-    const result = await avaCloudSDK.data.evm.transactions.listLatestTransactions({
-        pageSize: 3,
-    });
-
-    let count = 0;
-    const transactions: NativeTransaction[] = [];
-    for await (const page of result) {
-        if (count === 20) {
-            break;
-        }
-        transactions.push(...page.result.transactions);
-        count++;
-    }
-    return transactions;
-}
-```
-</Accordion>
-</Accordions>
-</Step>
-</Steps>
-### Modify Frontend `src/app/basic-explorer/page.tsx`
-
-<Steps>
-<Step>
-</Step>
-<Step>
-First we will implement the `fetchRecentTransactions` function. The goal of this function is to make a call to our backend to get recent transactions.
-<Accordions>
-<Accordion title="Hint">
-Make a call to our backend first for our `getRecentTransactions` method. Finally return the results.
-</Accordion>
-<Accordion title="Solution">
-```tsx title="src/app/basic-explorer/page.tsx"
-  const fetchRecentTransactions = async () => {
-    const response = await fetch(`/api/explorer?method=getRecentTransactions`)
-    const data = await response.json()
-    return data as NativeTransaction[]
-  }
-```
-</Accordion>
-</Accordions>
-</Step>
-<Step>
-Next we will implement the `fetchRecentBlocks` function. The goal of this function is to make a call to our backend to get recent block information.
-<Accordions>
-<Accordion title="Hint">
-Make a call to our backend first for our `getRecentBlocks` method. Finally return the results.
-</Accordion>
-<Accordion title="Solution">
-```tsx title="src/app/basic-explorer/page.tsx"
-const fetchRecentBlocks = async () => {
-    const response = await fetch(`/api/explorer?method=getRecentBlocks`)
-    const data = await response.json()
-    return data as EvmBlock[]
-  }
-```
-</Accordion>
-</Accordions>
-</Step>
-
-
-</Steps>
diff --git a/content/course/avacloudapis/07-using-webhooks/01-overview.mdx b/content/course/avacloudapis/07-using-webhooks/01-overview.mdx
deleted file mode 100644
index b5e61f50..00000000
--- a/content/course/avacloudapis/07-using-webhooks/01-overview.mdx
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Overview
-description: Coming soon!
-updated: 2024-09-13
-authors: [owenwahlgren]
-icon: Book
----
diff --git a/content/course/avacloudapis/index.mdx b/content/course/avacloudapis/index.mdx
deleted file mode 100644
index ff4587b6..00000000
--- a/content/course/avacloudapis/index.mdx
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title: 👋 Welcome to the Course
-description: Learn about AvaCloud APIs and the AvaCloud SDK.
-updated: 2024-09-03
-authors: [owenwahlgren]
----
-![](/course-banner/avacloudapis.jpg)
-## Why Take This Course?
-
-[AvaCloud APIs](https://developers.avacloud.io/introduction), built by [AvaCloud](https://avacloud.io/), provides Web3 developers with multi-chain data from Avalanche’s primary network and other Avalanche L1s. With the AvaCloud API, you can easily build products that utilize real-time and historical transaction data, transfer records, native and token balances, and various types of token metadata.
-
-## Course Content
-
-- [AvaCloud API Overview](/course/avacloudapis/02-overview/01-about)
-- [Environment Setup](/course/avacloudapis/03-environment-setup/01-avacloud-account)
-- [Build an ERC-20 Token Balance App](/course/avacloudapis/04-erc20-token-balance-app/01-overview)
-- [Build a Wallet Portfolio App](/course/avacloudapis/05-wallet-portfolio-app/01-overview)
-- [Build a Basic Block Explorer](/course/avacloudapis/06-block-explorer-app/01-overview)
-
-## Prerequisites
-
-A general understanding of web development is required. While you won't need to write a lot of code, familiarity with key concepts is important.
-
-- **TypeScript:** Understanding of common concepts, as all exercises will use TypeScript.
-- **React:** Basic understanding of React is required, as all exercises will use React.
-- **NextJS:** Basic understanding of NextJS is required, as all exercises will use NextJS.
-
-## Learning Outcomes
-
-By the end of this course, you will:
-
-- Be familiar with the AvaCloud API including the [Data API](https://developers.avacloud.io/data-api/overview) and [Webhooks API](https://developers.avacloud.io/webhooks-api/overview).
-- Learn how to use the [AvaCloudSDK](https://github.com/ava-labs/avacloud-sdk-typescript) to interact with [AvaCloud APIs](https://developers.avacloud.io/introduction).
-- Build multiple web apps using the [AvaCloudSDK](https://github.com/ava-labs/avacloud-sdk-typescript).
-
diff --git a/content/course/avacloudapis/meta.json b/content/course/avacloudapis/meta.json
deleted file mode 100644
index 7fbf87ec..00000000
--- a/content/course/avacloudapis/meta.json
+++ /dev/null
@@ -1,20 +0,0 @@
-{
-    "title": "AvaCloud APIs",
-    "root": true,
-    "pages": [
-      "index",
-     "---AvaCloud API Overview---",
-     "...02-overview",
-     "---Environment Setup---",
-      "...03-environment-setup",
-     "---Build an ERC-20 Balance App---",
-      "...04-erc20-token-balance-app",
-     "---Build a Wallet Portfolio---",
-      "...05-wallet-portfolio-app",
-     "---Build a Block Explorer---",
-      "...06-block-explorer-app",
-     "---Using Webhooks---",
-      "...07-using-webhooks"
-    ]
-  }
-  
\ No newline at end of file
diff --git a/content/course/avalanche-fundamentals/02-avalanche-consensus-intro/01-avalanche-consensus-intro.mdx b/content/course/avalanche-fundamentals/02-avalanche-consensus-intro/01-avalanche-consensus-intro.mdx
deleted file mode 100644
index 773599dd..00000000
--- a/content/course/avalanche-fundamentals/02-avalanche-consensus-intro/01-avalanche-consensus-intro.mdx
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Avalanche Consensus
-description: Learn how blockchains arrive at consensus using different mechanisms.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
-
-<YouTube id="3cAFxV2AIU8" />
-
-Avalanche Consensus is a novel consensus protocol that is used in the Avalanche network. It is a leaderless, decentralized, and scalable consensus protocol that is used to achieve consensus on the state of the network.
-
-<Quiz quizId="101"/>
-
-## What You Will Learn
-
-In this section, you will go through the following topics:
-
-- **Consensus Mechanisms:** Understand what consensus mechanisms are and how they work
-- **Snowman Consensus:** Learn about the Snowman consensus protocol
-- **TPS vs TTF:** Understand the difference between transactions per second (TPS) and time to finality (TTF)
diff --git a/content/course/avalanche-fundamentals/02-avalanche-consensus-intro/02-consensus-mechanisms.mdx b/content/course/avalanche-fundamentals/02-avalanche-consensus-intro/02-consensus-mechanisms.mdx
deleted file mode 100644
index 84b0eb21..00000000
--- a/content/course/avalanche-fundamentals/02-avalanche-consensus-intro/02-consensus-mechanisms.mdx
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: Consensus Mechanisms
-description: Learn how blockchains arrive at consensus using different mechanisms.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-Consensus plays a crucial role in [blockchain networks](/guide/what-is-a-blockchain) by resolving conflicts and ensuring that all validators agree on the current state of the distributed ledger. The main objective of a consensus mechanism is to create a single version of truth that is universally accepted by network participants.
-
-Validators can reach a consensus by following a set of steps called a consensus protocol. This way, they collectively decide on the state of the system and all state changes. Different consensus mechanisms have different approaches. All aim to ensure that validators reach a majority agreement on network state. 
-
-## Ordering through Consensus
-
-Consensus is needed to agree on the order of state changes in a blockchain. This allows the validators to decide between two conflicting states.
-
-![](/course-images/avalanche-fundamentals/1.png)
-
-<Quiz quizId="102"/>
-
-## Double Spending Attack
-
-A Double Spending Attack is when a user attempts to spend more crypto that they own by creating multiple transactions that reference the same funds.
-
-Let's look at an Example: Alice owns 5 AVAX
-
-![](/course-images/avalanche-fundamentals/2.png)
-
-Now Alice issues two transactions at the same time to different validators:
-
-1. Send 5 AVAX to Bob
-2. Send 5 AVAX to Charly
-
-It is important that there is only a limited notion of time in blockchain systems. Even if Alice does not issue these transactions at the exact same time, validators cannot identify which was issued first.
-
-![](/course-images/avalanche-fundamentals/3.png)
-
-Each of the transaction in itself is valid. Alice owns 5 AVAX and should be able to send them to whomever she wants. However, she should only be able to send the amount she actually owns.
-
-![](/course-images/avalanche-fundamentals/4.png)
-
-Therefore, validators have to collectively come to consensus on which of the two conflicting transactions will be included in the blockchain first, and therefore be accepted by all validators as the next state. To illustrate, we will color the validators preferring Charlie yellow and the validators preferring Bob blue.
-
-<Quiz quizId="103"/>
diff --git a/content/course/avalanche-fundamentals/02-avalanche-consensus-intro/03-snowman-consensus.mdx b/content/course/avalanche-fundamentals/02-avalanche-consensus-intro/03-snowman-consensus.mdx
deleted file mode 100644
index db262fb0..00000000
--- a/content/course/avalanche-fundamentals/02-avalanche-consensus-intro/03-snowman-consensus.mdx
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title: Snowman Consensus
-description: Learn about the Avalanche Snowman consensus protocol.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-Protocols in the Avalanche family operate through repeated sub-sampled voting. When a validator is determining whether a block should be accepted, it asks a small, random subset of validators on their preferences. Based on the responses the validator gets, it might change its own preference.
-
-Let's visualize this with an example. You are a validator in a set of validators that is performing the Avalanche Consensus protocol to agree on whether to send the funds to Charlie (yellow) or to Bob (blue). It is important to understand that none of the validators really cares whether it is going to be yellow or blue, as long as all correctly operating validators decide for the same outcome at the end of the process. The starting preference is chosen random by each validator.
-
-## Changing Preference
-
-You start by sampling the current preference of five other nodes and they reply: 2 prefer yellow (Charlie) and 3 prefer blue (Bob). 
-
-![](/course-images/avalanche-fundamentals/5.png)
-
-Avalanche consensus dictates, that a validator changes its preference if a α-majority of the sampled validators agrees on another option and it goes along with this popular choice. 
-
-Let's set the alpha value to 3 in our example, meaning that we change our preference when 3 out of 5 sampled nodes have another preference. Since 3 out of 5 have replied with blue (Bob) we are changing our own preference to Bob. 
-
-![](/course-images/avalanche-fundamentals/6.png)
-
-From now on you will respond with blue, when another validators queries you for your current preference. 
-
-<Quiz quizId="104"/>
-
-## Consecutive Successes
-
-Avalanche Consensus does not run for a fixed number of rounds, but until a decision threshold is hit. This means the validator keep sampling until their preference is confirmed for beta (β) consecutive rounds.
-
-Now you query another five validators for their preference. Again, three of the five reply with the preference blue (Bob). Since your current preference is confirmed, you increment a counter for consecutive successes by one. You repeat this sampling process until their preference is confirmed for 8 consecutive rounds. 
-
-![](/course-images/avalanche-fundamentals/7.png)
-
-## Parameters of Avalanche Consensus
-
-In our example we used fixed values for how many nodes are sampled, how many are needed to change our preference and how many consecutive rounds of successes we require to finalize our decision. These consensus parameters are formalized in the table below and can be chosen by every node individually to meet their needs.
-
-|Symbol|Name|Range|Explanation|
-|---|---|---|---|
-|n  |Number of Participants|1 to ∞|How many participants take part in the system?|
-|k  |Sample Size|1 to n|How many of these participants get asked every round of sub-sampling?|
-|α  |Quorum Size|1 to k|How many of the asked participants have to have the same preference for me to change my preference?|
-|β  |Decision Threshold|>= 1|How many times does the quorum have to confirm my preference until I finalize my decision?|
-
-With these parameters we can illustrate the consensus algorithm as pseudo code:
-
-![](/course-images/avalanche-fundamentals/8.png)
-
-
-## Finalization
-
-In the common case when a transaction has no conflicts, finalization happens very quickly. When conflicts exist, honest validators quickly cluster around conflicting transactions, entering a positive feedback loop until all correct validators prefer that transaction. This leads to the acceptance of non-conflicting transactions and the rejection of conflicting transactions.
-
-Avalanche Consensus guarantees (with high probability based on system parameters) that if any honest validator accepts a transaction, all honest validators will come to the same conclusion.
-
-<Quiz quizId="105"/>
diff --git a/content/course/avalanche-fundamentals/02-avalanche-consensus-intro/04-tps-vs-ttf.mdx b/content/course/avalanche-fundamentals/02-avalanche-consensus-intro/04-tps-vs-ttf.mdx
deleted file mode 100644
index b6460c66..00000000
--- a/content/course/avalanche-fundamentals/02-avalanche-consensus-intro/04-tps-vs-ttf.mdx
+++ /dev/null
@@ -1,42 +0,0 @@
----
-title: Throughput vs. Time to Finality
-description: Learn how metrics like throughput and time to finality are different.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-To measure blockchain performance we can use two metrics:
-
-- Throughput: How many transaction are finalized per second measured in transactions per second (TPS)
-- Time to Finality: How long does it take a transaction to go from being submitted to validators to being unchangeable. 
-
-These metrics are very different. Blockchain builders aspire to high throughput and very short time to finality.
-
-## Highway Analogy
-
-Let's take an analogy of a highway. Each car represents a transaction and they all travel the same speed. When you click *send* in your wallet, you're like a car entering the highway. When the transaction is *finalized* and unchangeable, it's like the car reaching its destination.
-
-![](/course-images/avalanche-fundamentals/9.png)
-
-Throughput could be likened to the number of lanes, determining how many cars can pass on the highway in a given amount of time. The more lanes you have, the more cars can pass through, thus increasing the throughput. In a blockchain network, increasing the block size (analogous to adding more lanes) can increase throughput.
-
-Now, imagine you're driving to a specific destination (finality). The time it takes you to get from your starting point (initiation of the transaction) to your destination (confirmation of the transaction) is analogous to the "time to finality." As soon as a car reaches finality, it cannot return or abort the travel.
-
-Our goal is to build highways with many lanes (high throughput) but that bring us to our destination as fast as possible (short time to finality).
-
-### Throughput and Finality of Popular Blockchain Networks
-
-|Network|Throughput|Time to Finality|
-|---|---|---|
-|Bitcoin|7 TPS|60 min|
-|Ethereum|30 TPS|6.4 min|
-|Avalanche / Avalanche L1|2500 TPS|~0.8 seconds|
-
-**TPS** &rarr; **Transactions per Second**
-
-Returning to the highway analogy, these networks would look like this:
-
-![](/course-images/avalanche-fundamentals/10.png)
-
-
diff --git a/content/course/avalanche-fundamentals/03-multi-chain-architecture-intro/01-multi-chain-architecture.mdx b/content/course/avalanche-fundamentals/03-multi-chain-architecture-intro/01-multi-chain-architecture.mdx
deleted file mode 100644
index a1486fbd..00000000
--- a/content/course/avalanche-fundamentals/03-multi-chain-architecture-intro/01-multi-chain-architecture.mdx
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: Multi-Chain Architecture
-description: Learn about the Multi-Chain Architecture.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Book
----
-
-Multi-chain systems are a significant innovation, which provide greater scalability, customizability, and independence. At the core of multi-chain systems is the ability to run multiple blockchains simultaneously. Each blockchain is optimized for specialized use cases, thereby boosting the network's overall performance.
-
-## What You Will Learn
-
-In this section, you will go through the following topics:
-
-- **Avalanche L1s:** Understand what Avalanche L1s are and how they work
-- **Setup Core Wallet:** Learn how to setup the Core wallet browser extension
-- **Use Dexalot:** Use your first Avalanche L1
diff --git a/content/course/avalanche-fundamentals/03-multi-chain-architecture-intro/02-subnet.mdx b/content/course/avalanche-fundamentals/03-multi-chain-architecture-intro/02-subnet.mdx
deleted file mode 100644
index eeacc88b..00000000
--- a/content/course/avalanche-fundamentals/03-multi-chain-architecture-intro/02-subnet.mdx
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Avalanche L1s
-description: Learn about the Multi-Chain Architecture.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-An Avalanche L1 is a network with its own set of rules regarding membership, token economics, and execution layer. It is composed of a Subset of Avalanche validators collaborating to achieve consensus on the state of one or more blockchains. Validators can be members of numerous Avalanche L1s.
-
-Avalanche enables multiple interconnected Avalanche L1s. Each Avalanche L1 is independent while maintaining the capacity to communicate with other Avalanche L1s. All validators are part of the Avalanche L1 known as the Primary Network.
-
-![](/common-images/multi-chain-architecture/subnets.png)
-
-Each blockchain belongs to exactly one Avalanche L1, but an Avalanche L1 can validate many blockchains. Each blockchain can define its own Virtual Machine (EVM, customized EVM or entirely new VM). 
-
-The tailored, application-specific blockchains of Avalanche L1s offer a solution to these challenges and many others, moving away from the monolithic blockchain structure of the past.
-
-<Quiz quizId="106"/>
\ No newline at end of file
diff --git a/content/course/avalanche-fundamentals/03-multi-chain-architecture-intro/03-benefits.mdx b/content/course/avalanche-fundamentals/03-multi-chain-architecture-intro/03-benefits.mdx
deleted file mode 100644
index 4322fe01..00000000
--- a/content/course/avalanche-fundamentals/03-multi-chain-architecture-intro/03-benefits.mdx
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: Features & Benefits of Avalanche L1s
-description: Learn about various benefits of using Avalanche Avalanche L1s,
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-Avalanche L1s are autonomous. Their creators can define their execution logic, set their own fees, manage their state, handle their networking, and ensure their security. They operate independently from other Avalanche L1s and the Primary Network, effectively enabling the greater Avalanche network to scale while delivering the benefits of lower latency, higher transactions per second (TPS), and lower transaction costs.
-
-## Scalability Through Multi-Chain Systems
-
-
-A blockchain has a limited capacity for computation and data storage. Therefore, the transactions it can process in a given time frame are limited. We can use the analogy of a highway to visualize this concept. A highway can only handle a certain number of cars at a time. If too many cars try to enter the highway at once, traffic congestion will occur and they have to wait to enter the highway.
-
-In order to scale horizontally and to offer more blockspace, a subset of validators can opt-in to validate an additional blockchain in parallel with the Primary Network: we call this an Avalanche L1. The idea is similiar to building many highways in parallel and create additional space for cars to drive on. This allows for more transactions to be processed in parallel, and therefore increases the overall throughput of the network.
-
-![](/course-images/avalanche-fundamentals/11.png)
-
-This parallel processing of transactions enhances scalability. One chain's congestion or increasing fees won't impact other chains. Going back to our highway analogy, we can think of the scaling through multiple chains as building many short highways in parallel.
-
-The beauty of this approach is its simplicity. It doesn't require any new untested innovations. The challenge, rather, is optimizing how Avalanche L1s interoperate and making switching from one Avalanche L1 to the other easy.
-
-## Independence From Other Avalanche L1s
-
-Separating the ecosystem into different chains creates independence from another. If congestion builds on one chain due to high network activity (e.g. an NFT drop, high volatility in token prices, new game launched), other chains are unaffected. With just a single chain, this congestion affects everyone, including parties that have nothing to do with the cause of the activity increase. 
-
-While the unified, or monolithic, blockchain design does offer certain advantages (like unified liquidity, fewer bridges, and potential for enhanced user experience via co-location of dApps), it also introduces notable drawbacks. Validators must have powerful, costly machines to support a diverse array of applications, increasing centralization due to high operational costs of running a node. Lack of modularity can halt all on-chain activities during network disruptions, potentially causing significant financial losses. Additionally, each new dApp competes for the same block space as all others, leading to overcrowding.
-
-![](/course-images/avalanche-fundamentals/12.png)
-
-Coming back to our highway analogy, we can imagine a scenario where congestion build up on one highway. The other highways are not directly affected. Some cars may choose to take a different highway and the traffic bottleneck may decrease.
-
-<Quiz quizId="107"/>
-
-## Customizability
-
-The creator of an Avalanche L1 can customize it to meet their needs. This can happen in numerous ways, including introducing a custom own gas token, using a different Virtual Machine (e.g. a WASM or Move VM), or limiting access to the Avalanche L1. This is very hard to do in a single-chain system because it would require a majority of users to agree.
-
-![](/course-images/avalanche-fundamentals/13.png)
-
-In our highway analogy, let's think of some travelers having a very unique requirement: They would like to travel by boat instead of a car. While technically possible to build a water lane on a single highway system, this would be challenging. However, when these custom requirements are met in a Avalanche L1, it's easy to do.
-
-## Other Multi-Chain Systems
-
-Avalanche isn't alone in the multi-chain landscape. Other blockchain systems utilizing a similar architectural approach include Cosmos, Polkadot, and Polygon CDK.
-
-<Quiz quizId="108"/>
diff --git a/content/course/avalanche-fundamentals/03-multi-chain-architecture-intro/03a-etna-upgrade.mdx b/content/course/avalanche-fundamentals/03-multi-chain-architecture-intro/03a-etna-upgrade.mdx
deleted file mode 100644
index 076f0be0..00000000
--- a/content/course/avalanche-fundamentals/03-multi-chain-architecture-intro/03a-etna-upgrade.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Etna Upgrade
-description: Learn about various benefits of using Avalanche Avalanche L1s,
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-import EtnaUpgradeMotivation from '@/content/common/multi-chain-architecture/etna-upgrade-motivation.mdx';
-
-<EtnaUpgradeMotivation />
\ No newline at end of file
diff --git a/content/course/avalanche-fundamentals/03-multi-chain-architecture-intro/04-setup-core.mdx b/content/course/avalanche-fundamentals/03-multi-chain-architecture-intro/04-setup-core.mdx
deleted file mode 100644
index 115d5100..00000000
--- a/content/course/avalanche-fundamentals/03-multi-chain-architecture-intro/04-setup-core.mdx
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: Setup Core Wallet
-description: Learn about how to setup your own Core Wallet.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-To grasp the concept of the Avalanche L1s better, interact with some chains. To do that, we will use Core. Core is an all-in-one command center built for multi-chain systems. It supports Avalanche, Bitcoin, Ethereum, and all EVM-compatible blockchains. Core has a browser extension, a web wallet, and a mobile app. It is optimized for multiple chains and makes navigating between them easy.
-
-<Steps>
-<Step>
-
-### Install Core Extension
-
-import InstallCoreExtension from "@/content/common/core-wallet/install.mdx"
-
-<InstallCoreExtension />
-
-</Step>
-<Step>
-
-### Create a Wallet
-
-import CreateWallet from "@/content/common/core-wallet/create-wallet.mdx"
-
-<CreateWallet />
-
-</Step>
-<Step>
-
-### Switch to Testnet
-
-import TestnetMode from "@/content/common/core-wallet/testnet-mode.mdx"
-
-<TestnetMode />
-
-</Step>
-<Step>
-
-### Get Testnet Tokens
-
-import Faucet from "@/content/common/core-wallet/faucet.mdx"
-
-<Faucet />
-
-</Step>
-</Steps>
-
-## Managing MetaMask & Core Extensions
-
-If you've added both Metamask and Core Wallet to your browser, you could face some problems. But, to fix them, you don't need to remove Metamask. Just follow the below steps to disable the Metamask extension:
-
-Open the extensions page in browser. You can also type chrome://extensions in your address bar to open extensions page.
-Scroll through your list of installed extensions, or use the search bar at the top of the page, to find the Metamask extension.
-Once you find Metamask, you will see a toggle switch next to it. Click on this switch to disable the extension.
-
-When the switch is in the off position, Metamask is disabled, and you should be all set.
-
-![](/course-images/avalanche-fundamentals/14.png)
diff --git a/content/course/avalanche-fundamentals/03-multi-chain-architecture-intro/05-use-dexalot.mdx b/content/course/avalanche-fundamentals/03-multi-chain-architecture-intro/05-use-dexalot.mdx
deleted file mode 100644
index 8e9a3fab..00000000
--- a/content/course/avalanche-fundamentals/03-multi-chain-architecture-intro/05-use-dexalot.mdx
+++ /dev/null
@@ -1,71 +0,0 @@
----
-title: Use Dexalot L1
-description: Get first hand experience with an Avalanche L1.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-In this activity, we'll interact with our first Avalanche L1. The Dexalot Avalanche L1 aims to replicate the user experience of a centralized exchange (CEX) with greater decentralization and transparency. By using a Avalanche L1, Dexalot can offer cheaper transaction fees than other traditional decentralized exchanges while keeping the transparency that centralized exchanges lack.
-
-<Steps>
-<Step>
-
-### Display the Dexalot Avalanche L1 in Core
-
-Make sure your Core Wallet is set to Testnet mode, so we do not use real funds. Open your Core Wallet Browser Extension and click "Show all Networks." To display Dexalot to our home screen, click the star icon next to its name.
-
-</Step>
-<Step>
-
-### Bridge Tokens to Dexalot
-
-Head over to the [Dexalot Testnet](https://app.dexalot-test.com/trade), connect your wallet (top right), and click on the `Balances` Tab in the `Trade` page. You will have to authenticate your wallet for the first time you interact with Dexalot.
-
-On the `Balances` tab, select to deposit into the Dexalot L1.
-
-![](/course-images/avalanche-fundamentals/15.png)
-
-Enter 1 AVAX and click Deposit. Confirm the transaction in your wallet.
-
-![](/course-images/avalanche-fundamentals/deposit.png)
-
-A few moments later, your balances should be updated in the `Balances` tab:
-
-![](/course-images/avalanche-fundamentals/16.png)
-
-</Step>
-<Step>
-
-### Swap Tokens on Dexalot L1
-
-Now head to the `Trade` tab and sell 0.5 AVAX for USDC. You can select the trading pair AVAX/USDC on the top right. The website will prompt your wallet to switch networks to the Dexalot L1. Confirm the switch and then sign the transaction.
-
-![](/course-images/avalanche-fundamentals/17.png)
-
-Now, head back to the `Balances` tab and check how the balances updated.
-![](/course-images/avalanche-fundamentals/updated-balance.png)
-
-
-</Step>
-<Step>
-
-### Withdraw to Fuji C-Chain
-
-From the `Balances` tab, withdraw your AVAX and USDC back to the Fuji C-Chain by clicking on the "Withdraw To Wallet" option in the drop down menu:
-
-![](/course-images/avalanche-fundamentals/18.png)
-
-Make sure the network is set to Fuji C-Chain and enter the amount you want to withdraw. Click on the Withdraw button and confirm the transaction in your wallet.
-![](/course-images/avalanche-fundamentals/bridge-back-usdc.png)
-
-</Step>
-</Steps>
-
-## What just happened?
-
-On the surface, it might feel like a regular decentralized swap. However, there is a substantial difference. We performed our operation not on the C-Chain, but bridged our tokens to a Avalanche L1, performed the operations there, and bridged our tokens back to the C-Chain.
-
-The Avalanche L1 (Dexalot) we used was highly specialized for our use case and very cheap. We actually got all the gas token ALOT we needed airdropped, just for bridging assets over. The only fees we had to pay were for bridging. Usually, we would not have done this for a single operation, so these costs do not occur for a single trade, but only for depositing and withdrawing from the portfolio.
diff --git a/content/course/avalanche-fundamentals/04-creating-a-blockchain/01-creating-a-blockchain.mdx b/content/course/avalanche-fundamentals/04-creating-a-blockchain/01-creating-a-blockchain.mdx
deleted file mode 100644
index 35f74284..00000000
--- a/content/course/avalanche-fundamentals/04-creating-a-blockchain/01-creating-a-blockchain.mdx
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Creating a Blockchain
-description: Learn about the Multi-Chain Architecture.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
-
-Now that we've gone over what an Avalanche L1 is and what the benefits of creating an Avalanche L1 on Avalanche are, you are probably eager to test out the functionality of Avalanche L1s by creating one yourself!
-
-There are many ways to create a blockchain on Avalanche. In this section, you will learn how to create a blockchain using the AvaCloud, a Blockchain-as-a-Service provider. This is the most straight forward way. Of course there are many other ways to create a blockchain on Avalanche, but this is the easiest way to get started. 
-
-You will learn how to deploy a blockchain with Avalanche-CLI in the course Multi-Chain Architecture.
-
-## What You Will Learn
-
-In this section, you will go through the following topics:
-
-- **AvaCloud:** Learn about AvaCloud and create an account
-- **Create Avalanche L1:** Learn how to create your first Avalanche L1 on AvaCloud
-- **Connect:** Connect your wallet to your Avalanche L1
\ No newline at end of file
diff --git a/content/course/avalanche-fundamentals/04-creating-a-blockchain/02-avacloud-signup.mdx b/content/course/avalanche-fundamentals/04-creating-a-blockchain/02-avacloud-signup.mdx
deleted file mode 100644
index 7cb7cc9d..00000000
--- a/content/course/avalanche-fundamentals/04-creating-a-blockchain/02-avacloud-signup.mdx
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: Sign Up for AvaCloud
-description: Signing up for the Avacloud service.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-AvaCloud is an online service that allows users to customize and launch their own Avalanche L1 just using the browser! No need to use any CLI or install any tools locally.
-
-Furthermore, this is great news for us because we can just jump straight into deploying an Avalanche L1 and connecting to it!
-
-## Let's Sign Up
-
-To start, please head over to https://avacloud.io, where you will be greeted with the following page:
-
-![](/course-images/avalanche-fundamentals/19.png)
-
-In the top-righthand corner (where the red box is), click the log-in button. If you are a first-time user, you will be directed through the account creation process. Afterwards, you will see the following page:
-
-![](/course-images/avalanche-fundamentals/20.png)
-
-We are now ready to create our Avalanche L1!
\ No newline at end of file
diff --git a/content/course/avalanche-fundamentals/04-creating-a-blockchain/03-create-on-avacloud.mdx b/content/course/avalanche-fundamentals/04-creating-a-blockchain/03-create-on-avacloud.mdx
deleted file mode 100644
index 4a8bfd1b..00000000
--- a/content/course/avalanche-fundamentals/04-creating-a-blockchain/03-create-on-avacloud.mdx
+++ /dev/null
@@ -1,60 +0,0 @@
----
-title: Create & Deploy a Blockchain
-description: Learn how you can configure and launch your subnet using AvaCloud.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-In this section, we will get our first taste of deploying an Avalanche L1. 
-
-<Steps>
-<Step>
-
-### Connect Core Wallet
-
-To start, please make sure your have the Core wallet set up. Connect the wallet at the top right.
-
-</Step>
-<Step>
-
-### Create an L1
-
-With a wallet address now set, click the Create Avalanche L1 button at the top-righthand corner of the AvaCloud home screen:
-
-![](/course-images/avalanche-fundamentals/21.png)
-
-</Step>
-<Step>
-
-### Configure the L1
-
-From here, you will see the following screen detailing the customization options of your Avalanche L1:
-
-![](/course-images/avalanche-fundamentals/22.png)
-
-Going through the customization options of your L1:
-
-1. **Avalanche L1 Name:** the name of your Avalanche L1. You can choose the name to be anything you want.
-2. **Airdrop Amount:** the amount of tokens you want the admin address to be initialized with. This is one of the reasons why we earlier needed you to verify that you had an address.
-3. **Native Token Symbol:** the symbol/ticker of your chain token
-4. **Admin Wallet Address:** the address of the admin (i.e. you)
-5. **Chain ID:** a unique numerical identifier for your chain. We recommend you keep it to the default value.
-
-At the bottom, you will see a button named Advanced Avalanche L1 Setup. You can ignore that.
-
-</Step>
-<Step>
-
-### Deploy the L1
-
-Click the next button, hit the Submit Devnet button on the next page, and you will have successful deployed your Avalanche L1. You should see a screen similar to the following:
-
-![](/course-images/avalanche-fundamentals/23.png)
-
-</Step>
-</Steps>
-
-In the next section, we will finally connect to our Avalanche L1 and deploy a smart contract on it!
\ No newline at end of file
diff --git a/content/course/avalanche-fundamentals/04-creating-a-blockchain/04-connect.mdx b/content/course/avalanche-fundamentals/04-creating-a-blockchain/04-connect.mdx
deleted file mode 100644
index df441d87..00000000
--- a/content/course/avalanche-fundamentals/04-creating-a-blockchain/04-connect.mdx
+++ /dev/null
@@ -1,41 +0,0 @@
----
-title: Connecting to Your Blockchain
-description: Learn how to connect a wallet to your newly created blockchain.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-In the final section of this chapter, we will go over the process of connecting your wallet to your Avalanche L1 along with sending some funds.
-
-## Connecting to Your Avalanche L1
-
-### Using AvaCloud
-
-Make sure your wallet is connected to AvaCloud. Then, recall the following page from last time:
-
-![](/course-images/avalanche-fundamentals/24.png)
-
-We can simply navigate to the Avalanche L1's details we require for connection, by clicking the **arrow** and then the **Details** tab. There click the **Add to Wallet** button.
-
-![](/course-images/avalanche-fundamentals/25.png)
-
-### Manual Connection
-
-If for some reason the button should not work with your wallet, you can also add you Avalanche L1 manually. In particular, there are two fields that we care about: the Chain ID and the RPC Url; these fields are what will allow us to connect our wallets to AvaCloud. To start, open Core Wallet, head into the **Networks** tab, and click the + button, where you should see the following screen:
-
-![](/course-images/avalanche-fundamentals/26.png)
-
-Congrats, you've just connected to your own Avalanche L1!
-
-## Interacting with Your Avalanche L1
-
-You should now be able to see the airdrop for your admin address in the you wallet when you open it:
-
-![](/course-images/avalanche-fundamentals/27.png)
-
-Click the Actions button and transfer some of the tokens to a random address (e.g. 0x321f6B73b6dFdE5C73731C39Fd9C89c7788D5EBc) to verify that this is actually a fully operational blockchain.
-
-## Congratulations 🎉
-
-You have just launched your first Avalanche L1!
diff --git a/content/course/avalanche-fundamentals/05-vms-and-blockchains/01-vms-and-blockchains.mdx b/content/course/avalanche-fundamentals/05-vms-and-blockchains/01-vms-and-blockchains.mdx
deleted file mode 100644
index 537d600f..00000000
--- a/content/course/avalanche-fundamentals/05-vms-and-blockchains/01-vms-and-blockchains.mdx
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Virtual Machines and Blockchains
-description: Learn about the Virtual Machines.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
-
-<YouTube id="b-slW7w65VQ" />
-
-Virtual Machines are defining the behaviour of a blockchain. They can be the execution environment for smart contracts and decentralized applications. In this section, you will learn about the Virtual Machines used in Avalanche.
-
-## What You Will Learn
-
-In this section, you will go through the following topics:
-
-- **State Machine:** Understand what a State Machine is and how it works
-- **Blockchain:** Learn about the role of VMs in blockchains
-- **Variety of VMs:** Learn how Avalanche supports different VMs
\ No newline at end of file
diff --git a/content/course/avalanche-fundamentals/05-vms-and-blockchains/02-state-machine.mdx b/content/course/avalanche-fundamentals/05-vms-and-blockchains/02-state-machine.mdx
deleted file mode 100644
index 359cea02..00000000
--- a/content/course/avalanche-fundamentals/05-vms-and-blockchains/02-state-machine.mdx
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: What is a State Machine?
-description: Learn about the State Machines in blockchain systems.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-A virtual machine in the context of a blockchain system is like a decentralized computer that can execute a program in a controlled environment. A Virtual Machine (VM) defines the application-level logic of a blockchain. In technical terms, it specifies the blockchain’s state, state transition function, transactions, and the API through which users can interact with the blockchain.
-
-When you write a VM, you don't need to concern yourself with lower-level logic like networking, consensus, and blockchain structure. Avalanche does this behind the scenes, so you can focus on building.
-
-The most popular VM in blockchain is the Ethereum Virtual Machine (EVM) used in the Ethereum blockchain and others. It enables the creation and execution of smart contracts. However, blockchain systems are not limited to the EVM and many blockchains operate with different virtual machines today. For instance, Solana and Cardano use completely different Virtual Machines.
-
-## Soda Dispenser: A Simple Machine
-
-To better comprehend Virtual Machines, take this analogy of a simple, everyday machine: a soda dispenser. 
-
-For optimal functionality, this machine must **consistently monitor its state**. In this instance, the state may represent the current balance, total revenue, and the number of cans available per brand.
-
-![](/course-images/avalanche-fundamentals/28.png)
-
-<Quiz quizId="109"/>
-
-This dispenser permits several **operations**, such as:
-- Inserting coins
-- Selecting a soda flavor
-
-User operations trigger **state transitions**. For example, when a user inserts a coin, the balance increases. Selecting a soda brand leads to a decrease of the balance by the soda's price and reduces the quantity of that specific brand by one. 
-
-<Quiz quizId="110"/>
-
-Additionally, certain logic might be incorporated to dictate various operational outcomes based on the current state. For example, the machine checks if the balance is sufficient when a user chooses a soda brand. As a result, the outcome could be different in cases where the balance is adequate compared to instances where it isn't.
-
-
-## Advantages of VMs
-
-Implementing state machines comes with several advantages:
-
-**Clear Interface:** The range of operations provides clarity on how to interact with it. Once familiarized with the interface, you can interact with all soda machines (following the same blueprint) in the same manner.
-
-**Reproducibility:** With a Virtual Machine blueprint, one can create multiple identical instances. These behave consistently, implying that if you conduct the same operations in the same sequence on two different machines, the state will remain identical.
-
-<Quiz quizId="111"/>
\ No newline at end of file
diff --git a/content/course/avalanche-fundamentals/05-vms-and-blockchains/03-blockchains.mdx b/content/course/avalanche-fundamentals/05-vms-and-blockchains/03-blockchains.mdx
deleted file mode 100644
index 1375c07d..00000000
--- a/content/course/avalanche-fundamentals/05-vms-and-blockchains/03-blockchains.mdx
+++ /dev/null
@@ -1,31 +0,0 @@
----
-title: Blockchains
-description: Learn about how VMs work in blockchain.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-Let’s look at how VMs work in blockchain. Each validator operates an instance of our hypothetical soda dispenser. So, they have their own instance of a machine running on their server. They do this so they do not have to trust a single party with the operation of a soda dispenser,  and to make it easy for everyone to verify the outcome of operations.
-
-When a user wishes to execute an operation on this distributed soda dispenser, they transmit the transaction to the network. The validators then reach consensus on the sequence in which transactions are carried out. In Avalanche, validators use Avalanche Consensus, which we talked about earlier.
-
-<Quiz quizId="112"/>
-
-Next, each validator executes the operation on their instance of the VM independently. Because each instance of our Virtual Machine behaves identically, validators maintain a uniform view of the machine’s state, so they balance and the number of available soda per flavor.
-
-![](/course-images/avalanche-fundamentals/28.png)
-
-Subsequently, each validator executes the operation on their instance independently. Again, because each instance behaves identically, validators maintain a uniform view of the system's state, encompassing balance and available soda quantities. 
-
-Let’s take the example further. Assume we have 100 validators in our Soda Dispenser Avalanche L1. I submit multiple operations to the validators:
-
-- Insert a quarter
-- A little while later, I Insert another quarter
-- Choose lemonade
-
-Each of the validators executes the operations on their own machine. After the first quarter the state of the machine states that the balance is 25 cents. After the second operation the balance is 50 cents. After choosing lemonade, the balance goes back to zero and the amount of available lemonades decreases from 8 to 7 on each instance running on each validators server.
-
-This is the fundamental principle of Blockchains in Avalanche: A collective of validators operate identical virtual machines, come to consensus on the order of transactions, execute them, and have a uniform view on the machine's current state.
-
-<Quiz quizId="113"/>
\ No newline at end of file
diff --git a/content/course/avalanche-fundamentals/05-vms-and-blockchains/04-variety-of-vm.mdx b/content/course/avalanche-fundamentals/05-vms-and-blockchains/04-variety-of-vm.mdx
deleted file mode 100644
index f0142785..00000000
--- a/content/course/avalanche-fundamentals/05-vms-and-blockchains/04-variety-of-vm.mdx
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Variety of Virtual Machines
-description: Learn about different types of Virtual Machines.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-We can take this concept even further: The same network of validators can run two or more blockchains. These could operate different VMs, like a soda dispenser and a candy dispenser, or identical VMs, like two soda dispensers. When a user wants to issue an operation, they specify which blockchain to interact with.
-
-![](/course-images/avalanche-fundamentals/30.png)
-
-You can think of a Virtual Machine (VM) as a blueprint for a blockchain, where the same VM can create multiple blockchains, each adhering to the same rules but remaining logically independent from the others. 
-
-Even though two blockchains may use the same virtual machine, they each have an independent state. As an example, it could be the case that in one soda dispenser, a user has a credit of 1 dollar to their name while in the other soda dispenser, they do not have any credits to their name.
-
-![](/course-images/avalanche-fundamentals/31.png)
-
-The number of blockchains a validator can validate is primarily limited by the additional computational resources required to operate the virtual machines of all the chains.
-
-<Quiz quizId="114"/>
\ No newline at end of file
diff --git a/content/course/avalanche-fundamentals/06-vm-customization/00-vm-customization.mdx b/content/course/avalanche-fundamentals/06-vm-customization/00-vm-customization.mdx
deleted file mode 100644
index 85391e3c..00000000
--- a/content/course/avalanche-fundamentals/06-vm-customization/00-vm-customization.mdx
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: Introduction to VM Customization
-description: Learn about customizing Virtual Machines.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Book
----
-
-<YouTube id="gilx8K32_eI" />
-
-For some use cases, it may be necessary to use a customized VM too. This is the case if an application cannot be built on a regular EVM on the C-Chain, or if it would result in gas costs too high to be economical for its users or creators.
-
-Depending on a builder's needs, Avalanche allows for different VM customizations:
-
-![](/course-images/avalanche-fundamentals/32.png)
-
-Customizing the EVM on the Ethereum network is difficult, requiring a wide consensus that the proposed change is mutually beneficial for all network participants. This can make customizations for unique use cases challenging, if not impossible. Additionally, Ethereum doesn't give users the option to add different chains. 
-
-In Avalanche, every Avalanche L1 has autonomy over their Virtual Machines. Their creators can customize VMs to fit their unique requirements. This is one of the biggest advantages of multi-chain systems. 
-
-In this section, we will see the three way to customize Virtual Machines at a high level. In later courses, we will dive deeper and learn how to actually customize each. 
-
-<Quiz quizId="115"/>
\ No newline at end of file
diff --git a/content/course/avalanche-fundamentals/06-vm-customization/01-configuration.mdx b/content/course/avalanche-fundamentals/06-vm-customization/01-configuration.mdx
deleted file mode 100644
index ddc3226c..00000000
--- a/content/course/avalanche-fundamentals/06-vm-customization/01-configuration.mdx
+++ /dev/null
@@ -1,80 +0,0 @@
----
-title: VM Configuration
-description: Learn about customizing Virtual Machines.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-When building a VM, it is possible to define certain parameters that can change the behavior of the VM. In our soda dispenser analogy these may be the products and prices offered by the dispenser. We might want to have two dispenser blockchains that offer different products and prices. If the VM is built in a way that it has parameters for the products and prices, it can be easily reused for different use items.
-
-![](/course-images/avalanche-fundamentals/33.png)
-
-This is a massive advantage over one-chain-fits-all systems, where the parameters have to be a compromise between all network participants. In Avalanche it is possible to have different blockchain with the same VM, but different parameters. 
-
-Using VM Configuration we can easily create EVM-chains for different use cases such as trading a cheap gaming NFT or valuable Real estate on chain. These blockchains may differ in fees (low fees for cheap NFTs, high fees for valuable goods) and security levels (low security for cheap NFTs, high security for valuable goods). 
-
-<Quiz quizId="116"/>
-
-Examples of the configurable parameters of the subnetEVM include:
-
-**trxAllowList:** Define a whitelist of accounts that restrict which account's transactions are accepted by the VM.
-
-**contractDeployerAllowlist:** Defined a whitelist of accounts that restricts which account can deploy contracts on the blockchain
-
-Using these parameters we VM can adapt the VM to our requirements without writing a single line of code. This is by far the easiest, but also least flexible way to customize a VM to one's requirements.
-
-```json
-{
-  "config": {
-    "chainId": 99999,
-    "homesteadBlock": 0,
-    "eip150Block": 0,
-    "eip150Hash": "0x2086799aeebeae135c246c65021c82b4e15a2c451340993aacfd2751886514f0",
-    "eip155Block": 0,
-    "eip158Block": 0,
-    "byzantiumBlock": 0,
-    "constantinopleBlock": 0,
-    "petersburgBlock": 0,
-    "istanbulBlock": 0,
-    "muirGlacierBlock": 0,
-    "subnetEVMTimestamp": 0,
-    "feeConfig": {
-      "gasLimit": 20000000,
-      "minBaseFee": 1000000000,
-      "targetGas": 100000000,
-      "baseFeeChangeDenominator": 48,
-      "minBlockGasCost": 0,
-      "maxBlockGasCost": 10000000,
-      "targetBlockRate": 2,
-      "blockGasCostStep": 500000
-    },
-    "contractDeployerAllowListConfig": {
-      "blockTimestamp": 0,
-      "adminAddresses": [
-        "0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC"
-      ]
-    }
-  },
-  "alloc": {
-    "8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC": {
-      "balance": "0x52B7D2DCC80CD2E4000000"
-    },
-    "0x0Fa8EA536Be85F32724D57A37758761B86416123": {
-      "balance": "0x52B7D2DCC80CD2E4000000"
-    }
-  },
-  "nonce": "0x0",
-  "timestamp": "0x0",
-  "extraData": "0x00",
-  "gasLimit": "0x1312D00",
-  "difficulty": "0x0",
-  "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
-  "coinbase": "0x0000000000000000000000000000000000000000",
-  "number": "0x0",
-  "gasUsed": "0x0",
-  "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000"
-}
-```
-
-You can find more examples of Genesis files [here](https://github.com/ava-labs/subnet-evm/tree/master/tests/precompile/genesis).
diff --git a/content/course/avalanche-fundamentals/06-vm-customization/02-modification.mdx b/content/course/avalanche-fundamentals/06-vm-customization/02-modification.mdx
deleted file mode 100644
index 5aa586c3..00000000
--- a/content/course/avalanche-fundamentals/06-vm-customization/02-modification.mdx
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: VM Modification
-description: Learn about modifying Virtual Machines.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-The next more powerful way to customize a VM is VM Modification. To meet our requirements, we can modify and extend our existing VM. In our soda dispenser analogy, we might want to customize our soda dispenser to accept card payments. Our current soda dispenser machine simply does not have this feature. Instead of reinventing the wheel and building a new dispenser with the new feature from the ground up, we simply extend the existing VM using a plugin.
-
-![](/course-images/avalanche-fundamentals/34.png)
-
-In Avalanche, creating modified VMs is straightforward. The subnetEVM for instance can be customized through the development of plugins as well as precompiles.
-
-<Quiz quizId="117"/>
\ No newline at end of file
diff --git a/content/course/avalanche-fundamentals/06-vm-customization/03-creation.mdx b/content/course/avalanche-fundamentals/06-vm-customization/03-creation.mdx
deleted file mode 100644
index 1c496fc0..00000000
--- a/content/course/avalanche-fundamentals/06-vm-customization/03-creation.mdx
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title: VM Creation
-description: Learn about creating Virtual Machines.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-For some use cases it might be necessary to create entirely new VMs. 
-
-In our analogy this would be the case if we require completely different features, let's say we want to build a car VM. There is simply no way we can configure or extend a soda dispenser to turn it into a car. Instead we have to build a new VM from ground up. These newly created VMs can cater to much more specialized use cases and therefore this enables completely new blockchain applications not possible before. 
-
-VM Creation is by far the most complex way, but also the most powerful way to customize a VM. It requires a deep understanding of the blockchain space and software development skill. There might be certain basic elements in most VMs, such as the notion of transaction, accounts and authentication. Therefore, Avalanche provides some SDKs, such as the HyperSDK, to make the creation of VMs in languages like Go and Rust easier. 
-
-When creating a VM, there are two very distinct design patterns, that greatly vary in their intended use case.
-
-## Special Purpose VMs
-
-Special Purpose VMs are highly optimized for a specific use case. They only allow a very limited set of operations closely knit to its use case. A popular example for this would be the VM of the Bitcoin blockchain. The operations are much more limited than the ones of the Ethereum Virtual Machines, hence it only allows transactions related to the transfer of BTC.
-
-## General Purpose
-
-General Purpose VMs introduce another layer - commonly know as Smart Contracts or Programs - that can be submitted to the VM and enable user of the chain to interact with these. This way it allows its users to introduce their own logic to the VM. The most common General Purpose VM is the Ethereum Virtual Machine (EVM). However, some Avalanche L1s creators might want to create a VM that utilizes another language, such as Move, instead of Solidity as it’s smart contract language.
-
-![](/course-images/avalanche-fundamentals/35.png)
-
-One of the EVM's key features is its capability to execution of smart contracts in a deterministic and trustless manner, ensuring that the outcome of their execution is predictable and verifiable by all network participants. Developers can create decentralized applications and deploy them on the Ethereum blockchain. 
-
-This enables a wide range of use cases including decentralized finance (DeFi), tokenization, supply chain management, and more. The EVM's flexibility, security, and compatibility have made it a fundamental component of the Ethereum ecosystem, powering a vibrant and rapidly evolving ecosystem of decentralized applications and services.
diff --git a/content/course/avalanche-fundamentals/get-certificate.mdx b/content/course/avalanche-fundamentals/get-certificate.mdx
deleted file mode 100644
index bd91f7e3..00000000
--- a/content/course/avalanche-fundamentals/get-certificate.mdx
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: Course Completion Certificate
-updated: 2024-09-09
-authors: [ashucoder9]
-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="avalanche-fundamentals"/>
-
-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/avalanche-fundamentals/index.mdx b/content/course/avalanche-fundamentals/index.mdx
deleted file mode 100644
index bb3cdba2..00000000
--- a/content/course/avalanche-fundamentals/index.mdx
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title: Welcome to the Course
-description: Learn about the basics of Avalanche.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Smile
----
-
-Welcome to the Avalanche Fundamentals, an online course introducing you to the exciting world of the Avalanche technology! This course will provide you with a comprehensive understanding of the basic concepts making Avalanche unique.
-
-Throughout, you'll learn the key features and benefits of the platform, plus how to build on it. You can also ask our expert instructors questions.
-
-By the end of these courses, you'll have the knowledge and skills to leverage the power of blockchain technology for your own projects and applications. We're excited to have you join us on this journey and can't wait to see what you'll create with Avalanche!
-
-## Prerequisites
-
-This course is for people with some blockchain knowledge. Check out this [guide](/guide/what-is-a-blockchain) to review what a blockchain is.
-
-Familiarity with the basic design of modern distributed software systems and common blockchain systems such as Bitcoin and Ethereum is also recommended. You do not need to know how to write code to successfully complete this course.
-
-Having these prerequisites will help you better understand the course material and engage in the activities. If you don't know whether you have the necessary foundation for this course, please contact the course instructor for guidance.
-
-
-## Learning Outcomes
-
-By the end of this course, you will:
-
-- Understand how Avalanche consensus works and what makes it different.
-- Understand how Avalanche L1s enable scalability, customizability, and independence.
-- Understand the Primary Network, a special Avalanche L1, and how to interact with it.
-- Understand how Virtual Machines enable developers to create more optimized and capable blockchain systems and to tackle completely new use cases unachievable with previous solutions.
-
-You can evaluate your own understanding of the material through quizzes and claim a certificate for successful completion at the end.
-
-Overall, this course aims to provide a foundational understanding of Avalanche. By completing it, you will be better prepared to take on more advanced courses focused on building on Avalanche.
\ No newline at end of file
diff --git a/content/course/avalanche-fundamentals/meta.json b/content/course/avalanche-fundamentals/meta.json
deleted file mode 100644
index 3f284f38..00000000
--- a/content/course/avalanche-fundamentals/meta.json
+++ /dev/null
@@ -1,19 +0,0 @@
-{
-  "title": "avalanche-fundamentals",
-  "root": true,
-  "pages": [
-    "index",
-    "---Primer on Avalanche Consensus---",
-    "...02-avalanche-consensus-intro",
-    "---Multi-Chain Architecture---",
-    "...03-multi-chain-architecture-intro",
-    "---Creating a Blockchain---",
-    "...04-creating-a-blockchain",
-    "---Virtual Machines & Blockchains---",
-    "...05-vms-and-blockchains",
-    "---Virtual Machine Customization---",
-    "...06-vm-customization",
-    "---Course Completion---",
-    "get-certificate"
-  ]
-}
diff --git a/content/course/blockchain-fundamentals/02-what-is-a-blockchain/01-what-is-a-blockchain.mdx b/content/course/blockchain-fundamentals/02-what-is-a-blockchain/01-what-is-a-blockchain.mdx
deleted file mode 100644
index 86006ed7..00000000
--- a/content/course/blockchain-fundamentals/02-what-is-a-blockchain/01-what-is-a-blockchain.mdx
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: What is a Blockchain?
-description: Understand the high-level structure of this chapter.
-updated: 2024-09-01
-authors: [martineckardt]
-icon: Book
----
-
-Blockchains introduce a lot of new concepts. In this chapter we will approach the concept from a high level and see how it compares with other kinds of computers we are used to:
-
-- **Decentralized Computer:** How is a blockchain different from computers we know?
-- **Decentralized Applications:** What are dApps? 
-- **Use Cases:** When does it make sense to use Blockchain?
diff --git a/content/course/blockchain-fundamentals/02-what-is-a-blockchain/02-decentralized-computer.mdx b/content/course/blockchain-fundamentals/02-what-is-a-blockchain/02-decentralized-computer.mdx
deleted file mode 100644
index 6ab3349c..00000000
--- a/content/course/blockchain-fundamentals/02-what-is-a-blockchain/02-decentralized-computer.mdx
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Decentralized Computer
-description: Explore how different types of computers, including smartphones, PCs, web servers, and blockchains, serve specific functions based on their unique characteristics. Understand the benefits and trade-offs of blockchain as a decentralized computer, ideal for secure transactions but less efficient and more complex than traditional centralized systems.
-updated: 2024-09-01
-authors: [martineckardt]
-icon: BookOpen
----
-
-We interact with various types of computers every day, each designed to serve specific functions based on its unique characteristics. Smartphones, for example, are portable and convenient, offering powerful computing capabilities in a compact form. They are ideal for tasks that require mobility, such as communication, navigation, and media consumption. However, their small screen size and limited processing power compared to larger computers make them less suitable for tasks that require intensive computing power or extensive multitasking. PCs, on the other hand, provide more robust processing power and versatility. They are well-suited for tasks like video editing, gaming, or software development, where performance and the ability to use larger screens and peripherals like a mouse and keyboard are crucial. Yet, they lack the portability of smartphones and often require more space and power to operate.
-
-![](/common-images/blockchain-basics/decentralized-computer/different-kinds-of-computer.png)
-
-Web servers represent another type of computer, designed to handle large volumes of data and manage multiple simultaneous requests from users across the internet. They are optimized for reliability, speed, and the ability to run continuously without interruption, making them crucial for hosting websites, online services, and cloud computing platforms. While web servers excel at handling complex backend processes and large-scale operations, they are not intended for direct user interaction or tasks requiring a graphical user interface, which is where PCs and smartphones come in. Each type of computer has its strengths and weaknesses, and they often work together within the broader digital ecosystem, each performing tasks that suit their design and capabilities best.
-
-The internet, as we know it today, is built on a centralized architecture, where data and services are controlled and maintained by a few large entities like data centers and internet service providers. However, the advent of blockchain technologies has opened up new possibilities for a more decentralized internet, often referred to as Web 3.0 or the decentralized web.
-
-## Blockchains are Decentralized Computers
-
-Blockchain can be thought of as a new kind of computer. The key advantage of this new kind of computer is decentralization, meaning that no single entity has control over the entire system. Instead, control is distributed across many participants, which enhances security and transparency, as all transactions are verified by consensus and recorded on an immutable ledger. 
-
-![](/common-images/blockchain-basics/decentralized-computer/blockchain-computer.png)
-
-However, this decentralization comes with trade-offs. Blockchains are inherently less efficient than traditional centralized systems. The complexity of managing and maintaining a decentralized network, along with slower transaction speeds, can be significant downsides compared to more traditional, centralized computing models. 
-
-This makes blockchain ideal for certain use cases, like secure financial transactions or decentralized applications, but less suitable for tasks requiring high speed and efficiency.
diff --git a/content/course/blockchain-fundamentals/02-what-is-a-blockchain/03-decentralized-applications.mdx b/content/course/blockchain-fundamentals/02-what-is-a-blockchain/03-decentralized-applications.mdx
deleted file mode 100644
index 25fec5e7..00000000
--- a/content/course/blockchain-fundamentals/02-what-is-a-blockchain/03-decentralized-applications.mdx
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: Decentralized Applications
-description: TBD
-updated: 2024-09-01
-authors: [martineckardt]
-icon: BookOpen
----
-
-Programs and apps are software applications designed to run on different types of computers, such as smartphones, PCs, and web servers. On smartphones, apps are typically designed for specific tasks like messaging, gaming, or social media, optimized for touch interfaces and mobile connectivity. PCs run more complex programs, such as word processors, video editors, or development tools, which take advantage of larger screens, more powerful hardware, and the ability to handle multitasking. Web servers, on the other hand, run server-side applications that power websites, process data, and handle multiple user requests simultaneously. These programs often provide the backend services that apps on smartphones and PCs rely on to function.
-
-![](/common-images/blockchain-basics/decentralized-computer/decentralized-applications.png)
-
-Similarly, smart contracts or decentralized applications (dApps) are programs that run on a blockchain. A smart contract is a self-executing program with the terms of the agreement directly written into code, operating without the need for a trusted central authority. dApps are more complex, often consisting of multiple smart contracts that together offer a full application experience on the blockchain. Like traditional apps, these blockchain-based programs can perform a wide range of tasks, from managing digital assets to running decentralized finance (DeFi) protocols.
-
-![](/common-images/blockchain-basics/decentralized-computer/decentralized-applications-connected.png)
-
-Different types of applications can interoperate across these platforms, enabling a seamless user experience. For instance, a mobile app can interact with a backend running on a web server to fetch or update data. Similarly, the same app could also interact with a smart contract on a blockchain to verify transactions or access decentralized services. This interoperability allows users to benefit from the strengths of each platform, combining the user-friendliness of mobile apps, the processing power of web servers, and the security and transparency of blockchain technology.
\ No newline at end of file
diff --git a/content/course/blockchain-fundamentals/02-what-is-a-blockchain/04-use-cases.mdx b/content/course/blockchain-fundamentals/02-what-is-a-blockchain/04-use-cases.mdx
deleted file mode 100644
index 63abbae1..00000000
--- a/content/course/blockchain-fundamentals/02-what-is-a-blockchain/04-use-cases.mdx
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title: Use Cases
-description: Explore the unique advantages and challenges of blockchain technology in finance, supply chain management, and voting systems. Learn how blockchain enhances security, transparency, and decentralization, while also considering its limitations in efficiency and complexity.
-updated: 2024-09-01
-authors: [martineckardt]
-icon: BookOpen
----
-
-Blockchains have unique properties that make them an excellent fit for certain use cases where security, transparency, and decentralization are paramount:
-
-### Finance
-Blockchains enable secure, transparent transactions without the need for intermediaries. This is the foundation of cryptocurrencies and decentralized finance (DeFi) platforms. The immutability of blockchain records ensures that financial transactions are tamper-proof and can be audited at any time, making it ideal for high-stakes environments where trust is critical.
-
-### Supply Chain Management
-Blockchain can provide an immutable record of a product's journey from origin to consumer, increasing transparency and reducing fraud. This helps ensure that every step of the supply chain is accurately tracked and verified.
-
-### Voting Systems
-Blockchain's transparency and security ensure that votes are accurately counted and cannot be altered. This is crucial for maintaining democratic integrity and building trust in electoral processes.
-
-## Downsides
-
-However, the same properties that make blockchains so powerful in these areas also introduce significant challenges. Blockchains are inherently less efficient than traditional databases because they require consensus among distributed nodes, which can slow down transaction speeds and increase the complexity of operations. This makes blockchain less suitable for use cases where high speed and efficiency are critical, such as real-time data processing or high-frequency trading. Additionally, the complexity of developing and maintaining blockchain systems can be a barrier, particularly for applications that don't require the levels of security and decentralization that blockchains offer.
-
-When deciding whether to use blockchain, consider whether your use case requires the specific advantages of decentralization, transparency, and security. Blockchain is well-suited for applications where trust between parties is a major concern and where an immutable record of transactions is essential. However, if your application demands high throughput, real-time processing, or simplicity, a traditional centralized system might be more appropriate. In short, blockchain is a powerful tool for the right situations, but its use should be carefully considered against the specific needs of your application.
\ No newline at end of file
diff --git a/content/course/blockchain-fundamentals/03-payments-use-case/01-payments-use-case.mdx b/content/course/blockchain-fundamentals/03-payments-use-case/01-payments-use-case.mdx
deleted file mode 100644
index a4115d4a..00000000
--- a/content/course/blockchain-fundamentals/03-payments-use-case/01-payments-use-case.mdx
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Payments Use Case
-description: Explore how blockchain technology can revolutionize payments by building decentralized systems. This chapter delves into account balances, transactions, and user interactions, highlighting the benefits of blockchain for security, transparency, and decentralization. Discover how these concepts apply to various use cases beyond payments, including decentralized finance, voting systems, and supply chain management.
-updated: 2024-09-01
-authors: [martineckardt]
-icon: Book
----
-
-In this chapter we will dive deeper in the payments use case. We will explore how blockchain technology can be used to build a decentralized payment system. We will look at the different components of a payment system, such as account balances, transactions, and user interactions. We will also discuss the benefits of using blockchain technology for payments, such as security, transparency, and decentralization.
-
-| Use Case                  | Data Structures  	| User Interactions  	|
-|-----------------------	|------------------	|--------------------	|
-| Payments              	| Account Balances 	| Transfer Funds     	|
-| Decentralized Finance 	| Loans, ...       	| Borrow, Repay, ..  	|
-| Voting Systems        	| Votes            	| Vote               	|
-| Supply Chain          	| Shipments        	| Hand Over, Deliver 	|
-| Identity Management   	| Certificates     	| Issue, Proof       	|
-
-Many of the concepts we will discuss in this chapter are applicable to other use cases as well. For example, the idea of account balances and transactions is not unique to payments but can be found in other applications like decentralized finance (DeFi) or supply chain management. Similarly, user interactions such as transferring funds or voting can be applied to various use cases, each with its unique requirements and challenges.
-
-So while we are discussing this specific use case, try to think about how these concepts could be adapted to other scenarios. This will help you understand the broader implications of blockchain technology and how it can be used to solve a wide range of problems across different industries and domains.
\ No newline at end of file
diff --git a/content/course/blockchain-fundamentals/03-payments-use-case/02-account-balances-transfers.mdx b/content/course/blockchain-fundamentals/03-payments-use-case/02-account-balances-transfers.mdx
deleted file mode 100644
index 203537c9..00000000
--- a/content/course/blockchain-fundamentals/03-payments-use-case/02-account-balances-transfers.mdx
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Account Balances & Transfers
-description: Learn about account balances, which reflect the current amount of money or assets in an account after credits and debits. Discover how transfers work by moving funds between accounts, ensuring balance integrity across financial systems.
-updated: 2024-09-01
-authors: [martineckardt]
-icon: BookOpen
----
-
-## Account Balances
-
-Account Balances refer to the current amount of money or assets held in a specific account at a given time. This number reflects the total value after all credits (additions) and debits (subtractions) have been accounted for, indicating how much the account holder has available to use or withdraw. For example, in a bank account, the balance represents the amount of money that the account holder can access, whether for spending, saving, or transferring.
-
-<div className="max-w-96 mx-auto">
-    ![](/common-images/blockchain-basics/payments/account-balances.png)
-</div>
-
-## Transfers
-
-A Transfer is the process of moving money or assets from one account to another. During a transfer, the balance of the sending account is reduced by the amount being transferred, while the balance of the receiving account is increased by the same amount. This operation ensures that the total value across all accounts remains constant, maintaining the integrity of the overall financial system. 
-
-![](/common-images/blockchain-basics/payments/transfer.png)
-
-## Invalid Transfers
-
-An invalid transfer occurs when a transaction request exceeds the available balance in the sending account. In such cases, the transfer cannot be executed, and the system will reject the transaction to prevent overdrafts. As a result, both the sending and receiving account balances remain unchanged, preserving the integrity of the financial records. This safeguard ensures that accounts do not inadvertently fall into negative balances and maintains accurate and reliable financial tracking.
-
-![](/common-images/blockchain-basics/payments/transfer-invalid.png)
\ No newline at end of file
diff --git a/content/course/blockchain-fundamentals/03-payments-use-case/03-ledger.mdx b/content/course/blockchain-fundamentals/03-payments-use-case/03-ledger.mdx
deleted file mode 100644
index 0da665af..00000000
--- a/content/course/blockchain-fundamentals/03-payments-use-case/03-ledger.mdx
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Ledger
-description: Understand the high-level structure of this chapter.
-updated: 2024-09-01
-authors: [martineckardt]
-icon: BookOpen
----
-
-A ledger is a comprehensive record-keeping system that documents all transactions. It maintains a detailed and chronological list of transactions, capturing every transfers across accounts. This ensures that every action is accurately tracked and traceable, providing a clear and complete view of the system's activity.
-
-![](/common-images/blockchain-basics/payments/ledger.png)
-
-## Immutability
-
-An immutable ledger means that once a transaction is recorded, it cannot be altered or deleted. This immutability ensures that the historical record of all transactions remains intact and unchangeable, which is crucial for maintaining transparency and trust. Even if errors are made or transactions are invalid, the ledger preserves the original data, preventing tampering or unauthorized modifications.
-
-## Append-Only
-
-An append-only ledger operates by adding new transactions to the end of the record without altering any previous entries. This means that while the ledger grows with each new transaction, past transactions remain unchanged and preserved. Invalid transactions, which fail to execute due to issues like insufficient funds, are still recorded in the ledger to maintain a complete history. To reverse the effects of a transaction, a new transaction must be appended that counteracts the previous one, ensuring the integrity and consistency of the ledger’s overall state.
\ No newline at end of file
diff --git a/content/course/blockchain-fundamentals/04-signatures/01-signatures.mdx b/content/course/blockchain-fundamentals/04-signatures/01-signatures.mdx
deleted file mode 100644
index 7f50d95d..00000000
--- a/content/course/blockchain-fundamentals/04-signatures/01-signatures.mdx
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: Signatures
-description: Signatures
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
-
-Coming soon
\ No newline at end of file
diff --git a/content/course/blockchain-fundamentals/04-signatures/xx-signature-schemes.mdx b/content/course/blockchain-fundamentals/04-signatures/xx-signature-schemes.mdx
deleted file mode 100644
index 56998d1b..00000000
--- a/content/course/blockchain-fundamentals/04-signatures/xx-signature-schemes.mdx
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Signature Schemes
-description: TBD
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Notebook
----
-
-While transactions on ledgers in the analogue world were often authorized by hand-written signatures, that is not going to work for the adoption in blockchain. To utilize the concept of a ledger in the modern age, we leverage cryptography instead. 
-
-import SignatureSchemes from "@/content/common/cryptography/signature-schemes.mdx"
-
-<SignatureSchemes />
\ No newline at end of file
diff --git a/content/course/blockchain-fundamentals/04-tx-ordering-through-consensus/01-tx-ordering-through-consensus.mdx b/content/course/blockchain-fundamentals/04-tx-ordering-through-consensus/01-tx-ordering-through-consensus.mdx
deleted file mode 100644
index 65d4bb85..00000000
--- a/content/course/blockchain-fundamentals/04-tx-ordering-through-consensus/01-tx-ordering-through-consensus.mdx
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Transaction Ordering through Consensus
-description: TBD
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
diff --git a/content/course/blockchain-fundamentals/04-tx-ordering-through-consensus/02-longest-chain-consensus.mdx b/content/course/blockchain-fundamentals/04-tx-ordering-through-consensus/02-longest-chain-consensus.mdx
deleted file mode 100644
index 4f43b11f..00000000
--- a/content/course/blockchain-fundamentals/04-tx-ordering-through-consensus/02-longest-chain-consensus.mdx
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Longest Chain Consensus
-description: TBD
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
diff --git a/content/course/blockchain-fundamentals/04-tx-ordering-through-consensus/xx-tx-lifecycle.mdx b/content/course/blockchain-fundamentals/04-tx-ordering-through-consensus/xx-tx-lifecycle.mdx
deleted file mode 100644
index ca93dbda..00000000
--- a/content/course/blockchain-fundamentals/04-tx-ordering-through-consensus/xx-tx-lifecycle.mdx
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title: Transaction Lifecycle
-description: TBD
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Notebook
----
-
-## Creation
-
-
-## Signing
-
-
-## Broadcasting
-
-
-## Verification
-
-
-## Consensus
-
-
-## Finalization
\ No newline at end of file
diff --git a/content/course/blockchain-fundamentals/05-sybil-protection/01-sybil-protection.mdx b/content/course/blockchain-fundamentals/05-sybil-protection/01-sybil-protection.mdx
deleted file mode 100644
index 7abfabfc..00000000
--- a/content/course/blockchain-fundamentals/05-sybil-protection/01-sybil-protection.mdx
+++ /dev/null
@@ -1,8 +0,0 @@
----
-title: Sybil Protection
-description: TBD
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
-
diff --git a/content/course/blockchain-fundamentals/05-sybil-protection/02-proof-of-work.mdx b/content/course/blockchain-fundamentals/05-sybil-protection/02-proof-of-work.mdx
deleted file mode 100644
index 052d2e32..00000000
--- a/content/course/blockchain-fundamentals/05-sybil-protection/02-proof-of-work.mdx
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Proof of Work
-description: TBD
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
\ No newline at end of file
diff --git a/content/course/blockchain-fundamentals/05-sybil-protection/03-proof-of-stake.mdx b/content/course/blockchain-fundamentals/05-sybil-protection/03-proof-of-stake.mdx
deleted file mode 100644
index 6455b231..00000000
--- a/content/course/blockchain-fundamentals/05-sybil-protection/03-proof-of-stake.mdx
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: Proof of Stake
-description: TBD
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-- Carrots and Sticks
-
-## Staking Rewards
-
-- Carrot
-
-## Slashing
-
-- Stick
\ No newline at end of file
diff --git a/content/course/blockchain-fundamentals/06-smart-contracts/01-smart-contracts.mdx b/content/course/blockchain-fundamentals/06-smart-contracts/01-smart-contracts.mdx
deleted file mode 100644
index d947feb9..00000000
--- a/content/course/blockchain-fundamentals/06-smart-contracts/01-smart-contracts.mdx
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Smart Contracts
-description: TBD
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
diff --git a/content/course/blockchain-fundamentals/index.mdx b/content/course/blockchain-fundamentals/index.mdx
deleted file mode 100644
index f315d0df..00000000
--- a/content/course/blockchain-fundamentals/index.mdx
+++ /dev/null
@@ -1,37 +0,0 @@
----
-title: Welcome to the Course
-description: Learn about the basics of Avalanche.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Smile
----
-
-Welcome to the Blockchain Fundamentals, an online course introducing you to blockchain! This course will provide you with a comprehensive understanding of the basic concepts of blockchains.
-
-By the end of these courses, you'll have the knowledge and skills to leverage the power of blockchain technology for your own projects and applications. We're excited to have you join us on this journey and can't wait to see what you'll create with Avalanche!
-
-## Course Content
-
-We will cover the following topics in this course:
-
-- What is a Blockchain?
-- Deep Dive into Payments
-- Cryptography: Signature schemes
-- Consensus Mechanisms
-- ...
-
-## Prerequisites
-
-This course is for people with some blockchain knowledge. Check out this [guide](/guide/what-is-a-blockchain) to review what a blockchain is.
-
-Familiarity with the basic design of modern distributed software systems and common blockchain systems such as Bitcoin and Ethereum is also recommended. You do not need to know how to write code to successfully complete this course.
-
-Having these prerequisites will help you better understand the course material and engage in the activities. If you don't know whether you have the necessary foundation for this course, please contact the course instructor for guidance.
-
-## Learning Outcomes
-
-By the end of this course, you will have a good understanding of the basic concepts of blockchain technology.
-
-You can evaluate your own understanding of the material through quizzes and claim a certificate for successful completion at the end.
-
-Overall, this course aims to provide a foundational understanding of Avalanche. By completing it, you will be better prepared to take on more advanced courses focused on building on Avalanche.
diff --git a/content/course/blockchain-fundamentals/meta.json b/content/course/blockchain-fundamentals/meta.json
deleted file mode 100644
index 45d47184..00000000
--- a/content/course/blockchain-fundamentals/meta.json
+++ /dev/null
@@ -1,14 +0,0 @@
-{
-  "title": "blockchain-fundamentals",
-  "root": true,
-  "pages": [
-    "index",
-    "---What is a Blockchain?---",
-    "...02-what-is-a-blockchain",
-    "---Payments---",
-    "...03-payments-use-case",
-    "---Signatures---",
-    "...04-signatures",
-    "---More Coming Soon!---"
-  ]
-}
diff --git a/content/course/blockchain-fundamentals/xx-decentralization.mdx b/content/course/blockchain-fundamentals/xx-decentralization.mdx
deleted file mode 100644
index ab7dc24f..00000000
--- a/content/course/blockchain-fundamentals/xx-decentralization.mdx
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Decentralization
-description: TBD
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-
-## Moving from a centralized Entity to a Collective of Validators
-
-Blockchain systems achieve decentralization through the use of a network of validators, sometimes referred to as nodes, miners, or stakers, depending on the underlying consensus mechanism. Validators are responsible for verifying and securing transactions, maintaining the integrity of the blockchain, and ensuring that the system remains decentralized and trustless. Decentralization is achieved by distributing the responsibility of maintaining the network across numerous independent participants.
-
-Decentralization in blockchain is achieved through a network of validators. These are independent entities that run the blockchain software, perform computations, and ensure the integrity of the blockchain. Here’s how it works:
-
-Computation Execution: Each validator independently performs the same computation. For example, let's consider a simple computation: 5 + 3.
-Consensus Process: After performing the computation, validators share their results with each other. They then use a process called consensus to agree on the correct result. You can think of it as a election, where all validators vote on the correct answer.
-The consensus process ensures that all validators reach an agreement on the correct result, given that the majority is honest. This agreement is crucial for maintaining the integrity and security of the blockchain. If a validator tries to cheat or provide an incorrect result, the other validators will detect the discrepancy, and the cheating validator will be penalized.
\ No newline at end of file
diff --git a/content/course/blockchain-fundamentals/xx-regulation/01-regulation.mdx b/content/course/blockchain-fundamentals/xx-regulation/01-regulation.mdx
deleted file mode 100644
index 143aa7a6..00000000
--- a/content/course/blockchain-fundamentals/xx-regulation/01-regulation.mdx
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Regulation
-description: TBD
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
diff --git a/content/course/blockchain-fundamentals/xx-tokens.mdx b/content/course/blockchain-fundamentals/xx-tokens.mdx
deleted file mode 100644
index 4acd8bc1..00000000
--- a/content/course/blockchain-fundamentals/xx-tokens.mdx
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Tokens
-description: TBD
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Notebook
----
-
-Tokens are a concept that existed in societies for a long time. 
-
-Tokens can be used to represent value. The most common valuable tokens we use every day are fiat currencies, like the US dollar. But there are also other kinds of tokens, such as points or miles in loyalty programs. Today we can also tokenize other assets, such as property titles.
-
-## Fungible Tokens
-
-Fungibility means that different tokens can be considered of equal value. Let's take for example two one dollar bills. Most people will not care if they get one or the other. They both offer the same utility. 
-
-## Non-Fungible Tokens
-
-Non-fungible tokens are not considered equal. The most prominent use cases are Art-NFTs. While the tokens may follow a standard of how they can be transfered, they may not be interchangeable. Two pieces of art may have very different values.
\ No newline at end of file
diff --git a/content/course/customizing-evm/02-intro-to-evm/01-origin-of-evm.mdx b/content/course/customizing-evm/02-intro-to-evm/01-origin-of-evm.mdx
deleted file mode 100644
index 64795401..00000000
--- a/content/course/customizing-evm/02-intro-to-evm/01-origin-of-evm.mdx
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: Origin of the EVM
-description: Learn about the origin of the Ethereum Virtual Machine.
-updated: 2024-09-27
-authors: [ashucoder9, owenwahlgren]
-icon: BookOpen
----
-
-The **Ethereum Virtual Machine (EVM)** is a fundamental component of Ethereum’s infrastructure, responsible for executing smart contracts across the network. The origins of the EVM can be traced back to the creation of the Ethereum blockchain itself, proposed in a whitepaper by **Vitalik Buterin** in late 2013.
-
-Buterin and the founding Ethereum team envisioned a platform where developers could build **decentralized applications (dApps)** on a blockchain. To accomplish this, they needed a way to execute arbitrary, complex computations in a secure and decentralized manner. This is how the concept of the EVM was born.
-
-The EVM, an integral part of the Ethereum ecosystem, operates as a **quasi-Turing complete machine**. This means it can run nearly any algorithm, given enough resources. It's isolated from the main network, providing a sandboxed environment for smart contract execution.
-
-Following the publication of the whitepaper, the Ethereum project moved into development. The first live version of the Ethereum network, including the EVM, launched on **July 30, 2015**. The Ethereum blockchain was designed with the EVM at the protocol level, enabling users to create and execute smart contracts. These smart contracts are essentially programs that autonomously execute the terms of an agreement. They are written in high-level languages like **Solidity** or **Vyper**, which are then compiled down to EVM bytecode for execution on the EVM.
-
-Since its creation, the EVM has become a crucial component of the Ethereum blockchain and has set a standard for other blockchain platforms that have adopted similar models for executing smart contracts. The advent of the EVM has undoubtedly revolutionized the blockchain world by introducing the concept of **programmable blockchains**.
diff --git a/content/course/customizing-evm/02-intro-to-evm/02-accounts-keys-address.mdx b/content/course/customizing-evm/02-intro-to-evm/02-accounts-keys-address.mdx
deleted file mode 100644
index 39741585..00000000
--- a/content/course/customizing-evm/02-intro-to-evm/02-accounts-keys-address.mdx
+++ /dev/null
@@ -1,37 +0,0 @@
----
-title: Accounts, Keys, and Addresses
-description: Learn about Accounts, Keys, and Addresses in EVM.
-updated: 2024-09-27
-authors: [ashucoder9, owenwahlgrne]
-icon: BookOpen
----
-
-## Accounts
-
-In the EVM, there are two types of accounts:
-
-1. **Externally Owned Accounts (EOAs)**: These accounts are controlled by private keys and do not have associated code. They can send transactions by creating and signing them with their private keys. If you're an end user of Ethereum, you're likely using an EOA.
-
-2. **Contract Accounts**: These accounts have associated code (smart contracts). Contract accounts can't initiate transactions on their own; instead, they only perform actions when instructed by an EOA. This could be as simple as a token transfer or a function call within a smart contract.
-
-## Public and Private Keys
-
-In Ethereum, as in many blockchain platforms, the **Elliptic Curve Digital Signature Algorithm (ECDSA)** is used to generate a pair of keys: a public key and a private key.
-
-- The **private key** is a 32-byte number generated randomly.
-- The **public key** is derived from the private key using elliptic curve cryptography. It is 64 bytes long, made up of two concatenated 32-byte coordinates.
-
-## Addresses
-
-An EVM address is derived from the public key through the following steps:
-
-1. **Keccak-256 Hashing**: The public key is first passed through the Keccak-256 hashing function (the version of SHA-3 used by Ethereum). Keccak-256 outputs a 64-byte string, for example:
-   `025ad33e2479a53b02dc0be66eb0ce272fc0f4358c57a8f0a442410c3d831a`
-
-2. **Rightmost 20 bytes**: The resulting string is truncated to keep only the last 20 bytes. In hexadecimal, this means retaining the rightmost 40 hex digits (since two hex digits represent one byte), like so:
-   `e66eb0ce272fc0f4358c57a8f0a442410c3d831a`
-
-3. **Adding '0x'**: Finally, "0x" is prefixed to the address for a total of 42 characters. The "0x" indicates that the following characters represent a hexadecimal number, a common convention in Ethereum:
-   `0xe66eb0ce272fc0f4358c57a8f0a442410c3d831a`
-
-This process ensures that each Ethereum address uniquely corresponds to a public key. Since the address is a truncated hash of the public key, it's impossible to reverse-engineer the public key from the address.
diff --git a/content/course/customizing-evm/02-intro-to-evm/03-transactons-and-blocks.mdx b/content/course/customizing-evm/02-intro-to-evm/03-transactons-and-blocks.mdx
deleted file mode 100644
index 4bab0584..00000000
--- a/content/course/customizing-evm/02-intro-to-evm/03-transactons-and-blocks.mdx
+++ /dev/null
@@ -1,37 +0,0 @@
----
-title: Transactions and Blocks
-description: Learn about another fundamental aspect of the Ethereum ecosystem - Transactions and Blocks.
-updated: 2024-09-27
-authors: [ashucoder9, owenwahlgren]
-icon: BookOpen
----
-
-## Transactions
-
-In the EVM, a transaction is the smallest unit of work that can be included in a block. It represents a **state transition**, modifying account data and transferring Ether across the network.
-
-Transactions can either transfer Ether or invoke smart contracts. Each transaction includes the following components:
-
-- **Nonce**: A unique value set by the sender to ensure the transaction is processed only once, preventing replay attacks.
-- **Gas Price**: The amount the sender is willing to pay per unit of gas, typically measured in `nanoAvax` (1 `nAvax` = 1/(10^9) Avax). It consists of three parts:
-  - **Base Gas Fee**: The minimum `nAvax` required per unit of gas.
-  - **Maximum Priority Gas Fee**: Additional `nAvax` the sender is willing to pay on top of the base fee.
-  - **Maximum Total Gas Fee**: The maximum `nAvax` the sender is willing to spend per unit of gas. If the sum of the base gas fee and the priority gas fee exceeds this amount, the gas price paid will be capped at the maximum total gas fee.
-- **Gas Limit**: The maximum amount of gas units the sender is willing to pay for executing the transaction. If this limit is reached, the transaction fails, preventing indefinite execution.
-- **To**: The recipient's Ethereum address or the target smart contract.
-- **V, R, S**: Cryptographic data used to create the sender's signature.
-
-## Blocks
-
-A block in the EVM is a bundle of validated transactions, grouped together and linked to the previous block. Each block contains:
-
-- **Block Number**: The index of the block, representing its position in a zero-indexed linked list.
-- **Timestamp**: The time the block was mined.
-- **Transactions Root**: The Merkle root of all transactions within the block.
-- **Receipts Root**: The Merkle root of all transaction receipts.
-- **State Root**: A hash of the entire Ethereum state after executing all transactions in the block.
-- **Parent Hash**: The hash of the previous (parent) block.
-- **Gas Limit**: The maximum gas all transactions in the block can consume.
-- **Gas Used**: The total gas consumed by all transactions in the block.
-- **Extra Data**: An optional field for including arbitrary data up to 32 bytes.
-- **Validator**: The address of the node that proposed the block.
diff --git a/content/course/customizing-evm/02-intro-to-evm/05-different-evm-versions.mdx b/content/course/customizing-evm/02-intro-to-evm/05-different-evm-versions.mdx
deleted file mode 100644
index f8f9401f..00000000
--- a/content/course/customizing-evm/02-intro-to-evm/05-different-evm-versions.mdx
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: Different Versions of EVM
-description: Learn about the different versions of the Ethereum Virtual Machine in the Avalanche ecosystem.
-updated: 2024-09-27
-authors: [ashucoder9, owenwahlgren]
-icon: BookOpen
----
-
-## Geth
-
-Geth (or [go-ethereum](https://github.com/ethereum/go-ethereum)) is the official implementation of an Ethereum client, written in the Go programming language. It is one of the original and most widely used Ethereum clients today. Geth handles transactions, deploys and executes smart contracts, and contains the Ethereum Virtual Machine.
-
-## Coreth
-
-[Coreth](https://github.com/ava-labs/coreth) is a fork of Geth maintained by Ava Labs. It implements the EVM for the C-Chain and has been adapted to work with Avalanche Consensus.
-
-## Subnet-EVM
-
-[Subnet-EVM](https://github.com/ava-labs/subnet-evm) is a fork of Coreth designed to facilitate launching customized EVM-based blockchains on an Avalanche L1. It differs from Coreth in the following ways:
-
-- **Configurable Fees and Gas Limits**: Customizable fees and gas limits can be set in the genesis file.
-- **Unified Subnet-EVM Hardfork**: All Avalanche hardforks are merged into a single "Subnet-EVM" hardfork.
-- **Atomic Transactions and Shared Memory Removed**: Support for atomic transactions and shared memory has been removed.
-- **Multicoin Contracts and State Removed**: Multicoin contracts and state tracking are no longer supported.
-
-## Precompile-EVM
-
-Precompile-EVM allows precompiles to be registered with Subnet-EVM without needing to fork the Subnet-EVM codebase. This simplifies common customizations to Subnet-EVM, making them more accessible and easier to maintain. It also streamlines updates for Subnet-EVM.
diff --git a/content/course/customizing-evm/03-development-env-setup/00-intro.mdx b/content/course/customizing-evm/03-development-env-setup/00-intro.mdx
deleted file mode 100644
index af53bcb0..00000000
--- a/content/course/customizing-evm/03-development-env-setup/00-intro.mdx
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Set Up Development Environment
-description: Start by setting up your development environment.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Book
----
-
-It's time to set up the development environment necessary for customizing the EVM! While the primary focus of this course is teaching you about precompiles, it's also crucial to configure a development environment that ensures a smooth and efficient workflow.
-
-In this section, we will cover the following:
-
-- Creating a GitHub repository for our customized EVM
-- Setting up a default test account in your Core Wallet
-- Exploring different types of development setups
-- Choosing the setup for developing precompiles
-
-Let's get started! 🚀
diff --git a/content/course/customizing-evm/03-development-env-setup/02-create-codespaces.mdx b/content/course/customizing-evm/03-development-env-setup/02-create-codespaces.mdx
deleted file mode 100644
index 787657bb..00000000
--- a/content/course/customizing-evm/03-development-env-setup/02-create-codespaces.mdx
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title: Create Codespaces
-description: Learn how to create GitHub Codespaces.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-## Open Precompile-EVM Repository
-
-Open the Precompile-EVM Repository on the `avalanche-academy-start` branch: [Precompile-EVM](https://github.com/ava-labs/precompile-evm/tree/avalanche-academy-start)
-
-## Create Codespace
-
-Make sure you are on the branch `avalanche-academy-start`. Then click Code and then Create codespace on `avalanche-academy-start`:
-
-![](/course-images/customizing-evm/10.png)
-
-Next a window opens and the Codespace is built. This may take a few minutes.
-
-![](/course-images/customizing-evm/11.png)
-
-When the building is completed, you can access the Codespace through the browser IDE.
-
-## Closing Codespaces
-
-The codespace time out after 30 minutes of inactivity by default. So if you are not too worried about the 30 hour/month limit, just close the window or the tab. Alternatively, you can open the command prompt (Cmd + Shift + P) and issue the command: **Stop Current Codespace**.
-
-![](/course-images/customizing-evm/12.png)
-
-## Reopen Codespaces
-
-You can see your Codespaces on https://github.com/codespaces/. There you can stop them, reopen them and delete them.
-
-![](/course-images/customizing-evm/13.png)
\ No newline at end of file
diff --git a/content/course/customizing-evm/03-development-env-setup/03-codespace-in-vscode.mdx b/content/course/customizing-evm/03-development-env-setup/03-codespace-in-vscode.mdx
deleted file mode 100644
index e228d44c..00000000
--- a/content/course/customizing-evm/03-development-env-setup/03-codespace-in-vscode.mdx
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Codespace in VS Code
-description: Learn how to setup GitHub Codespaces.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-## Switch from Browser to VS Code
-
-You can switch any time from the browser IDE to Visual Studio Code:
-
-![](/course-images/customizing-evm/14.png)
-
-The first time you switch, you will be asked to install the [Codespaces extension](https://marketplace.visualstudio.com/items?itemName=GitHub.codespaces) and connect VS Code to you GitHub account, if it is not already connceted.
\ No newline at end of file
diff --git a/content/course/customizing-evm/04-your-evm-blockchain/00-intro.mdx b/content/course/customizing-evm/04-your-evm-blockchain/00-intro.mdx
deleted file mode 100644
index 8fc6f571..00000000
--- a/content/course/customizing-evm/04-your-evm-blockchain/00-intro.mdx
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: Your Own EVM Blockchain
-description: Learn how to spin up your own EVM blockchain.
-updated: 2024-09-27
-authors: [ashucoder9, owenwahlgren]
-icon: Book
----
-
-In this part of the course, we'll explore how to run your own Avalanche L1 with a custom EVM. Running your own EVM allows you to address specific use cases, showcasing one of the key advantages of multi-chain systems over monolithic blockchains.
-
-## Topics
-
-We’ll cover the following topics:
-
-- **Avalanche CLI**: Learn how to configure and launch an Avalanche L1 using the Avalanche CLI.
-- **Token Transfer**: Explore how to perform token transfers with Foundry.
-
-This hands-on exercise will solidify your knowledge and allow you to observe how customizations impact EVM performance.
-
-## Learning Objective
-
-By the end of this section, you’ll have the skills to effectively run your own Avalanche L1 with a custom EVM blockchain, empowering you to start building your blockchain projects!
diff --git a/content/course/customizing-evm/04-your-evm-blockchain/01-avalanche-cli.mdx b/content/course/customizing-evm/04-your-evm-blockchain/01-avalanche-cli.mdx
deleted file mode 100644
index 78b99fa8..00000000
--- a/content/course/customizing-evm/04-your-evm-blockchain/01-avalanche-cli.mdx
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Avalanche CLI
-description: Learn about the Avalanche Command-Line Interface tooling.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-## What is the Avalanche CLI?
-
-The Avalanche CLI is a command-line tool that gives developers comprehensive access to Avalanche's functionalities, making it easier to build and test independent blockchains.
-
-Each Avalanche network includes the Primary Network, which consists of the Contract (C), Platform (P), and Exchange (X) chains. It's important to note that "Primary Network" refers to a special Avalanche L1 rather than a distinct, standalone network.
-
-Your local network operates independently from both the Mainnet and Fuji Testnet. You can even run an Avalanche L1 offline. Local Avalanche networks support, but are not limited to, the following commands:
-
-- **Start and Stop a Network**: Easily start or stop a local network.
-- **Health Check**: Check the health status of each node in the network.
-- **Create Blockchains**: Spin up new blockchains with custom parameters.
-
-Managing a local network with multiple nodes can be complex, but the Avalanche CLI simplifies the process with user-friendly commands.
-
-## Usage
-
-The Precompile-EVM repository comes preloaded with the Avalanche CLI and Foundry, so you don’t need to install additional tools when working within Codespaces. Just use the terminal in your Codespace to run Avalanche CLI commands and start building.
diff --git a/content/course/customizing-evm/04-your-evm-blockchain/02-create-your-blockchain.mdx b/content/course/customizing-evm/04-your-evm-blockchain/02-create-your-blockchain.mdx
deleted file mode 100644
index 0d660a65..00000000
--- a/content/course/customizing-evm/04-your-evm-blockchain/02-create-your-blockchain.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Create Your Blockchain
-description: Learn how to use Avalanche-CLI to spin up your own EVM blockchain.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-import CreateDefaultBlockchain from "@/content/common/avalanche-starter-kit/create-default-blockchain.mdx";
-
-<CreateDefaultBlockchain/>
\ No newline at end of file
diff --git a/content/course/customizing-evm/04-your-evm-blockchain/03-sending-tokens.mdx b/content/course/customizing-evm/04-your-evm-blockchain/03-sending-tokens.mdx
deleted file mode 100644
index c0c93353..00000000
--- a/content/course/customizing-evm/04-your-evm-blockchain/03-sending-tokens.mdx
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: Sending Tokens
-description: Learn how to send tokens on your EVM blockchain.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-To ensure that the blockchain is up and running, let's perform a simple token transfer to a random address, `0x321f6B73b6dFdE5C73731C39Fd9C89c7788D5EBc`, using Foundry:
-
-```bash
-cast send --rpc-url myblockchain --private-key $PK 0x321f6B73b6dFdE5C73731C39Fd9C89c7788D5EBc --value 1ether
-```
-To verify if the transaction was successful, check the balance of the address with the following command:
-
-
-```bash
-cast balance --rpc-url myblockchain 0x321f6B73b6dFdE5C73731C39Fd9C89c7788D5EBc
-```
-```bash
-1000000000000000000
-```
-You should see that the balance of the address `0x321f6B73b6dFdE5C73731C39Fd9C89c7788D5EBc` is now 1 (1 * 10^18).
-
-
-Congratulations! You have successfully sent tokens on your EVM blockchain. 🎉
-
-
diff --git a/content/course/customizing-evm/05-genesis-configuration/00-vm-configuration.mdx b/content/course/customizing-evm/05-genesis-configuration/00-vm-configuration.mdx
deleted file mode 100644
index 30a2c312..00000000
--- a/content/course/customizing-evm/05-genesis-configuration/00-vm-configuration.mdx
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: EVM Configuration
-description: Learn about Virtual Machine configuration.
-updated: 2024-09-27
-authors: [ashucoder9]
-icon: Book
----
-
-In this part of the course, we'll explore how to optimize your EVM through chain configuration, tailoring it to fit specific use cases. Customizing EVM configurations is a key advantage of multi-chain systems.
-
-## Exercise
-
-In this section, you won’t need to write any Go code. Instead, we’ll adjust values in the JSON file of the genesis block.
-
-## Topics
-
-We will cover the following topics:
-
-- **Genesis Block**: The foundation of any blockchain. We’ll review its components and how to customize its properties.
-- **Fee Configuration**: Learn how to balance validator incentives with user affordability. This is crucial for managing network congestion and discouraging wasteful transactions on public networks.
-- **Initial Token Allocation**: Understand how to define the initial token distribution in your custom EVM, setting your network up for success.
-- **Preinstalled Precompiles**: Discover how to configure preinstalled precompiles to leverage features like restricting who can issue transactions or deploy contracts on your chain.
-
-Finally, we’ll demonstrate how to run a local EVM with a custom Genesis Block. This exercise will solidify your understanding and allow you to observe the performance impact of your EVM customizations.
-
-## Learning Objective
-
-By the end of this section, you'll be able to effectively customize the EVM in Avalanche, unlocking new possibilities for your blockchain projects. Let’s dive into EVM customization and chain configuration together!
diff --git a/content/course/customizing-evm/05-genesis-configuration/01-genesis-block.mdx b/content/course/customizing-evm/05-genesis-configuration/01-genesis-block.mdx
deleted file mode 100644
index 6028f912..00000000
--- a/content/course/customizing-evm/05-genesis-configuration/01-genesis-block.mdx
+++ /dev/null
@@ -1,71 +0,0 @@
----
-title: Genesis Block
-description: Learn about the Genesis Block.
-updated: 2024-09-27
-authors: [ashucoder9]
-icon: BookOpen
----
-
-## Background
-
-Each blockchain begins with a genesis state when it is created. For instance, the Ethereum mainnet genesis block included the addresses and balances from the Ethereum pre-sale, marking the initial distribution of ether.
-
-For Subnet-EVM and Precompile-EVM, the genesis block contains additional parameters that allow us to configure the behavior of our customized EVM to meet specific requirements. Since each blockchain has its own genesis block, you can create two blockchains with the same VM but different genesis blocks.
-
-## Format
-
-Here’s an example of a genesis block:
-
-```json
-{
-  "config": {
-    "chainId": 43214,
-    "homesteadBlock": 0,
-    "eip150Block": 0,
-    "eip150Hash": "0x2086799aeebeae135c246c65021c82b4e15a2c451340993aacfd2751886514f0",
-    "eip155Block": 0,
-    "eip158Block": 0,
-    "byzantiumBlock": 0,
-    "constantinopleBlock": 0,
-    "petersburgBlock": 0,
-    "istanbulBlock": 0,
-    "muirGlacierBlock": 0,
-    "subnetEVMTimestamp": 0,
-    "feeConfig": {
-      "gasLimit": 15000000,
-      "minBaseFee": 25000000000,
-      "targetGas": 15000000,
-      "baseFeeChangeDenominator": 36,
-      "minBlockGasCost": 0,
-      "maxBlockGasCost": 1000000,
-      "targetBlockRate": 2,
-      "blockGasCostStep": 200000
-    },
-    "allowFeeRecipients": false, 
-    "txAllowListConfig": {
-      "blockTimestamp": 0,
-      "adminAddresses": [
-        "0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC"
-      ]
-    }
-  },
-  "alloc": {
-    "8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC": {
-      "balance": "0x295BE96E64066972000000"
-    }
-  },
-  "nonce": "0x0",
-  "timestamp": "0x0",
-  "extraData": "0x00",
-  "gasLimit": "0xe4e1c0",
-  "difficulty": "0x0",
-  "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
-  "coinbase": "0x0000000000000000000000000000000000000000",
-  "number": "0x0",
-  "gasUsed": "0x0",
-  "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000"
-}
-```
-We will explore the relevant configurable parameters in the upcoming activities. Some parameters (e.g., `eip150Block`, `byzantiumBlock`) are omitted here as they are not relevant for most use cases.
-
-This version provides a clean and concise explanation of the genesis block and its structure, keeping the focus on what's essential.
diff --git a/content/course/customizing-evm/05-genesis-configuration/02-create-your-genesis.mdx b/content/course/customizing-evm/05-genesis-configuration/02-create-your-genesis.mdx
deleted file mode 100644
index 500350d5..00000000
--- a/content/course/customizing-evm/05-genesis-configuration/02-create-your-genesis.mdx
+++ /dev/null
@@ -1,72 +0,0 @@
----
-title: Create Your Genesis File
-description: Learn how to create your own genesis file.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-import { Callout } from 'fumadocs-ui/components/callout';
-
-## Create File
-
-In your Precompile-EVM project, create a file called `evm-configuration-genesis.json` in the directory `tests/precompile/genesis/` and open it. You can use the command below as a shortcut to open the file in VSCode:
-
-```bash
-code ./tests/precompile/genesis/evm-configuration-genesis.json
-```
-
-## Fill with template
-
-Paste the following template in the new file:
-
-```json
-{
-    "config": {
-      "chainId":  <your-chain-id>,
-      "homesteadBlock": 0,
-      "eip150Block": 0,
-      "eip150Hash": "0x2086799aeebeae135c246c65021c82b4e15a2c451340993aacfd2751886514f0",
-      "eip155Block": 0,
-      "eip158Block": 0,
-      "byzantiumBlock": 0,
-      "constantinopleBlock": 0,
-      "petersburgBlock": 0,
-      "istanbulBlock": 0,
-      "muirGlacierBlock": 0,
-      "subnetEVMTimestamp": 0,
-      "feeConfig": {
-        "gasLimit": <your-gas-limit>,
-        "minBaseFee": <your-min-base-fee>,
-        "targetGas": <your-target-gas>,
-        "baseFeeChangeDenominator": 36,
-        "minBlockGasCost": <your-min-block-gas-cost>,
-        "maxBlockGasCost": <your-max-block-gas-cost>,
-        "targetBlockRate": <your-target-block-rate>,
-        "blockGasCostStep": <your-block-gas-cost-step>
-      },
-      "allowFeeRecipients": false
-    },
-    "alloc": {
-      "<your-test-wallet-address>": {
-        "balance": "<your-initial-balance-converted-to-hex>"
-      }
-    },
-    "nonce": "0x0",
-    "timestamp": "0x0",
-    "extraData": "0x00",
-    "gasLimit": <your-gas-limit>,
-    "difficulty": "0x0",
-    "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
-    "coinbase": "0x0000000000000000000000000000000000000000",
-    "number": "0x0",
-    "gasUsed": "0x0",
-    "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000"
-  }
-```
-
-<Callout title="Warning about gasLimit" type="warn">
-If you do decide to set your own gasLimit, please set all gasLimit keys equal to the same value! 
-
-If you set the 'gasLimit' keys to different values, you will still be able to deploy a blockchain, but it will halt during initialization!
-</Callout>
\ No newline at end of file
diff --git a/content/course/customizing-evm/05-genesis-configuration/03-setup-chainid.mdx b/content/course/customizing-evm/05-genesis-configuration/03-setup-chainid.mdx
deleted file mode 100644
index 34030f6a..00000000
--- a/content/course/customizing-evm/05-genesis-configuration/03-setup-chainid.mdx
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Setup Your ChainID
-description: Learn how to setup ChainID for your own blockchain.
-updated: 2024-09-27
-authors: [ashucoder9]
-icon: Terminal
----
-
-## What is ChainID?
-
-The `ChainID` of an EVM blockchain is a unique identifier that distinguishes Ethereum chains from one another. Introduced in Ethereum Improvement Proposal (EIP) 155, this mechanism prevents transaction replay attacks, which could occur when the same transaction is valid across multiple chains.
-
-## Setting the ChainID
-
-To set the `ChainID` for your blockchain, configure it in the `genesis` JSON file at the top level with the value `99999`.
-
-If you wish to use a custom `ChainID`, check [chainlist.org](https://chainlist.org) to ensure your proposed `ChainID` is not in use by any other network. Be sure to cross-check with Testnets as well!
-
-![](/course-images/customizing-evm/28.png)
diff --git a/content/course/customizing-evm/05-genesis-configuration/04-gas-fees-and-limit.mdx b/content/course/customizing-evm/05-genesis-configuration/04-gas-fees-and-limit.mdx
deleted file mode 100644
index cd87a230..00000000
--- a/content/course/customizing-evm/05-genesis-configuration/04-gas-fees-and-limit.mdx
+++ /dev/null
@@ -1,33 +0,0 @@
----
-title: Gas Fees and Gas Limit
-description: Learn about Gas Fees and Gas Limit in the context of the EVM.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-## Background
-
-In the context of the EVM, gas is a unit that measures the computational effort required to execute specific operations. Each operation performed by a contract or transaction on an EVM chain consumes a certain number of gas units based on its complexity. Operations that require more computational resources cost more gas. The EVM calculates the required gas units automatically, and developers are encouraged to optimize their contract code to reduce gas consumption.
-
-The cost of executing a transaction is determined by the gas units consumed and the gas price, calculated as follows:
-
-```
-Transaction Cost = Gas Units * Gas Price
-```
-
-For EVM Avalanche L1s, gas payment can be configured to better suit the use case of the Avalanche L1. This means that the Avalanche L1 design can decide whether the gas fees are burned, paid to incentivize validators, or used for any other custom behavior.
-
-## Purpose
-
-The primary goal of setting and enforcing computational costs via gas is to prevent spam and abuse on the network. By requiring users to pay for each computational step, the network deters malicious actors from launching denial-of-service (DoS) attacks, which involve flooding the network with spurious transactions. Essentially, the gas system serves as a deterrent against such attacks.
-
-## Gas Price and Gas Limit
-
-Each transaction specifies the gas price and gas limit:
-
-**`Gas Price`:** The gas price is the amount of the Avalanche L1's native token that the sender is willing to spend per unit of gas, typically denoted in `gwei` (1 native token = 1,000,000,000 `gwei`). A well-designed gas mechanism adapts the gas price according to network activity to protect the network from spam.
-
-**`Gas Limit`:** The gas limit is the maximum amount of gas the sender is willing to use for the transaction. It was introduced to prevent infinite loops in contract execution. In a Turing-complete language like Solidity (the main programming language in the EVM), it is possible to write a contract with an infinite loop, either accidentally or intentionally. While an infinite loop might be a nuisance in traditional computing, it could cause significant issues in a decentralized blockchain by causing the network to hang as it attempts to process a never-ending transaction. The gas limit prevents this by halting execution once the gas consumed reaches the limit.
-
-If a transaction exceeds the gas limit, it fails, but the fee amounting to the gas limit is still paid by the sender.
diff --git a/content/course/customizing-evm/05-genesis-configuration/05-gas-fee-configuration.mdx b/content/course/customizing-evm/05-genesis-configuration/05-gas-fee-configuration.mdx
deleted file mode 100644
index 1c393760..00000000
--- a/content/course/customizing-evm/05-genesis-configuration/05-gas-fee-configuration.mdx
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: Gas Fees Configuration
-description: Learn how to configure gas fees in your EVM blockchain.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-## Configuration Format
-
-The fees are configured in the `chainConfig` in the `feeConfig` field:
-
-```json
-{
-  "config": {
-    // ...
-    "feeConfig": { // [!code highlight]
-      "gasLimit": 15000000,
-      "minBaseFee": 25000000000,
-      "targetGas": 15000000,
-      "baseFeeChangeDenominator": 36,
-      "minBlockGasCost": 0,
-      "maxBlockGasCost": 1000000,
-      "targetBlockRate": 2,
-      "blockGasCostStep": 200000
-    },
-    "allowFeeRecipients": false
-  },
-  "alloc": {
-    // ...
-  },
-  // ...
-    
-  "gasLimit": 0xe4e1c0,
-  // ...
-}
-```
-
-## Gas Configuration Parameters
-
-### `gasLimit`
-
-Sets the maximum amount of gas consumed per block. This restriction caps the computational capacity of a single block and thereby limits the maximum gas usage allowed for any single transaction. For reference, the C-Chain value is set to 15,000,000.
-
-You might notice that the `gasLimit` field appears twice. This is because Avalanche introduced its own fee configuration under the `feeConfig` key while maintaining compatibility with the standard EVM configuration. Ensure that both fields have the same decimal and hexadecimal equivalent values.
-
-### `targetBlockRate`
-
-Specifies the target rate of block production in seconds. For instance, a target of 2 aims to produce a block every 2 seconds. If blocks are produced faster than this rate, it signals that more blocks are being issued to the network than anticipated, leading to an increase in base fees. For C-Chain, this value is set to 2.
-
-### `minBaseFee`
-
-Establishes a lower bound on the EIP-1559 base fee for a block. This minimum base fee effectively sets the minimum gas price for any transaction included in that block.
-
-### `targetGas`
-
-Indicates the targeted amount of gas (including block gas cost) to be consumed within a rolling 10-second window. The dynamic fee algorithm adjusts the base fee proportionally based on how actual network activity compares to this target. If network activity exceeds the `targetGas`, the base fee is increased accordingly.
-
-### `baseFeeChangeDenominator`
-
-Determines how much to adjust the base fee based on the difference between actual and target utilization. A larger denominator results in a slower-changing base fee, while a smaller denominator allows for quicker adjustments. For C-Chain, this value is set to 36, meaning the base fee changes by a factor of 1/36 of the parent block's base fee.
-
-### `minBlockGasCost`
-
-Sets the minimum amount of gas charged for the production of a block. In the C-Chain, this value is set to 0.
-
-### `maxBlockGasCost`
-
-Specifies the maximum amount of gas charged for the production of a block.
-
-### `blockGasCostStep`
-
-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.
diff --git a/content/course/customizing-evm/05-genesis-configuration/06-configuring-gas-fees.mdx b/content/course/customizing-evm/05-genesis-configuration/06-configuring-gas-fees.mdx
deleted file mode 100644
index d188c9ef..00000000
--- a/content/course/customizing-evm/05-genesis-configuration/06-configuring-gas-fees.mdx
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: Configure Gas Fees
-description: Learn how to configure gas fees in your EVM blockchain.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-## Benchmarks
-
-You can take these numbers below as a benchmark:
-
-```json
-"feeConfig": {
-        "gasLimit": 15000000,
-        "minBaseFee": 25000000000,
-        "targetGas": 15000000,
-        "baseFeeChangeDenominator": 36,
-        "minBlockGasCost": 0,
-        "maxBlockGasCost": 1000000,
-        "targetBlockRate": 2,
-        "blockGasCostStep": 200000
-      },
-        
-"gasLimit": 0xe4e1c0,
-```
-
-## Choose Your Own Values
-
-### `gasLimit`
-
-As previously discussed, the `gasLimit` acts as a restriction on the amount of computation that can be executed in a single block, and hence caps the maximum transaction size, as the entire transaction needs to be processed within the same block.
-
-Your choice of `gasLimit` values should depend on the specific use case and computational demands of your application. Here are some considerations:
-
-**High Throughput:** If your application requires a high volume of transactions, you might want to allow for more transactions (i.e., more computation) to be packed into a single block. This increases the block capacity and enables handling a higher transaction load.
-
-**Heavy Transactions:** Transactions that involve deploying large contracts or executing complex operations tend to consume more gas. If your application involves such operations, ensure that your `gasLimit` accommodates the full execution of these heavy transactions or contract deployments.
-
-Be cautious with setting excessively high `gasLimit` values. Larger computational allowances per block can translate to increased hardware requirements for your blockchain. Therefore, align the `gasLimit` with your use case and infrastructure requirements for validators. Avoid setting an unusually large value "just in case." For reference, consider that a typical native token transaction costs around 21,000 gas units, and the C-Chain `gasLimit` is set to 15,000,000.
-
-### Gas Price Parameters
-
-The following parameters affect the gas pricing and dynamic adjustments in your network:
-
-- **`minBaseFee`**: Sets the minimum base fee per unit of gas, establishing the lower bound for transaction costs in a block.
-- **`targetGas`**: Defines the target amount of gas to be consumed within a rolling 10-second window. Adjust this based on the expected network activity under normal conditions.
-- **`baseFeeChangeDenominator`**: Controls how quickly the base fee adjusts in response to fluctuations in gas usage. A smaller denominator allows for faster adjustments.
-- **`minBlockGasCost`**: Specifies the minimum gas cost for producing a block.
-- **`maxBlockGasCost`**: Sets the maximum gas cost for producing a block.
-- **`targetBlockRate`**: Determines the desired block production rate in seconds. Choose this based on your expected block issuance frequency.
-- **`blockGasCostStep`**: Adjusts the block gas cost based on the deviation from the target block rate. A higher step value increases the block gas cost more rapidly with deviations.
-
-These parameters should be selected based on the stability of gas usage in your network. Since gas fees are crucial for protecting against spam and abuse, carefully consider how these parameters will adapt to changes in network activity. The goal is to dynamically adjust transaction costs during irregular activity periods while maintaining stability under normal conditions.
diff --git a/content/course/customizing-evm/05-genesis-configuration/07-initial-token-allocation.mdx b/content/course/customizing-evm/05-genesis-configuration/07-initial-token-allocation.mdx
deleted file mode 100644
index 0e4ce4b4..00000000
--- a/content/course/customizing-evm/05-genesis-configuration/07-initial-token-allocation.mdx
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: Initial Token Allocation
-description: Learn about the initial token allocation and configure in your EVM blockchain.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-import { Callout } from 'fumadocs-ui/components/callout';
-
-## Background
-
-`Alloc` defines the initial balances of addresses at the time of chain creation. This field should be modified according to the specific requirements of each chain.
-
-If no genesis allocation is provided, you won't be able to interact with your new chain, as all transactions require a fee to be paid from the sender's balance. Without an initial allocation, there will be no funds available to cover transaction fees.
-
-## Format
-
-The `alloc` field expects key-value pairs. Keys must be valid addresses, and the balance field in each value can be either a hexadecimal or decimal number representing the initial balance of the address.
-
-```json
-{
-  "config": {
-    // ...
-  },
-  "alloc": { // [!code highlight]
-    "8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC": {
-      "balance": "0x295BE96E64066972000000" // 50,000,000 tokens
-    }
-  },
-  // ...
-}
-```
-
-Keys in the allocation are hex addresses without the canonical 0x prefix. Balances are denominated in `Wei` (10^18 `Wei` = 1 Whole Unit of the native token of the chain) and expressed as hex strings with the canonical 0x prefix. Use [this converter](https://www.rapidtables.com/convert/number/hex-to-decimal.html) for translating between decimal and hex numbers.
-
-The default configuration for testing purposes allocates a significant number of tokens to the address `8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC`. 
-
-The private key for this address (as defined in the `.devcontainer`) is: `56289e99c94b6912bfc12adc093c9b51124f0dc54ac7a766b2bc5ccf558d8027`.
-
-<Callout title="Warning" type="warn"> Never use this address or private key for anything other than testing on a local test network. The private key is publicly known, and any real funds transferred to this address are likely to be stolen. </Callout>
-
-
-## Configure
-
-Allocate tokens to two addresses:
-
-- The well-known test address `8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC`.
-- Another test address that you have created (avoid using addresses associated with real funds).
-
-```json
-{
-  "config": {
-    // ...
-  },
-  "alloc": {
-    "8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC": { // [!code highlight]
-      "balance": "0x295BE96E64066972000000" // 50,000,000 tokens
-    },
-    "<your_address>": { // [!code highlight]
-      "balance": "0x295BE96E64066972000000" // 50,000,000 tokens
-    }
-  },
-  // ...
-}
-
-```
\ No newline at end of file
diff --git a/content/course/customizing-evm/05-genesis-configuration/08-build-and-run-custom-genesis-blockchain.mdx b/content/course/customizing-evm/05-genesis-configuration/08-build-and-run-custom-genesis-blockchain.mdx
deleted file mode 100644
index 2b0683d0..00000000
--- a/content/course/customizing-evm/05-genesis-configuration/08-build-and-run-custom-genesis-blockchain.mdx
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title: Build and Run Custom Genesis EVM
-description: Learn how to build and run your blockchain with custom genesis file.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-## Build the Precompile-EVM
-
-In the root of your Precompile-EVM, run the following script:
-
-```bash
-./scripts/build.sh
-```
-
-## Start an Avalanche Network with a New Blockchain
-You can run your Precompile-EVM by using the Avalanche CLI.
-
-First, create the configuration for your blockchain:
-
-```bash
-avalanche blockchain create myblockchain --custom --vm $AVALANCHEGO_PLUGIN_PATH/srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy --genesis ./.devcontainer/genesis-example.json
-```
-
-<Callout type="info"> Make sure you replace the binary name with the actual binary name of your Precompile-EVM, and genesis file with the actual path to your genesis file. </Callout>
-
-Next, launch the Avalanche L1 with your custom VM:
-
-```bash
-avalanche blockchain deploy myblockchain
-```
-
-After around 1 minute, the blockchain should have been created, and additional output will appear in the terminal. You'll also see the RPC URL of your blockchain in the terminal.
-
diff --git a/content/course/customizing-evm/06-precompiles/01-what-are-precompiles.mdx b/content/course/customizing-evm/06-precompiles/01-what-are-precompiles.mdx
deleted file mode 100644
index 72f41459..00000000
--- a/content/course/customizing-evm/06-precompiles/01-what-are-precompiles.mdx
+++ /dev/null
@@ -1,71 +0,0 @@
----
-title: What are Precompiles?
-description: Learn about Precompiled Smart Contracts in EVM.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-Precompiled contracts allow the execution of code written in the low-level programming language Go from the EVM, which is significantly faster and more efficient than Solidity.
-
-## Overview
-
-If you're familiar with Python, you might recognize a similar concept where many Python functions and libraries are implemented in C for efficiency. Python developers can import these precompiled modules and call functions as if they were written in Python. The main difference is that the modules execute faster and more efficiently.
-
-Precompiles can be called from a Solidity smart contract just like any other contract. The EVM maintains a list of reserved addresses mapped to precompiles. When a smart contract calls a function of a contract at one of these addresses, the EVM executes the precompile written in Go instead of the Solidity contract.
-
-For example, if we map the address `0x030...01` to the SHA256 precompile that hashes its input using the SHA256 hash function, we can call the precompile as follows:
-
-```solidity
-// SPDX-License-Identifier: MIT
-
-pragma solidity >=0.8.0;
-
-interface ISHA256 {
-    // Computes the SHA256 hash of value
-    function hashWithSHA256(string memory value) external view returns(bytes32 hash);
-}
-
-contract MyContract {  
-    ISHA256 mySHA256Precompile = ISHA256(0x0300000000000000000000000000000000000001);
-    
-    function doSomething() public {
-        bytes32 hash = mySHA256Precompile.hashWithSHA256("test");
-    }
-}
-```
-In the code above, we call the precompile using the defined interface for our SHA256 precompile within `MyContract`.
-
-Note that there is no implementation of the precompile in Solidity itself. This will only work if the precompile is implemented in Go and registered at the address `0x030...01`.
-
-### PrecompiledContract Interface
-
-When implementing a precompile in the Avalanche L1-EVM, the following function of the `StatefulPrecompiledContract` interface must be implemented in Go:
-
-```go
-// StatefulPrecompiledContract is the interface for executing a precompiled contract
-type StatefulPrecompiledContract interface {
-    // Run executes the precompiled contract.
-    Run(accessibleState AccessibleState, 
-        caller common.Address, 
-        addr common.Address, 
-        input []byte, 
-        suppliedGas uint64, 
-        readOnly bool) 
-        (ret []byte, remainingGas uint64, err error)
-}
-```
-
-We will cover the meaning of "stateful" and the first parameter `accessibleState` later. For now, let's focus on the function that specifies the logic of our precompile, which provides access to the following data:
-
-- caller: The address of the account that called the precompile.
-- addr: The address of the precompile being called.
-- input: All inputs encoded in a byte array.
-- suppliedGas: The amount of gas supplied for the precompile call.
-- readOnly: A boolean flag indicating if the interaction is only reading or modifying the state.
-
-The precompile implementation must return the following values:
-
-- ret: All return values encoded in a byte array.
-- remainingGas: The amount of gas remaining after execution.
-- err: If an error occurs, return it. Otherwise, return nil.
\ No newline at end of file
diff --git a/content/course/customizing-evm/06-precompiles/02-why-precompiles.mdx b/content/course/customizing-evm/06-precompiles/02-why-precompiles.mdx
deleted file mode 100644
index 14b30461..00000000
--- a/content/course/customizing-evm/06-precompiles/02-why-precompiles.mdx
+++ /dev/null
@@ -1,45 +0,0 @@
----
-title: Why Precompiles?
-description: Learn about why you should utilize Precompiles in your smart contracts.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-Adding precompiles to the EVM offers several significant advantages, which we will outline in this chapter.
-
-## Performance Optimization
-
-Precompiles primarily optimize the performance of specific computations. Introducing a new precompile can greatly reduce the computational resources required for certain tasks, thereby enhancing the performance of smart contracts and decentralized applications (DApps) that rely on these tasks.
-
-For instance, the SHA256 hash function (0x02) and the RIPEMD160 hash function (0x03) serve as examples of precompiles that significantly boost performance. Implementing these functions within a smart contract would be computationally expensive and slow, whereas as precompiles, they execute quickly and efficiently.
-
-## Security
-
-Incorporating a function as a precompile allows developers to leverage libraries that have been thoroughly reviewed and audited, thus reducing the risk of bugs and vulnerabilities, which enhances overall security.
-
-For example, the ModExp (0x05) precompile safely performs modular exponentiation, a complex mathematical operation utilized in various cryptographic functions.
-
-## Access to Go Libraries
-
-Precompiles are implemented in Go, allowing access to the rich ecosystem of existing Go libraries. This access eliminates the need for reimplementation, which can be labor-intensive and carries the risk of introducing bugs during the translation from Go to Solidity.
-
-Consider the implementation of the SHA256 hash algorithm to understand the complexity involved in reimplementing it in Solidity.
-
-## Gas Efficiency
-
-Introducing a new precompile to the EVM can enhance gas efficiency for specific computations, thereby lowering execution costs. This makes it feasible to incorporate more complex operations into smart contracts, expanding their functionality without significantly increasing transaction costs.
-
-The identity precompile (0x04), which copies and returns input data, exemplifies this. Though simple, it provides gas efficiency by being faster and cheaper than implementing the same functionality in a standard contract.
-
-## Advanced Features and Functionality
-
-By adding new precompiles to the EVM, developers can introduce advanced features and functionalities, such as complex mathematical calculations, advanced cryptographic operations, and new data structures. This can unlock new possibilities for DApps and smart contracts, enabling them to execute tasks that would otherwise be too computationally demanding or technically challenging.
-
-Precompiles for elliptic curve operations, such as ecadd (0x06), ecmul (0x07), and ecpairing (0x08), enable advanced cryptographic functionality within EVM smart contracts. These precompiles are crucial for implementing zk-SNARKs, a form of zero-knowledge proof, in Ethereum.
-
-## Interoperability
-
-Certain precompiles can enhance the interoperability of the EVM with other blockchains or systems. For instance, precompiles can be utilized to verify proofs from other chains or perform operations compatible with different cryptographic standards.
-
-The BLS12-381 elliptic curve operations precompiles (0x0a through 0x13, added in the Istanbul upgrade) improve EVM interoperability by allowing operations that are compatible with the BLS signature scheme, potentially facilitating inter-blockchain communication.
diff --git a/content/course/customizing-evm/06-precompiles/03-interact-wtih-precompile.mdx b/content/course/customizing-evm/06-precompiles/03-interact-wtih-precompile.mdx
deleted file mode 100644
index 27180471..00000000
--- a/content/course/customizing-evm/06-precompiles/03-interact-wtih-precompile.mdx
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Interact with a Precompile
-description: Learn about why you should utilize Precompiles in your smart contracts.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-So let's get to it and interact with a precompile on the C-Chain of your local network. The SHA256 precompile is already available on the C-Chain.
-
-## Call Precompile from Foundry
-
-In this example, we will call the SHA256 precompile to generate hash of the input string.
-
-**Precompile Address:** `0x0000000000000000000000000000000000000002`
-
-```bash 
-cast call --rpc-url local-c --private-key $PK 0x0000000000000000000000000000000000000002 "run(string)(bytes32)" "test"
-```
-
-You should see a bytes32 hash of the input string `test` as the output. 
-
-```bash
-0xa770b926e13a31fb823282e9473fd1da9e85afe23690336770c490986ef1b1fc
-```
\ No newline at end of file
diff --git a/content/course/customizing-evm/07-hash-function-precompile/00-intro.mdx b/content/course/customizing-evm/07-hash-function-precompile/00-intro.mdx
deleted file mode 100644
index cc243b12..00000000
--- a/content/course/customizing-evm/07-hash-function-precompile/00-intro.mdx
+++ /dev/null
@@ -1,60 +0,0 @@
----
-title: Overview
-description: Learn how to create a Hash Function Precompile.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Book
----
-import {Step, Steps} from 'fumadocs-ui/components/steps';
-
-## What We're Building
-
-In this section, we'll create a precompile for the MD5 hash function. By utilizing the existing Go library for this hash function, we can avoid reimplementing the algorithm in Solidity and take advantage of Go's superior efficiency.
-
-<Accordions>
-<Accordion title="What is a Hash Function?">
-
-A hash function is a special type of function that takes input data of any size (such as a letter, a word, the text of a book, or even all combined texts available on the internet) and converts it into a fixed-size output. This output, known as a hash value, represents the original data. The process is often referred to as "hashing."
-
-Hash functions possess several key properties:
-
-- **Deterministic**: Given the same input, a hash function will always produce the same output. For instance, hashing the word "apple" a thousand times will yield the same hash value each time.
-- **Fixed Size**: Regardless of the input data size—whether it's a single character or an entire novel—the hash function always produces an output (the hash value) of a consistent length.
-- **Fast Computation**: Hash functions are designed to be quick and efficient, returning a hash value with minimal computational resources and time.
-- **Preimage Resistance**: It's computationally infeasible to retrieve the original input data from the hash value alone. This property is especially crucial in cryptographic hash functions for data security.
-- **Avalanche Effect**: A small change to the input should cause significant changes in the output, making the new hash value appear uncorrelated with the old one. For example, hashing "apple" and "Apple" should produce completely different hash values.
-- **Collision Resistance**: It is highly unlikely for two different pieces of input data to yield the same hash value. However, due to the limited length of hash values, collisions are theoretically possible. A good hash function minimizes the occurrence of such collisions.
-
-Hash functions are utilized in various applications across computer science, including data retrieval, data integrity verification, password storage, and in blockchain technology for cryptocurrencies like Bitcoin.
-
-</Accordion>
-</Accordions>
-
-## Reference Implementation
-
-To aid your understanding of building precompiles, we will compare each step with a reference example: a precompile for the SHA256 hash function. Both precompiles are quite similar, featuring a single function that returns the hashed value.
-
-## Overview of Steps
-
-Here's an overview of the steps involved:
-<Steps>
-<Step>
-Create a Solidity interface for the precompile.
-</Step>
-<Step>
-Generate the ABI.
-</Step>
-<Step>
-Write the precompile code in Go.
-</Step>
-<Step>
-Configure and register the precompile.
-</Step>
-<Step>
-Build and run your customized EVM.
-</Step>
-<Step>
-Connect Remix to your customized EVM and interact with the precompile.
-</Step>
-</Steps>
-Let's get started!
diff --git a/content/course/customizing-evm/07-hash-function-precompile/01-create-solidity-interface.mdx b/content/course/customizing-evm/07-hash-function-precompile/01-create-solidity-interface.mdx
deleted file mode 100644
index 6b4fc971..00000000
--- a/content/course/customizing-evm/07-hash-function-precompile/01-create-solidity-interface.mdx
+++ /dev/null
@@ -1,100 +0,0 @@
----
-title: Create an MD5 Solidity Interface
-description: Learn how to create an MD5 Solidity Interface
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-The first step is defining the interface that will wrap the precompile implementation and that other contracts and users will interact with. In addition to declaring the way users can interact with our MD5 precompile, defining the MD5 interface will also allow us to utilize a generator script. A precompile consists of many files, and generating boilerplate Go files will make implementing the precompile much easier.
-
-## SHA-256 Precompile Interface
-
-Before defining the MD5 interface, we will first look at the interface of the very similar SHA-256 precompile. This reference implementation is included in the repository we have created earlier.
-
-```solidity title="contracts/contracts/interfaces/ISHA256.sol"
-// SPDX-License-Identifier: MIT
-
-pragma solidity >=0.8.0;
-
-interface ISHA256 {
-    /// Compute the hash of value
-    /// @param value the value to be hashed
-    /// @return hash the hash of the value
-    function hashWithSHA256(string memory value) external view returns(bytes32 hash);
-    }
-```
-
-ISHA256 contains a single function `hashWithSHA256`. `hashWithSHA256` takes in a value of type string, which is the value which is to be hashed, and outputs a 32-byte hash.
-
-## Creating the Solidity Interface For The MD5 Precompile
-
-Now it's your turn to define a precompile interface!
-
-Create the interface for the MD5 hash function. Start by going into the same directory where `ISHA256.sol` lives (`contracts/contracts/interfaces/`) and create a new file named `IMD5.sol`. Note that:
-
-&rarr; MD5 returns a 16-byte hash instead of a 32-byte hash
-
-&rarr; Make sure to name all parameters and return values
-
-<Accordions>
-<Accordion title="Solution">
-
-```solidity title="contracts/contracts/interfaces/IMD5.sol"
-// SPDX-License-Identifier: MIT
-
-pragma solidity >=0.8.0;
-
-interface IMD5 {
-    function hashWithMD5(string memory value) external view returns (bytes16 hash);
-}
-```
-
-</Accordion>
-</Accordions>
-
-## Generate the ABI
-
-Now that we have an interface of our precompile, let's create an ABI of our Solidity interface. Open the integrated VS Code terminal (control + \`), and change to the `/contracts` directory.
-
-```bash
-cd contracts
-```
-
-Run the command to compile the solidity interface to the ABI:
-
-```bash
-npx solc@latest --abi ./contracts/interfaces/IMD5.sol -o ./abis --base-path . --include-path ./node_modules
-```
-
-Rename the file:
-
-```bash
-mv ./abis/contracts_interfaces_IMD5_sol_IMD5.abi ./abis/IMD5.abi
-```
-
-Now, you should have a file called `IMD5.abi` in the folder `/contracts/abis` with the following content:
-
-```json
-[
-    {
-        "inputs": [
-            {
-                "internalType": "string",
-                "name": "value",
-                "type": "string"
-            }
-        ],
-        "name": "hashWithMD5",
-        "outputs": [
-            {
-                "internalType": "bytes16",
-                "name": "hash",
-                "type": "bytes16"
-            }
-        ],
-        "stateMutability": "view",
-        "type": "function"
-    }
-]
-```
diff --git a/content/course/customizing-evm/07-hash-function-precompile/02-generate-the-precompile.mdx b/content/course/customizing-evm/07-hash-function-precompile/02-generate-the-precompile.mdx
deleted file mode 100644
index 673e5388..00000000
--- a/content/course/customizing-evm/07-hash-function-precompile/02-generate-the-precompile.mdx
+++ /dev/null
@@ -1,202 +0,0 @@
----
-title: Generate the Precompile
-description: Learn how to generate your precompile.
-updated: 2024-09-27
-authors: [ashucoder9, owenwahlgren]
-icon: Terminal
-comments: true
----
-
-import { File, Files, Folder } from 'fumadocs-ui/components/files';
-
-In the last section, we created the ABI for our precompile contract. Now, we'll use the precompile generation script provided by the precompile-evm template to generate a boilerplate code in go for the precompile implementation that will be wrapped in the solidity interface we created in the previous step.
-
-## Running the Generation Script
-
-To start, go to the root directory of your precompile-evm project: 
-
-```bash
-cd ..
-```
-
-Now generate the files necessary for the precompile.
-
-```bash
-./scripts/generate_precompile.sh --abi ./contracts/abis/IMD5.abi --type Md5 --pkg md5 --out ./md5
-```
-
-Now you should have a new directory in your root directory called `md5`:
-
-<Files>
-  <File name="LICENSE" />
-  <File name="README.md" />
-  <Folder name="contracts">
-    <File name="..." />
-  </Folder>
-  <File name="go.mod" />
-  <File name="go.sum" />
-  <Folder name="sha256">
-    <File name="..." />
-  </Folder>
-  <Folder name="md5" defaultOpen>
-    <File name="README.md" />
-    <File name="config.go" />
-    <File name="config_test.go" />
-    <File name="contract.abi" />
-    <File name="contract.go" />
-    <File name="contract_test.go" />
-    <File name="module.go" />
-  </Folder>
-  <Folder name="plugin">
-    <File name="main.go" />
-  </Folder>
-  <Folder name="scripts">
-    <File name="build.sh" />
-    <File name="..." />
-  </Folder>
-  <Folder name="tests">
-    <File name="..." />
-  </Folder>
-</Files>
-
-### `contract.go`
-
-For the rest of this chapter, we'll work with the `md5/contract.go` file. If you generated the Go files related to your precompile, `contract.go` should look like the code below.
-
-Do not be intimidated if much of this code does not make sense to you. We'll cover the different parts and add some code to implement the logic of our MD5 precompile.
-
-```go
-// Code generated
-// This file is a generated precompile contract config with stubbed abstract functions.
-// The file is generated by a template. Please inspect every code and comment in this file before use.
-
-package md5
-
-import (
-	"errors"
-	"fmt"
-	"math/big"
-
-	"github.com/ava-labs/subnet-evm/accounts/abi"
-	"github.com/ava-labs/subnet-evm/precompile/contract"
-	"github.com/ava-labs/subnet-evm/vmerrs"
-
-	_ "embed"
-
-	"github.com/ethereum/go-ethereum/common"
-)
-
-const (
-	// Gas costs for each function. These are set to 1 by default.
-	// You should set a gas cost for each function in your contract.
-	// Generally, you should not set gas costs very low as this may cause your network to be vulnerable to DoS attacks.
-	// There are some predefined gas costs in contract/utils.go that you can use.
-	HashWithMD5GasCost uint64 = 1 /* SET A GAS COST HERE */
-)
-
-// CUSTOM CODE STARTS HERE
-// Reference imports to suppress errors from unused imports. This code and any unnecessary imports can be removed.
-var (
-	_ = abi.JSON
-	_ = errors.New
-	_ = big.NewInt
-	_ = vmerrs.ErrOutOfGas
-	_ = common.Big0
-)
-
-// Singleton StatefulPrecompiledContract and signatures.
-var (
-
-	// Md5RawABI contains the raw ABI of Md5 contract.
-	//go:embed contract.abi
-	Md5RawABI string
-
-	Md5ABI = contract.ParseABI(Md5RawABI)
-
-	Md5Precompile = createMd5Precompile()
-)
-
-// UnpackHashWithMD5Input attempts to unpack [input] into the string type argument
-// assumes that [input] does not include selector (omits first 4 func signature bytes)
-func UnpackHashWithMD5Input(input []byte) (string, error) {
-	res, err := Md5ABI.UnpackInput("hashWithMD5", input)
-	if err != nil {
-		return "", err
-	}
-	unpacked := *abi.ConvertType(res[0], new(string)).(*string)
-	return unpacked, nil
-}
-
-// PackHashWithMD5 packs [value] of type string into the appropriate arguments for hashWithMD5.
-// the packed bytes include selector (first 4 func signature bytes).
-// This function is mostly used for tests.
-func PackHashWithMD5(value string) ([]byte, error) {
-	return Md5ABI.Pack("hashWithMD5", value)
-}
-
-// PackHashWithMD5Output attempts to pack given hash of type [16]byte
-// to conform the ABI outputs.
-func PackHashWithMD5Output(hash [16]byte) ([]byte, error) {
-	return Md5ABI.PackOutput("hashWithMD5", hash)
-}
-
-// UnpackHashWithMD5Output attempts to unpack given [output] into the [16]byte type output
-// assumes that [output] does not include selector (omits first 4 func signature bytes)
-func UnpackHashWithMD5Output(output []byte) ([16]byte, error) {
-	res, err := Md5ABI.Unpack("hashWithMD5", output)
-	if err != nil {
-		return [16]byte{}, err
-	}
-	unpacked := *abi.ConvertType(res[0], new([16]byte)).(*[16]byte)
-	return unpacked, nil
-}
-
-func hashWithMD5(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-	if remainingGas, err = contract.DeductGas(suppliedGas, HashWithMD5GasCost); err != nil {
-		return nil, 0, err
-	}
-	// attempts to unpack [input] into the arguments to the HashWithMD5Input.
-	// Assumes that [input] does not include selector
-	// You can use unpacked [inputStruct] variable in your code
-	inputStruct, err := UnpackHashWithMD5Input(input)
-	if err != nil {
-		return nil, remainingGas, err
-	}
-
-	// CUSTOM CODE STARTS HERE
-	_ = inputStruct // CUSTOM CODE OPERATES ON INPUT
-
-	var output [16]byte // CUSTOM CODE FOR AN OUTPUT
-	packedOutput, err := PackHashWithMD5Output(output)
-	if err != nil {
-		return nil, remainingGas, err
-	}
-
-	// Return the packed output and the remaining gas
-	return packedOutput, remainingGas, nil
-}
-
-// createMd5Precompile returns a StatefulPrecompiledContract with getters and setters for the precompile.
-
-func createMd5Precompile() contract.StatefulPrecompiledContract {
-	var functions []*contract.StatefulPrecompileFunction
-
-	abiFunctionMap := map[string]contract.RunStatefulPrecompileFunc{
-		"hashWithMD5": hashWithMD5,
-	}
-
-	for name, function := range abiFunctionMap {
-		method, ok := Md5ABI.Methods[name]
-		if !ok {
-			panic(fmt.Errorf("given method (%s) does not exist in the ABI", name))
-		}
-		functions = append(functions, contract.NewStatefulPrecompileFunction(method.ID, function))
-	}
-	// Construct the contract with no fallback function.
-	statefulContract, err := contract.NewStatefulPrecompileContract(nil, functions)
-	if err != nil {
-		panic(err)
-	}
-	return statefulContract
-}
-```
diff --git a/content/course/customizing-evm/07-hash-function-precompile/03-unpack-input-pack-output.mdx b/content/course/customizing-evm/07-hash-function-precompile/03-unpack-input-pack-output.mdx
deleted file mode 100644
index 8d6f1374..00000000
--- a/content/course/customizing-evm/07-hash-function-precompile/03-unpack-input-pack-output.mdx
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: Packing and Unpacking
-description: Learn how to unpack inputs and pack outputs.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-In this first segment of examining the `contract.go` file generated for us, we will go over the packing and unpacking functions in this file.   
-
-## The Notion of Packing
-
-Those eager to implement the MD5 algorithm might be wondering why we're discussing packing. However, there is good reason to discuss packing, and it comes down to the specification of the `staticcall` function in Solidity.
-
-We begin by referring to the example of calling the SHA-256 precompiled contract:
-
-```go
-(bool ok, bytes memory out) = address(2).staticcall(abi.encode(numberToHash));
-```
-
-As seen above, the `staticcall` function accepts input in bytes format, generated by `abi.encode`, and returns a boolean value indicating success, along with a bytes format output.
-
-Therefore, our precompiled contract should be designed to accept and return data in bytes format, involving the packing and unpacking of values. Since packing is a deterministic process, there's no concern about data corruption during translation. However, some preprocessing or postprocessing is necessary to ensure the contract functions correctly.
-
-## Unpacking Inputs
-
-In `contract.go`, the function `UnpackHashWithMd5Input` unpacks our data and converts it into a type relevant to us. It takes a byte array as an input and returns a Go string. We will look at more complex precompiles that have multiple functions that may take multiple inputs later.
-
-```go
-// UnpackHashWithMD5Input attempts to unpack [input] into the string type argument
-// assumes that [input] does not include selector (omits first 4 func signature bytes)
-func UnpackHashWithMD5Input(input []byte) (string, error) {
-    res, err := Md5ABI.UnpackInput("hashWithMD5", input)
-    if err != nil {
-        return "", err
-    }
-    unpacked := *abi.ConvertType(res[0], new(string)).(*string)
-    return unpacked, nil
-}
-```
-
-## Packing Outputs
-
-Ignoring `hashWithMD5` for now, note that whatever value `hashWithMD5` outputs, we will need to postprocess it (i.e. pack it). `PackHashWithMD5Output` does just this, taking in an input of type [16]byte and outputting a byte array which can be returned by `staticcall`.
-
-```go
-// PackHashWithMd5Output attempts to pack given hash of type [16]byte
-// to conform the ABI outputs.
-func PackHashWithMd5Output(hash [16]byte) ([]byte, error) {
-    return Md5ABI.PackOutput("hash_with_md5", hash)
-}
-```
-
-This may seem trivial, but if our Solidity interface defined our function to return a uint or string, the type of our input to this function would differ accordingly.
diff --git a/content/course/customizing-evm/07-hash-function-precompile/04-implementing-precompile.mdx b/content/course/customizing-evm/07-hash-function-precompile/04-implementing-precompile.mdx
deleted file mode 100644
index 54a186e8..00000000
--- a/content/course/customizing-evm/07-hash-function-precompile/04-implementing-precompile.mdx
+++ /dev/null
@@ -1,112 +0,0 @@
----
-title: Implement the Precompile
-description: Learn how to implement the Precompile.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-Now, we'll implement the logic of the precompile in Go. We'll hash our string using the MD5 algorithm.
-
-## SHA-256 Precompile Implementation
-
-Before defining the logic of our MD5 precompile, let's look at the logic of the function `hashWithSHA256` (located in `sha256/contract.go`), which computes the SHA-256 hash of a string:
-
-```go title="sha256/contract.go"
-import (
-    "crypto/sha256"
-    //...
-)
-
-// ...
-
-func hashWithSHA256(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-    if remainingGas, err = contract.DeductGas(suppliedGas, HashWithSHA256GasCost); err != nil {
-        return nil, 0, err
-    }
-    // attempts to unpack [input] into the arguments to the HashWithSHA256Input.
-    // Assumes that [input] does not include selector
-    // You can use unpacked [inputStruct] variable in your code
-    inputStruct, err := UnpackHashWithSHA256Input(input)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // CUSTOM CODE STARTS HERE
-    _ = inputStruct // CUSTOM CODE OPERATES ON INPUT
-
-    var output [32]byte // CUSTOM CODE FOR AN OUTPUT
-
-    output = sha256.Sum256([]byte(inputStruct))
-    
-    packedOutput, err := PackHashWithSHA256Output(output)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // Return the packed output and the remaining gas
-    return packedOutput, remainingGas, nil
-}
-```
-
-As you can see, we're performing the following steps:
-
-- Line 1: Importing the sha256 function from the crypto library (at the top of the Go file)
-- Line 15: Unpacking the input to the variable inputStruct. It doesn't make sense that the variable has Struct in its name, but you will see why it is done like this when we have multiple inputs in a later example
-- Line 24: Calling the sha256 function and assign its result to the output variable
-- Line 26: Packing the output into a byte array
-- Line 32: Returning the packed output, the remaining gas and nil, since no error has occurred
-
-## Implementing the MD5 Precompile in `contract.go`
-
-Go ahead and implement the `md5/contract.go` for the MD5 precompile. You should only have to write a few lines of code. If you're unsure which function to use, the following documentation might help: [Go Documentation Crypto/md5](https://pkg.go.dev/crypto/md5#Sum)
-
-<Accordions>
-<Accordion title="Solution">
-
-```go title="md5/contract.go"
-import (
-	"crypto/md5"
-	// ...
-)
-
-// ...
-
-func hashWithMD5(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {func hashWithMD5(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-	if remainingGas, err = contract.DeductGas(suppliedGas, HashWithMD5GasCost); err != nil {
-		return nil, 0, err
-	}
-	// attempts to unpack [input] into the arguments to the HashWithMD5Input.
-	// Assumes that [input] does not include selector
-	// You can use unpacked [inputStruct] variable in your code
-	inputStruct, err := UnpackHashWithMD5Input(input)
-	if err != nil {
-		return nil, remainingGas, err
-	}
-
-	// CUSTOM CODE STARTS HERE
-	_ = inputStruct // CUSTOM CODE OPERATES ON INPUT
-
-	var output [16]byte // CUSTOM CODE FOR AN OUTPUT
-	output = md5.Sum([]byte(inputStruct))
-
-	packedOutput, err := PackHashWithMD5Output(output)
-	if err != nil {
-		return nil, remainingGas, err
-	}
-
-	// Return the packed output and the remaining gas
-	return packedOutput, remainingGas, nil
-}
-```
-
-To solve this task, we did the following things:
-
-- Import the md5 function from the crypto library
-- Unpack the input to a variable inputStruct (It does not make sense that the variable has Struct in its name, but you will see why it is done like this when we have multiple inputs in a later example)
-- Call the md5 function and assign it's result to the output variable
-- Pack the output into a byte array
-- Return the packed output, the remaining gas and nil, since no error has occurred
-
-</Accordion>
-</Accordions>
\ No newline at end of file
diff --git a/content/course/customizing-evm/07-hash-function-precompile/05-configkey-and-contractaddr.mdx b/content/course/customizing-evm/07-hash-function-precompile/05-configkey-and-contractaddr.mdx
deleted file mode 100644
index 539288e4..00000000
--- a/content/course/customizing-evm/07-hash-function-precompile/05-configkey-and-contractaddr.mdx
+++ /dev/null
@@ -1,97 +0,0 @@
----
-title: ConfigKey, ContractAddress, and Genesis
-description: Learn how to set ConfigKey, ContractAddress, and update the genesis configuration.
-updated: 2024-09-27
-authors: [ashucoder9, owenwahlgren]
-icon: Terminal
----
-
-## Config Key
-
-The precompile config key is used to configure the precompile in the `chainConfig`. It's set in the `module.go` file of our precompile.
-
-The generator chooses an initial value that should be sufficient for many cases. In our case:
-
-```go title="md5/module.go"
-// ConfigKey is the key used in json config files to specify this precompile precompileconfig.
-// must be unique across all precompiles.
-const ConfigKey = "md5Config"
-```
-This key is used for each precompile in the geneis configuration to set the activation timestamp of the precompile.
-
-## Contract Address
-
-Each precompile has a unique contract address we can use to call it. This is the address we used earlier to instantiate the precompile in our solidity code or in remix when we interacted with the sha256 precompile.
-
-```go title="md5/module.go"
-// ContractAddress is the defined address of the precompile contract.
-// This should be unique across all precompile contracts.
-// See precompile/registry/registry.go for registered precompile contracts and more information.
-
-var ContractAddress = common.HexToAddress("{ASUITABLEHEXADDRESS}") // SET A SUITABLE HEX ADDRESS HERE
-```
-
-The `0x01` range is reserved for precompiles added by Ethereum.
-
-The `0x02` range is reserved for precompiles provided by Avalanche.
-
-The `0x03` range is reserved for custom precompiles.
-
-Lets set our contract address to `0x0300000000000000000000000000000000000002`
-
-```go title="md5/module.go"
-var ContractAddress = common.HexToAddress("0x0300000000000000000000000000000000000002") // SET A SUITABLE HEX ADDRESS HERE
-```
-
-## Update Genesis Configuration
-Now that the `ConfigKey` and `ContractAddress` are set, we need to update the genesis configuration to register the precompile.
-
-```json title=".devcontainer/genesis-example.json"
-{
-  "config": {
-    "chainId": 99999,
-    "homesteadBlock": 0,
-    "eip150Block": 0,
-    "eip150Hash": "0x2086799aeebeae135c246c65021c82b4e15a2c451340993aacfd2751886514f0",
-    "eip155Block": 0,
-    "eip158Block": 0,
-    "byzantiumBlock": 0,
-    "constantinopleBlock": 0,
-    "petersburgBlock": 0,
-    "istanbulBlock": 0,
-    "muirGlacierBlock": 0,
-    "subnetEVMTimestamp": 0,
-    "feeConfig": {
-      "gasLimit": 20000000,
-      "minBaseFee": 1000000000,
-      "targetGas": 100000000,
-      "baseFeeChangeDenominator": 48,
-      "minBlockGasCost": 0,
-      "maxBlockGasCost": 10000000,
-      "targetBlockRate": 2,
-      "blockGasCostStep": 500000
-    },
-    "sha256Config": {
-      "blockTimestamp": 0
-    },
-    "md5Config": { // [!code highlight:3]
-      "blockTimestamp": 0
-    } 
-  },
-  "alloc": {
-    "8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC": {
-      "balance": "0x52B7D2DCC80CD2E4000000"
-    }
-  },
-  "nonce": "0x0",
-  "timestamp": "0x0",
-  "extraData": "0x00",
-  "gasLimit": "0x1312D00",
-  "difficulty": "0x0",
-  "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
-  "coinbase": "0x0000000000000000000000000000000000000000",
-  "number": "0x0",
-  "gasUsed": "0x0",
-  "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000"
-}
-```
\ No newline at end of file
diff --git a/content/course/customizing-evm/07-hash-function-precompile/06-register-precompile.mdx b/content/course/customizing-evm/07-hash-function-precompile/06-register-precompile.mdx
deleted file mode 100644
index 57893b0f..00000000
--- a/content/course/customizing-evm/07-hash-function-precompile/06-register-precompile.mdx
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: Register Your Precompile
-description: Learn how to register your precompile.
-updated: 2024-09-27
-authors: [owenwahlgren]
-icon: Terminal
----
-
-The next step in developing our precompile is to **register it with precompile-evm**. Take a look at `plugin/main.go`. You should see the following file:
-
-```go title="plugin/main.go"
-// (c) 2019-2023, Ava Labs, Inc. All rights reserved.
-// See the file LICENSE for licensing terms.
-
-package main
-
-import (
-    "fmt"
-
-    "github.com/ava-labs/avalanchego/version"
-    "github.com/ava-labs/subnet-evm/plugin/evm"
-    "github.com/ava-labs/subnet-evm/plugin/runner"
-
-    // Each precompile generated by the precompilegen tool has a self-registering init function
-    // that registers the precompile with the subnet-evm. Importing the precompile package here
-    // will cause the precompile to be registered with the subnet-evm.
-    // ADD YOUR PRECOMPILE HERE
-    //_ "github.com/ava-labs/precompile-evm/{yourprecompilepkg}"
-)
-
-const Version = "v0.1.4"
-
-func main() {
-    versionString := fmt.Sprintf("Precompile-EVM/%s Avalanche L1-EVM/%s [AvalancheGo=%s, rpcchainvm=%d]", Version, evm.Version, version.Current, version.RPCChainVMProtocol)
-    runner.Run(versionString)
-}
-```
-
-As of now, we do not have any precompile registered. To reigster a precompile, simply import the precompile package in the `plugin/main.go` file.
-
-```go title="plugin/main.go"
-// (c) 2019-2023, Ava Labs, Inc. All rights reserved.
-// See the file LICENSE for licensing terms.
-
-package main
-
-import (
-    "fmt"
-
-    "github.com/ava-labs/avalanchego/version"
-    "github.com/ava-labs/subnet-evm/plugin/evm"
-    "github.com/ava-labs/subnet-evm/plugin/runner"
-
-    // Each precompile generated by the precompilegen tool has a self-registering init function
-    // that registers the precompile with the subnet-evm. Importing the precompile package here
-    // will cause the precompile to be registered with the subnet-evm.
-    _ "github.com/ava-labs/precompile-evm/sha256"// [!code highlight:2]
-    _ "github.com/ava-labs/precompile-evm/md5" 
-)
-
-const Version = "v0.1.4"
-
-func main() {
-    versionString := fmt.Sprintf("Precompile-EVM/%s Avalanche L1-EVM/%s [AvalancheGo=%s, rpcchainvm=%d]", Version, evm.Version, version.Current, version.RPCChainVMProtocol)
-    runner.Run(versionString)
-}
-```
diff --git a/content/course/customizing-evm/07-hash-function-precompile/07-build-and-run.mdx b/content/course/customizing-evm/07-hash-function-precompile/07-build-and-run.mdx
deleted file mode 100644
index 477db5b7..00000000
--- a/content/course/customizing-evm/07-hash-function-precompile/07-build-and-run.mdx
+++ /dev/null
@@ -1,45 +0,0 @@
----
-title: Build and Run
-description: Learn how to build and run your custom VM on a local network.
-updated: 2024-09-27
-authors: [ashucoder9, owenwahlgren]
-icon: Terminal
----
-
-## Build Your Custom VM
-
-There's a simple build script in the Precompile-EVM we can utilize to build. First, make sure you are in the root folder of you Precompile-EVM:
-
-```bash
-cd $GOPATH/src/github.com/ava-labs/precompile-evm
-```
-
-Then run the command to initiate the build script:
-
-```bash
-./scripts/build.sh
-```
-
-If you do not see any error, the build was successful.
-
-## Run a Local Network with Your Custom VM
-
-You can run you customized Precompile-EVM by using the Avalanche CLI.
-
-First, create the configuration for your blockchain with custom VM.
-
-```bash
-avalanche blockchain create myblockchain --custom --vm $AVALANCHEGO_PLUGIN_PATH/srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy --genesis ./.devcontainer/genesis-example.json
-```
-
-<Callout type="info">
-Make sure you replace the binary name with the actual binary name of your Precompile-EVM, and genesis file with the actual path to your genesis file.
-</Callout>
-
-Next, launch the Avalanche L1 with your custom VM:
-
-```bash
-avalanche blockchain deploy myblockchain
-```
-
-After around 1 minute the blockchain should have been created and some more output should appear in the terminal. You'll also see the RPC URL of your blockchain in the terminal.
\ No newline at end of file
diff --git a/content/course/customizing-evm/07-hash-function-precompile/08-interact-with-md5.mdx b/content/course/customizing-evm/07-hash-function-precompile/08-interact-with-md5.mdx
deleted file mode 100644
index 68141cd2..00000000
--- a/content/course/customizing-evm/07-hash-function-precompile/08-interact-with-md5.mdx
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: Interact with Precompile
-description: Interact with the MD5 precompile we just deployed.
-updated: 2024-08-27
-authors: [owenwahlgren]
-icon: Terminal
----
-
-## Call Precompile from Foundry
-
-Now we will call our MD5 precompile to generate a bytes16 hash of the input string.
-
-**MD5 Precompile Address:** `0x0300000000000000000000000000000000000002`
-
-```bash 
-cast call --rpc-url myblockchain --private-key $PK 0x0300000000000000000000000000000000000002 "hashWithMD5(string)(bytes16)" "test"
-```
-
-You should see the bytes16 hash of the input string `test` as the output. 
-
-```bash
-0x098f6bcd4621d373cade4e832627b4f6
-```
\ No newline at end of file
diff --git a/content/course/customizing-evm/08-calculator-precompile/00-intro.mdx b/content/course/customizing-evm/08-calculator-precompile/00-intro.mdx
deleted file mode 100644
index 043ff935..00000000
--- a/content/course/customizing-evm/08-calculator-precompile/00-intro.mdx
+++ /dev/null
@@ -1,57 +0,0 @@
----
-title: Overview
-description: Learn how to create a Calculator precompile.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Book
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-## Reference Implementation
-
-In this section, we will showcase how to build a more complex precompile that offers selected simple math operations. Our calculator will support the following operations:
-
-1. Add two numbers and return the result (3 + 5 = 8)
-2. Get the next two greater numbers (7 => 8, 9)
-3. Repeat a string x times (4, b => bbbb)
-
-This is somewhat odd calculator and real-life usability might not be the best, but as you will see in a bit the operations have been chosen to demonstrate some different scenarios we might face while building precompiles.
-
-## What You Are Building
-
-Similar to the Calculator precompile, you will be building a precompile called **CalculatorPlus** which contains the following mathematical functions:
-
-- **Powers of Three**: takes in as input an integer base; returns the square, cube, and 4th power of the input
-- **Modulo+**: takes in as input two arguments: the dividend and the divisor. Returns how many times the dividend fits in the divisor, and the remainder.
-- **Simplify Fraction**: takes in two arguments: the numerator and the denominator. Returns the simplfied version of the fraction (if the denominator is 0, we return 0)
-
-## Overview of Steps
-
-Compared to the process before, we will now also add tests for our precompile. Here's a quick overview of the steps we're going to follow:
- 
-<Steps>
-<Step>
-Create a Solidity interface for the precompile
-</Step>
-<Step>
-Generate the ABI
-</Step>
-<Step>
-Write the precompile code in Go
-</Step>
-<Step>
-Configure and register the precompile
-</Step>
-<Step>
-Add and run tests
-</Step>
-<Step>
-Build and run your customized EVM
-</Step>
-<Step>
-Connect Remix to your customized EVM and interact with the precompile
-</Step>
-</Steps>
-
-This tutorial will help you understand how to create more complex precompiles. Let's begin!
diff --git a/content/course/customizing-evm/08-calculator-precompile/01-create-solidity-interface.mdx b/content/course/customizing-evm/08-calculator-precompile/01-create-solidity-interface.mdx
deleted file mode 100644
index 50723f91..00000000
--- a/content/course/customizing-evm/08-calculator-precompile/01-create-solidity-interface.mdx
+++ /dev/null
@@ -1,158 +0,0 @@
----
-title: Create Solidity Interface
-description: Learn how to create the Solidity interface for your calculator precompile.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-Just like in the MD5 section, we will start off by first demonstrating the Solidity interface for the Calculator precompile before guiding you on how to build the **CalculatorPlus** precompile. To start, let's take a look at the Calculator Solidity interface:
-
-```solidity title="solidity/interfaces/ICalculator.sol"
-// SPDX-License-Identifier: MIT
-
-pragma solidity >=0.8.0;
-
-interface ICalculator {
-    function add(uint value1, uint value2) external view returns(uint result);
-
-    function nextTwo(uint value1) external view returns(uint result1, uint result2);
-
-    function repeat(uint times, string memory text) external view returns(string memory result);
-}
-```
-
-With this in mind, let's define the CalculatorPlus Solidity interface. Your interface should have the following three functions:
-
-1. `powOfThree`: takes in an unsigned integer base, and returns three unsigned integers named secondPow, thirdPow, fourthPow . 
-2. `moduloPlus`: takes in unsigned integers dividend and divisor as input, and returns two unsigned integers named multiple and remainder .
-3. `simplFrac`: takes in unsigned integers named numerator and denominator, and returns two unsigned integers named simplNum and simplDenom
-
-<Accordions>
-<Accordion title="Solution">
-
-```solidity title="solidity/interfaces/ICalculatorPlus.sol"
-// SPDX-License-Identifier: MIT
-
-pragma solidity >=0.8.0;
-
-interface ICalculatorPlus {
-    function powOfThree(uint256 base) external view returns(uint256 secondPow, uint256 thirdPow, uint256 fourthPow);
-
-    function moduloPlus(uint256 dividend, uint256 divisor) external view returns(uint256 multiple, uint256 remainder);
-
-    function simplFrac(uint256 numerator, uint256 denominator) external view returns(uint256 simplNum, uint256 simplDenom);
-}
-```
-
-</Accordion>
-</Accordions>
-
-## Generate the ABI
-
-Now that we have an interface of our precompile, let's create an ABI of our Solidity interface. Open the terminal (control + \`), change to the `/contracts` directory and run the following command to compile the solidity interface to the ABI:
-
-```bash
-# Go to the upper contracts directory of your project
-cd contracts
-
-# Compile ICalculatorPlus.sol to ABI
-npx solc@latest --abi ./contracts/interfaces/ICalculatorPlus.sol -o ./abis --base-path . --include-path ./node_modules
-
-# Rename using this script or manually
-mv ./abis/contracts_interfaces_ICalculatorPlus_sol_ICalculatorPlus.abi ./abis/ICalculatorPlus.abi
-```
-
-Now you should have a file called `ICalculatorPlus.abi` in the folder `/contracts/abis` with the following content:
-
-```json title="/contracts/abis/ICalculatorPlus.abi"
-[
-  {
-    "inputs": [
-      {
-        "internalType": "uint256",
-        "name": "dividend",
-        "type": "uint256"
-      },
-      {
-        "internalType": "uint256",
-        "name": "divisor",
-        "type": "uint256"
-      }
-    ],
-    "name": "moduloPlus",
-    "outputs": [
-      {
-        "internalType": "uint256",
-        "name": "multiple",
-        "type": "uint256"
-      },
-      {
-        "internalType": "uint256",
-        "name": "remainder",
-        "type": "uint256"
-      }
-    ],
-    "stateMutability": "view",
-    "type": "function"
-  },
-  {
-    "inputs": [
-      {
-        "internalType": "uint256",
-        "name": "base",
-        "type": "uint256"
-      }
-    ],
-    "name": "powOfThree",
-    "outputs": [
-      {
-        "internalType": "uint256",
-        "name": "secondPow",
-        "type": "uint256"
-      },
-      {
-        "internalType": "uint256",
-        "name": "thirdPow",
-        "type": "uint256"
-      },
-      {
-        "internalType": "uint256",
-        "name": "fourthPow",
-        "type": "uint256"
-      }
-    ],
-    "stateMutability": "view",
-    "type": "function"
-  },
-  {
-    "inputs": [
-      {
-        "internalType": "uint256",
-        "name": "numerator",
-        "type": "uint256"
-      },
-      {
-        "internalType": "uint256",
-        "name": "denominator",
-        "type": "uint256"
-      }
-    ],
-    "name": "simplFrac",
-    "outputs": [
-      {
-        "internalType": "uint256",
-        "name": "simplNum",
-        "type": "uint256"
-      },
-      {
-        "internalType": "uint256",
-        "name": "simplDenom",
-        "type": "uint256"
-      }
-    ],
-    "stateMutability": "view",
-    "type": "function"
-  }
-]
-```
diff --git a/content/course/customizing-evm/08-calculator-precompile/02-generating-precompile.mdx b/content/course/customizing-evm/08-calculator-precompile/02-generating-precompile.mdx
deleted file mode 100644
index 5bee640c..00000000
--- a/content/course/customizing-evm/08-calculator-precompile/02-generating-precompile.mdx
+++ /dev/null
@@ -1,303 +0,0 @@
----
-title: Generating the Precompile
-description: Learn how to generating the precompile
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-In this step, we will again utilize the precompile generation script to generate all the Go files based on the ABI for your calculator.
-
-## Run Generation Script
-
-Change to the root directory of your precompile-evm project and run the command to generate the go files:
-
-```bash
-# Change to root
-cd ..
-
-# Generate go files
-./scripts/generate_precompile.sh --abi ./contracts/abis/ICalculatorPlus.abi --type Calculatorplus --pkg calculatorplus --out ./calculatorplus
-```
-
-Now you should have a new directory called `calculatorplus` in the root directory of your project.
-
-If you check our the generated contract.go file you will see right away that it is much longer than in our hash function precompile from earlier. This is due to the fact that our calculator precompile has more functions and parameters. Browse through the code and see if you can spot the new elements:
-
-```go title="contract.go"
-// Code generated
-// This file is a generated precompile contract config with stubbed abstract functions.
-// The file is generated by a template. Please inspect every code and comment in this file before use.
-
-package calculatorplus
-
-import (
-    "errors"
-    "fmt"
-    "math/big"
-
-    "github.com/ava-labs/subnet-evm/accounts/abi"
-    "github.com/ava-labs/subnet-evm/precompile/contract"
-    "github.com/ava-labs/subnet-evm/vmerrs"
-
-    _ "embed"
-
-    "github.com/ethereum/go-ethereum/common"
-)
-
-const (
-    // Gas costs for each function. These are set to 1 by default.
-    // You should set a gas cost for each function in your contract.
-    // Generally, you should not set gas costs very low as this may cause your network to be vulnerable to DoS attacks.
-    // There are some predefined gas costs in contract/utils.go that you can use.
-    ModuloPlusGasCost uint64 = 1 /* SET A GAS COST HERE */
-    PowOfThreeGasCost uint64 = 1 /* SET A GAS COST HERE */
-    SimplFracGasCost  uint64 = 1 /* SET A GAS COST HERE */
-)
-
-// CUSTOM CODE STARTS HERE
-// Reference imports to suppress errors from unused imports. This code and any unnecessary imports can be removed.
-var (
-    _ = abi.JSON
-    _ = errors.New
-    _ = big.NewInt
-    _ = vmerrs.ErrOutOfGas
-    _ = common.Big0
-)
-
-// Singleton StatefulPrecompiledContract and signatures.
-var (
-    // CalculatorplusRawABI contains the raw ABI of Calculatorplus contract.
-    //go:embed contract.abi
-    CalculatorplusRawABI string
-
-    CalculatorplusABI = contract.ParseABI(CalculatorplusRawABI)
-
-    CalculatorplusPrecompile = createCalculatorplusPrecompile()
-)
-
-type ModuloPlusInput struct {
-    Dividend *big.Int
-    Divisor  *big.Int
-}
-
-type ModuloPlusOutput struct {
-    Multiple  *big.Int
-    Remainder *big.Int
-}
-
-type PowOfThreeOutput struct {
-    SecondPow *big.Int
-    ThirdPow  *big.Int
-    FourthPow *big.Int
-}
-
-type SimplFracInput struct {
-    Numerator   *big.Int
-    Denominator *big.Int
-}
-
-type SimplFracOutput struct {
-    SimplNum   *big.Int
-    SimplDenom *big.Int
-}
-
-// UnpackModuloPlusInput attempts to unpack [input] as ModuloPlusInput
-// assumes that [input] does not include selector (omits first 4 func signature bytes)
-func UnpackModuloPlusInput(input []byte) (ModuloPlusInput, error) {
-    inputStruct := ModuloPlusInput{}
-    err := CalculatorplusABI.UnpackInputIntoInterface(&inputStruct, "moduloPlus", input)
-
-    return inputStruct, err
-}
-
-// PackModuloPlus packs [inputStruct] of type ModuloPlusInput into the appropriate arguments for moduloPlus.
-func PackModuloPlus(inputStruct ModuloPlusInput) ([]byte, error) {
-    return CalculatorplusABI.Pack("moduloPlus", inputStruct.Dividend, inputStruct.Divisor)
-}
-
-// PackModuloPlusOutput attempts to pack given [outputStruct] of type ModuloPlusOutput
-// to conform the ABI outputs.
-func PackModuloPlusOutput(outputStruct ModuloPlusOutput) ([]byte, error) {
-    return CalculatorplusABI.PackOutput("moduloPlus",
-        outputStruct.Multiple,
-        outputStruct.Remainder,
-    )
-}
-
-// UnpackModuloPlusOutput attempts to unpack [output] as ModuloPlusOutput
-// assumes that [output] does not include selector (omits first 4 func signature bytes)
-func UnpackModuloPlusOutput(output []byte) (ModuloPlusOutput, error) {
-    outputStruct := ModuloPlusOutput{}
-    err := CalculatorplusABI.UnpackIntoInterface(&outputStruct, "moduloPlus", output)
-
-    return outputStruct, err
-}
-
-func moduloPlus(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-    if remainingGas, err = contract.DeductGas(suppliedGas, ModuloPlusGasCost); err != nil {
-        return nil, 0, err
-    }
-    // attempts to unpack [input] into the arguments to the ModuloPlusInput.
-    // Assumes that [input] does not include selector
-    // You can use unpacked [inputStruct] variable in your code
-    inputStruct, err := UnpackModuloPlusInput(input)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // CUSTOM CODE STARTS HERE
-    _ = inputStruct             // CUSTOM CODE OPERATES ON INPUT
-    var output ModuloPlusOutput // CUSTOM CODE FOR AN OUTPUT
-    packedOutput, err := PackModuloPlusOutput(output)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // Return the packed output and the remaining gas
-    return packedOutput, remainingGas, nil
-}
-
-// UnpackPowOfThreeInput attempts to unpack [input] into the *big.Int type argument
-// assumes that [input] does not include selector (omits first 4 func signature bytes)
-func UnpackPowOfThreeInput(input []byte) (*big.Int, error) {
-    res, err := CalculatorplusABI.UnpackInput("powOfThree", input)
-    if err != nil {
-        return new(big.Int), err
-    }
-    unpacked := *abi.ConvertType(res[0], new(*big.Int)).(**big.Int)
-    return unpacked, nil
-}
-
-// PackPowOfThree packs [base] of type *big.Int into the appropriate arguments for powOfThree.
-// the packed bytes include selector (first 4 func signature bytes).
-// This function is mostly used for tests.
-func PackPowOfThree(base *big.Int) ([]byte, error) {
-    return CalculatorplusABI.Pack("powOfThree", base)
-}
-
-// PackPowOfThreeOutput attempts to pack given [outputStruct] of type PowOfThreeOutput
-// to conform the ABI outputs.
-func PackPowOfThreeOutput(outputStruct PowOfThreeOutput) ([]byte, error) {
-    return CalculatorplusABI.PackOutput("powOfThree",
-        outputStruct.SecondPow,
-        outputStruct.ThirdPow,
-        outputStruct.FourthPow,
-    )
-}
-
-// UnpackPowOfThreeOutput attempts to unpack [output] as PowOfThreeOutput
-// assumes that [output] does not include selector (omits first 4 func signature bytes)
-func UnpackPowOfThreeOutput(output []byte) (PowOfThreeOutput, error) {
-    outputStruct := PowOfThreeOutput{}
-    err := CalculatorplusABI.UnpackIntoInterface(&outputStruct, "powOfThree", output)
-
-    return outputStruct, err
-}
-
-func powOfThree(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-    if remainingGas, err = contract.DeductGas(suppliedGas, PowOfThreeGasCost); err != nil {
-        return nil, 0, err
-    }
-    // attempts to unpack [input] into the arguments to the PowOfThreeInput.
-    // Assumes that [input] does not include selector
-    // You can use unpacked [inputStruct] variable in your code
-    inputStruct, err := UnpackPowOfThreeInput(input)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // CUSTOM CODE STARTS HERE
-    _ = inputStruct             // CUSTOM CODE OPERATES ON INPUT
-    var output PowOfThreeOutput // CUSTOM CODE FOR AN OUTPUT
-    packedOutput, err := PackPowOfThreeOutput(output)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // Return the packed output and the remaining gas
-    return packedOutput, remainingGas, nil
-}
-
-// UnpackSimplFracInput attempts to unpack [input] as SimplFracInput
-// assumes that [input] does not include selector (omits first 4 func signature bytes)
-func UnpackSimplFracInput(input []byte) (SimplFracInput, error) {
-    inputStruct := SimplFracInput{}
-    err := CalculatorplusABI.UnpackInputIntoInterface(&inputStruct, "simplFrac", input)
-
-    return inputStruct, err
-}
-
-// PackSimplFrac packs [inputStruct] of type SimplFracInput into the appropriate arguments for simplFrac.
-func PackSimplFrac(inputStruct SimplFracInput) ([]byte, error) {
-    return CalculatorplusABI.Pack("simplFrac", inputStruct.Numerator, inputStruct.Denominator)
-}
-
-// PackSimplFracOutput attempts to pack given [outputStruct] of type SimplFracOutput
-// to conform the ABI outputs.
-func PackSimplFracOutput(outputStruct SimplFracOutput) ([]byte, error) {
-    return CalculatorplusABI.PackOutput("simplFrac",
-        outputStruct.SimplNum,
-        outputStruct.SimplDenom,
-    )
-}
-
-// UnpackSimplFracOutput attempts to unpack [output] as SimplFracOutput
-// assumes that [output] does not include selector (omits first 4 func signature bytes)
-func UnpackSimplFracOutput(output []byte) (SimplFracOutput, error) {
-    outputStruct := SimplFracOutput{}
-    err := CalculatorplusABI.UnpackIntoInterface(&outputStruct, "simplFrac", output)
-
-    return outputStruct, err
-}
-
-func simplFrac(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-    if remainingGas, err = contract.DeductGas(suppliedGas, SimplFracGasCost); err != nil {
-        return nil, 0, err
-    }
-    // attempts to unpack [input] into the arguments to the SimplFracInput.
-    // Assumes that [input] does not include selector
-    // You can use unpacked [inputStruct] variable in your code
-    inputStruct, err := UnpackSimplFracInput(input)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // CUSTOM CODE STARTS HERE
-    _ = inputStruct            // CUSTOM CODE OPERATES ON INPUT
-    var output SimplFracOutput // CUSTOM CODE FOR AN OUTPUT
-    packedOutput, err := PackSimplFracOutput(output)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // Return the packed output and the remaining gas
-    return packedOutput, remainingGas, nil
-}
-
-// createCalculatorplusPrecompile returns a StatefulPrecompiledContract with getters and setters for the precompile.
-
-func createCalculatorplusPrecompile() contract.StatefulPrecompiledContract {
-    var functions []*contract.StatefulPrecompileFunction
-
-    abiFunctionMap := map[string]contract.RunStatefulPrecompileFunc{
-        "moduloPlus": moduloPlus,
-        "powOfThree": powOfThree,
-        "simplFrac":  simplFrac,
-    }
-
-    for name, function := range abiFunctionMap {
-        method, ok := CalculatorplusABI.Methods[name]
-        if !ok {
-            panic(fmt.Errorf("given method (%s) does not exist in the ABI", name))
-        }
-        functions = append(functions, contract.NewStatefulPrecompileFunction(method.ID, function))
-    }
-    // Construct the contract with no fallback function.
-    statefulContract, err := contract.NewStatefulPrecompileContract(nil, functions)
-    if err != nil {
-        panic(err)
-    }
-    return statefulContract
-}
-```
\ No newline at end of file
diff --git a/content/course/customizing-evm/08-calculator-precompile/03-unpacking-and-packing.mdx b/content/course/customizing-evm/08-calculator-precompile/03-unpacking-and-packing.mdx
deleted file mode 100644
index 2eac3fc6..00000000
--- a/content/course/customizing-evm/08-calculator-precompile/03-unpacking-and-packing.mdx
+++ /dev/null
@@ -1,109 +0,0 @@
----
-title: Unpacking Multiple Inputs & Packing Multiple Outputs
-description: Learn how to unpack multiple inputs and packing multiple outputs.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-## Unpack/Pack Functions For Each Operation
-
-As with the MD5 precompile, the generator created the pack/unpack functions for each operation of our Calculator and CalculatorPlus precompiles. However, you might have noticed that the generator also created some struct in each respective `contract.go` file. In the case of CalculatorPrecompile, we have:
-
-```go title="contract.go"
-type AddInput struct {
-    Value1 *big.Int
-    Value2 *big.Int
-}
-
-type NextTwoOutput struct {
-    Result1 *big.Int
-    Result2 *big.Int
-}
-
-type RepeatInput struct {
-    Times *big.Int
-    Text  string
-}
-```
-
-The generator creates these structs whenever a function defined in the respective Solidity interface has more than one input or more than one output. These multiple values are now stored together via structs.
-
-## Unpacking Multiple Inputs
-
-To understand how unpacking works when structs are introduced, let's take a look at the add function in the Calculator precompile, which takes in two inputs, and the nextTwo, which takes in only one input.
-
-```go
-// UnpackAddInput attempts to unpack [input] as AddInput
-// assumes that [input] does not include selector (omits first 4 func signature bytes)
-func UnpackAddInput(input []byte) (AddInput, error) {
-    inputStruct := AddInput{}
-    err := CalculatorABI.UnpackInputIntoInterface(&inputStruct, "add", input)
-    return inputStruct, err
-}
-
-// UnpackNextTwoInput attempts to unpack [input] into the *big.Int type argument
-// assumes that [input] does not include selector (omits first 4 func signature bytes)
-func UnpackNextTwoInput(input []byte) (*big.Int, error) {
-    res, err := CalculatorABI.UnpackInput("nextTwo", input)
-    if err != nil {
-        return big.NewInt(0), err
-    }
-    unpacked := *abi.ConvertType(res[0], new(*big.Int)).(**big.Int)
-    return unpacked, nil
-}
-```
-
-As you can see, both unpacker functions take a byte array as an input but the `UnpackAddInput` returns a value of the type `AddInput` (which contains two `big.Int` values) and `UnpackNextTwoInput` returns a value of the type `big.Int`.
-
-In each case, the respective unpacking function takes in a byte array as an input. However, `UnpackAddInput` returns a value of the type `AddInput`, which is a struct that contains two `big.Int` values. `UnpackNextTwo`, meanwhile, returns an value of type `big.Int`. 
-
-To demonstrate how one could use the output of unpacking functions like `UnpackAddInput`, below is the implementation of the add function of the Calculator precompile:
-
-```go
-func add(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-    if remainingGas, err = contract.DeductGas(suppliedGas, AddGasCost); err != nil {
-        return nil, 0, err
-    }
-    // attempts to unpack [input] into the arguments to the AddInput.
-    // Assumes that [input] does not include selector
-    // You can use unpacked [inputStruct] variable in your code
-    inputStruct, err := UnpackAddInput(input)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // CUSTOM CODE STARTS HERE
-    var output *big.Int // CUSTOM CODE FOR AN OUTPUT
-
-    output = big.NewInt(0).Add(inputStruct.Value1, inputStruct.Value2)
-
-    packedOutput, err := PackAddOutput(output)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // Return the packed output and the remaining gas
-    return packedOutput, remainingGas, nil
-}
-```
-
-## Packing Multiple Outputs
-
-To understand how structs affect the packing of outputs, lets refer to `PackNextTwoOutput` for the Calculator precompile:
-
-```go
-// PackHashWithMd5Output attempts to pack given hash of type [16]
-// PackNextTwoOutput attempts to pack given [outputStruct] of type NextTwoOutput
-// to conform the ABI outputs.
-func PackNextTwoOutput(outputStruct NextTwoOutput) ([]byte, error) {
-    return CalculatorABI.PackOutput("nextTwo",
-        outputStruct.Result1,
-        outputStruct.Result2,
-    )
-}
-```           
-        
-Notice here that even though we are no longer working with singular types, the generator still is able to pack our struct so that it is of the type bytes.
-
-As a result, we are able to return the packed version of any `NextTwoOutput` struct as bytes at the end of nextTwo.
diff --git a/content/course/customizing-evm/08-calculator-precompile/04-implementing-precompile.mdx b/content/course/customizing-evm/08-calculator-precompile/04-implementing-precompile.mdx
deleted file mode 100644
index 2be82d1b..00000000
--- a/content/course/customizing-evm/08-calculator-precompile/04-implementing-precompile.mdx
+++ /dev/null
@@ -1,593 +0,0 @@
----
-title: Implementing Precompile
-description: Learn how to implement the precompile in `contract.go`
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-In this section, we will go define the logic for our CalculatorPlus precompile; in particular, we want to add the logic for the following three functions: `powOfThree`, `moduloPlus`, and `simplFrac`.
-
-For those worried about this section - don't be! Our solution only added 12 lines of code to `contract.go`.
-
-## Looking at Calculator
-
-Before we define the logic of CalculatorPlus, we first will examine the implementation of the Calculator precompile:
-
-```go
-func add(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-    if remainingGas, err = contract.DeductGas(suppliedGas, AddGasCost); err != nil {
-        return nil, 0, err
-    }
-    // attempts to unpack [input] into the arguments to the AddInput.
-    // Assumes that [input] does not include selector
-    // You can use unpacked [inputStruct] variable in your code
-    inputStruct, err := UnpackAddInput(input)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // CUSTOM CODE STARTS HERE
-  
-    _ = inputStruct          // CUSTOM CODE OPERATES ON INPUT
-  
-    var output *big.Int // CUSTOM CODE FOR AN OUTPUT
-
-    output = big.NewInt(0).Add(inputStruct.Value1, inputStruct.Value2)
-
-    packedOutput, err := PackAddOutput(output)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // Return the packed output and the remaining gas
-    return packedOutput, remainingGas, nil
-}
-// ...
-
-func repeat(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-    if remainingGas, err = contract.DeductGas(suppliedGas, RepeatGasCost); err != nil {
-        return nil, 0, err
-    }
-    // attempts to unpack [input] into the arguments to the RepeatInput.
-    // Assumes that [input] does not include selector
-    // You can use unpacked [inputStruct] variable in your code
-    inputStruct, err := UnpackRepeatInput(input)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // CUSTOM CODE STARTS HERE
-    _ = inputStruct          // CUSTOM CODE OPERATES ON INPUT
-  
-    var output string // CUSTOM CODE FOR AN OUTPUT
-
-    output = strings.Repeat(inputStruct.Text, int(inputStruct.Times.Int64()))
-
-    packedOutput, err := PackRepeatOutput(output)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // Return the packed output and the remaining gas
-    return packedOutput, remainingGas, nil
-}
-
-// ...
-
-func nextTwo(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-    if remainingGas, err = contract.DeductGas(suppliedGas, NextTwoGasCost); err != nil {
-        return nil, 0, err
-    }
-    // attempts to unpack [input] into the arguments to the NextTwoInput.
-    // Assumes that [input] does not include selector
-    // You can use unpacked [inputStruct] variable in your code
-    inputStruct, err := UnpackNextTwoInput(input)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // CUSTOM CODE STARTS HERE
-  
-    _ = inputStruct          // CUSTOM CODE OPERATES ON INPUT
-  
-    var output NextTwoOutput // CUSTOM CODE FOR AN OUTPUT
-
-    output.Result1 = big.NewInt(0).Add(inputStruct, big.NewInt(1))
-    output.Result2 = big.NewInt(0).Add(inputStruct, big.NewInt(2))
-
-    packedOutput, err := PackNextTwoOutput(output)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // Return the packed output and the remaining gas
-    return packedOutput, remainingGas, nil
-}
-```
-
-Although the code snippet above may be long, you might notice that we added only four lines of code to the autogenerated code provided to us by Precompile-EVM! In particular, we only added lines 19, 48, 79, and 80. In general, note the following:
-
-- Structs vs Singular Values: make sure to keep track which inputs/outputs are structs and which one are values like big.Int. As an example, in `nextTwo`, we are dealing with a big.Int type input. However, in repeat, we are passed in a input of type struct RepeatInput.
-- Documentation: for both Calculator and CalculatorPlus, the big package documentation is of great reference: https://pkg.go.dev/math/big 
-
-Now that we have looked at the implementation for the Calculator precompile, its time you define the CalculatorPlus precompile!
-
-## Implementing moduloPlus
-
-We start by looking at the starter code for `moduloPlus`:
-
-```go
-func moduloPlus(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-    if remainingGas, err = contract.DeductGas(suppliedGas, ModuloPlusGasCost); err != nil {
-        return nil, 0, err
-    }
-    // attempts to unpack [input] into the arguments to the ModuloPlusInput.
-    // Assumes that [input] does not include selector
-    // You can use unpacked [inputStruct] variable in your code
-    inputStruct, err := UnpackModuloPlusInput(input)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // CUSTOM CODE STARTS HERE
-    _ = inputStruct             // CUSTOM CODE OPERATES ON INPUT
-    var output ModuloPlusOutput // CUSTOM CODE FOR AN OUTPUT
-    
-    packedOutput, err := PackModuloPlusOutput(output)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // Return the packed output and the remaining gas
-    return packedOutput, remainingGas, nil
-}
-```
-
-We want to note the following:
-
-- `inputStruct` is the input that we want to work with (i.e. `inputStruct` contains the two numbers that we want to use for the modulo calculation)
-- All of our code will go after line 15
-- We want the struct output to contain the result of our modulo operation (the struct will contain the multiple and remainder)
-
-With this in mind, try to implement `moduloPlus`.
-
-<Accordions>
-<Accordion title="Solution">
-
-```go
-func moduloPlus(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {func moduloPlus(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-	if remainingGas, err = contract.DeductGas(suppliedGas, ModuloPlusGasCost); err != nil {
-		return nil, 0, err
-	}
-	// attempts to unpack [input] into the arguments to the ModuloPlusInput.
-	// Assumes that [input] does not include selector
-	// You can use unpacked [inputStruct] variable in your code
-	inputStruct, err := UnpackModuloPlusInput(input)
-	if err != nil {
-		return nil, remainingGas, err
-	}
-
-	// CUSTOM CODE STARTS HERE
-	_ = inputStruct             // CUSTOM CODE OPERATES ON INPUT
-	var output ModuloPlusOutput // CUSTOM CODE FOR AN OUTPUT
-	output.Multiple, output.Remainder = big.NewInt(0).DivMod(inputStruct.Dividend, inputStruct.Divisor, output.Remainder)
-
-	packedOutput, err := PackModuloPlusOutput(output)
-	if err != nil {
-		return nil, remainingGas, err
-	}
-
-	// Return the packed output and the remaining gas
-	return packedOutput, remainingGas, nil
-}
-```
-
-</Accordion>
-</Accordions>
-
-## Implementing powOfThree
-
-Likewise, for `powOfThree`, we want to define the logic of the function in the custom code section. However, note that while we are working with an output struct, our input is a singular value. With this in mind, take a crack at implementing `powOfThree`:
-
-<Accordions>
-<Accordion title="Solution">
-
-```go
-func powOfThree(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {func powOfThree(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-	if remainingGas, err = contract.DeductGas(suppliedGas, PowOfThreeGasCost); err != nil {
-		return nil, 0, err
-	}
-	// attempts to unpack [input] into the arguments to the PowOfThreeInput.
-	// Assumes that [input] does not include selector
-	// You can use unpacked [inputStruct] variable in your code
-	inputStruct, err := UnpackPowOfThreeInput(input)
-	if err != nil {
-		return nil, remainingGas, err
-	}
-
-	// CUSTOM CODE STARTS HERE
-	_ = inputStruct             // CUSTOM CODE OPERATES ON INPUT
-	var output PowOfThreeOutput // CUSTOM CODE FOR AN OUTPUT
-
-	output.SecondPow = big.NewInt(0).Exp(inputStruct, big.NewInt(2), nil)
-	output.ThirdPow = big.NewInt(0).Exp(inputStruct, big.NewInt(3), nil)
-	output.FourthPow = big.NewInt(0).Exp(inputStruct, big.NewInt(4), nil)
-
-	packedOutput, err := PackPowOfThreeOutput(output)
-	if err != nil {
-		return nil, remainingGas, err
-	}
-
-	// Return the packed output and the remaining gas
-	return packedOutput, remainingGas, nil
-}
-```
-
-</Accordion>
-</Accordions>
-
-## Implementing simplFrac
-
-For implementing `simplFrac`, note the following:
-
-- The documentation for the big package will be of use here
-- Remember to take care of the case when the denominator is 0
-
-<Accordions>
-<Accordion title="Solution">
-
-```go
-func simplFrac(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {func simplFrac(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-	if remainingGas, err = contract.DeductGas(suppliedGas, SimplFracGasCost); err != nil {
-		return nil, 0, err
-	}
-	// attempts to unpack [input] into the arguments to the SimplFracInput.
-	// Assumes that [input] does not include selector
-	// You can use unpacked [inputStruct] variable in your code
-	inputStruct, err := UnpackSimplFracInput(input)
-	if err != nil {
-		return nil, remainingGas, err
-	}
-
-	// CUSTOM CODE STARTS HERE
-	_ = inputStruct            // CUSTOM CODE OPERATES ON INPUT
-	var output SimplFracOutput // CUSTOM CODE FOR AN OUTPUT
-
-	// If denominator is 0, return both 0
-	if inputStruct.Denominator.Cmp(big.NewInt(0)) == 0 {
-		output.SimplDenom = big.NewInt(0)
-		output.SimplNum = big.NewInt(0)
-	} else {
-		// First, find common denominator
-		var gcd big.Int
-		gcd.GCD(nil, nil, inputStruct.Numerator, inputStruct.Denominator)
-
-		// Now, simplify fraction
-		output.SimplNum = big.NewInt(0).Div(inputStruct.Numerator, &gcd)
-		output.SimplDenom = big.NewInt(0).Div(inputStruct.Denominator, &gcd)
-	}
-
-	packedOutput, err := PackSimplFracOutput(output)
-	if err != nil {
-		return nil, remainingGas, err
-	}
-
-	// Return the packed output and the remaining gas
-	return packedOutput, remainingGas, nil
-}
-```
-
-</Accordion>
-</Accordions>
-
-## Final Solution
-
-Below is the final solution for the CalculatorPlus precompile:
-
-<Accordions>
-<Accordion title="Solution">
-
-```go
-// Code generated
-// This file is a generated precompile contract config with stubbed abstract functions.
-// The file is generated by a template. Please inspect every code and comment in this file before use.
-
-package calculatorplus
-
-import (
-	"errors"
-	"fmt"
-	"math/big"
-
-	"github.com/ava-labs/subnet-evm/accounts/abi"
-	"github.com/ava-labs/subnet-evm/precompile/contract"
-	"github.com/ava-labs/subnet-evm/vmerrs"
-
-	_ "embed"
-
-	"github.com/ethereum/go-ethereum/common"
-)
-
-const (
-	// Gas costs for each function. These are set to 1 by default.
-	// You should set a gas cost for each function in your contract.
-	// Generally, you should not set gas costs very low as this may cause your network to be vulnerable to DoS attacks.
-	// There are some predefined gas costs in contract/utils.go that you can use.
-	ModuloPlusGasCost uint64 = 1 /* SET A GAS COST HERE */
-	PowOfThreeGasCost uint64 = 1 /* SET A GAS COST HERE */
-	SimplFracGasCost  uint64 = 1 /* SET A GAS COST HERE */
-)
-
-// CUSTOM CODE STARTS HERE
-// Reference imports to suppress errors from unused imports. This code and any unnecessary imports can be removed.
-var (
-	_ = abi.JSON
-	_ = errors.New
-	_ = big.NewInt
-	_ = vmerrs.ErrOutOfGas
-	_ = common.Big0
-)
-
-// Singleton StatefulPrecompiledContract and signatures.
-var (
-
-	// CalculatorplusRawABI contains the raw ABI of Calculatorplus contract.
-	//go:embed contract.abi
-	CalculatorplusRawABI string
-
-	CalculatorplusABI = contract.ParseABI(CalculatorplusRawABI)
-
-	CalculatorplusPrecompile = createCalculatorplusPrecompile()
-)
-
-type ModuloPlusInput struct {
-	Dividend *big.Int
-	Divisor  *big.Int
-}
-
-type ModuloPlusOutput struct {
-	Multiple  *big.Int
-	Remainder *big.Int
-}
-
-type PowOfThreeOutput struct {
-	SecondPow *big.Int
-	ThirdPow  *big.Int
-	FourthPow *big.Int
-}
-
-type SimplFracInput struct {
-	Numerator   *big.Int
-	Denominator *big.Int
-}
-
-type SimplFracOutput struct {
-	SimplNum   *big.Int
-	SimplDenom *big.Int
-}
-
-// UnpackModuloPlusInput attempts to unpack [input] as ModuloPlusInput
-// assumes that [input] does not include selector (omits first 4 func signature bytes)
-func UnpackModuloPlusInput(input []byte) (ModuloPlusInput, error) {
-	inputStruct := ModuloPlusInput{}
-	err := CalculatorplusABI.UnpackInputIntoInterface(&inputStruct, "moduloPlus", input)
-
-	return inputStruct, err
-}
-
-// PackModuloPlus packs [inputStruct] of type ModuloPlusInput into the appropriate arguments for moduloPlus.
-func PackModuloPlus(inputStruct ModuloPlusInput) ([]byte, error) {
-	return CalculatorplusABI.Pack("moduloPlus", inputStruct.Dividend, inputStruct.Divisor)
-}
-
-// PackModuloPlusOutput attempts to pack given [outputStruct] of type ModuloPlusOutput
-// to conform the ABI outputs.
-func PackModuloPlusOutput(outputStruct ModuloPlusOutput) ([]byte, error) {
-	return CalculatorplusABI.PackOutput("moduloPlus",
-		outputStruct.Multiple,
-		outputStruct.Remainder,
-	)
-}
-
-// UnpackModuloPlusOutput attempts to unpack [output] as ModuloPlusOutput
-// assumes that [output] does not include selector (omits first 4 func signature bytes)
-func UnpackModuloPlusOutput(output []byte) (ModuloPlusOutput, error) {
-	outputStruct := ModuloPlusOutput{}
-	err := CalculatorplusABI.UnpackIntoInterface(&outputStruct, "moduloPlus", output)
-
-	return outputStruct, err
-}
-
-func moduloPlus(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-	if remainingGas, err = contract.DeductGas(suppliedGas, ModuloPlusGasCost); err != nil {
-		return nil, 0, err
-	}
-	// attempts to unpack [input] into the arguments to the ModuloPlusInput.
-	// Assumes that [input] does not include selector
-	// You can use unpacked [inputStruct] variable in your code
-	inputStruct, err := UnpackModuloPlusInput(input)
-	if err != nil {
-		return nil, remainingGas, err
-	}
-
-	// CUSTOM CODE STARTS HERE
-	_ = inputStruct             // CUSTOM CODE OPERATES ON INPUT
-	var output ModuloPlusOutput // CUSTOM CODE FOR AN OUTPUT
-	output.Multiple, output.Remainder = big.NewInt(0).DivMod(inputStruct.Dividend, inputStruct.Divisor, output.Remainder)
-
-	packedOutput, err := PackModuloPlusOutput(output)
-	if err != nil {
-		return nil, remainingGas, err
-	}
-
-	// Return the packed output and the remaining gas
-	return packedOutput, remainingGas, nil
-}
-
-// UnpackPowOfThreeInput attempts to unpack [input] into the *big.Int type argument
-// assumes that [input] does not include selector (omits first 4 func signature bytes)
-func UnpackPowOfThreeInput(input []byte) (*big.Int, error) {
-	res, err := CalculatorplusABI.UnpackInput("powOfThree", input)
-	if err != nil {
-		return new(big.Int), err
-	}
-	unpacked := *abi.ConvertType(res[0], new(*big.Int)).(**big.Int)
-	return unpacked, nil
-}
-
-// PackPowOfThree packs [base] of type *big.Int into the appropriate arguments for powOfThree.
-// the packed bytes include selector (first 4 func signature bytes).
-// This function is mostly used for tests.
-func PackPowOfThree(base *big.Int) ([]byte, error) {
-	return CalculatorplusABI.Pack("powOfThree", base)
-}
-
-// PackPowOfThreeOutput attempts to pack given [outputStruct] of type PowOfThreeOutput
-// to conform the ABI outputs.
-func PackPowOfThreeOutput(outputStruct PowOfThreeOutput) ([]byte, error) {
-	return CalculatorplusABI.PackOutput("powOfThree",
-		outputStruct.SecondPow,
-		outputStruct.ThirdPow,
-		outputStruct.FourthPow,
-	)
-}
-
-// UnpackPowOfThreeOutput attempts to unpack [output] as PowOfThreeOutput
-// assumes that [output] does not include selector (omits first 4 func signature bytes)
-func UnpackPowOfThreeOutput(output []byte) (PowOfThreeOutput, error) {
-	outputStruct := PowOfThreeOutput{}
-	err := CalculatorplusABI.UnpackIntoInterface(&outputStruct, "powOfThree", output)
-
-	return outputStruct, err
-}
-
-func powOfThree(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-	if remainingGas, err = contract.DeductGas(suppliedGas, PowOfThreeGasCost); err != nil {
-		return nil, 0, err
-	}
-	// attempts to unpack [input] into the arguments to the PowOfThreeInput.
-	// Assumes that [input] does not include selector
-	// You can use unpacked [inputStruct] variable in your code
-	inputStruct, err := UnpackPowOfThreeInput(input)
-	if err != nil {
-		return nil, remainingGas, err
-	}
-
-	// CUSTOM CODE STARTS HERE
-	_ = inputStruct             // CUSTOM CODE OPERATES ON INPUT
-	var output PowOfThreeOutput // CUSTOM CODE FOR AN OUTPUT
-
-	output.SecondPow = big.NewInt(0).Exp(inputStruct, big.NewInt(2), nil)
-	output.ThirdPow = big.NewInt(0).Exp(inputStruct, big.NewInt(3), nil)
-	output.FourthPow = big.NewInt(0).Exp(inputStruct, big.NewInt(4), nil)
-
-	packedOutput, err := PackPowOfThreeOutput(output)
-	if err != nil {
-		return nil, remainingGas, err
-	}
-
-	// Return the packed output and the remaining gas
-	return packedOutput, remainingGas, nil
-}
-
-// UnpackSimplFracInput attempts to unpack [input] as SimplFracInput
-// assumes that [input] does not include selector (omits first 4 func signature bytes)
-func UnpackSimplFracInput(input []byte) (SimplFracInput, error) {
-	inputStruct := SimplFracInput{}
-	err := CalculatorplusABI.UnpackInputIntoInterface(&inputStruct, "simplFrac", input)
-
-	return inputStruct, err
-}
-
-// PackSimplFrac packs [inputStruct] of type SimplFracInput into the appropriate arguments for simplFrac.
-func PackSimplFrac(inputStruct SimplFracInput) ([]byte, error) {
-	return CalculatorplusABI.Pack("simplFrac", inputStruct.Numerator, inputStruct.Denominator)
-}
-
-// PackSimplFracOutput attempts to pack given [outputStruct] of type SimplFracOutput
-// to conform the ABI outputs.
-func PackSimplFracOutput(outputStruct SimplFracOutput) ([]byte, error) {
-	return CalculatorplusABI.PackOutput("simplFrac",
-		outputStruct.SimplNum,
-		outputStruct.SimplDenom,
-	)
-}
-
-// UnpackSimplFracOutput attempts to unpack [output] as SimplFracOutput
-// assumes that [output] does not include selector (omits first 4 func signature bytes)
-func UnpackSimplFracOutput(output []byte) (SimplFracOutput, error) {
-	outputStruct := SimplFracOutput{}
-	err := CalculatorplusABI.UnpackIntoInterface(&outputStruct, "simplFrac", output)
-
-	return outputStruct, err
-}
-
-func simplFrac(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-	if remainingGas, err = contract.DeductGas(suppliedGas, SimplFracGasCost); err != nil {
-		return nil, 0, err
-	}
-	// attempts to unpack [input] into the arguments to the SimplFracInput.
-	// Assumes that [input] does not include selector
-	// You can use unpacked [inputStruct] variable in your code
-	inputStruct, err := UnpackSimplFracInput(input)
-	if err != nil {
-		return nil, remainingGas, err
-	}
-
-	// CUSTOM CODE STARTS HERE
-	_ = inputStruct            // CUSTOM CODE OPERATES ON INPUT
-	var output SimplFracOutput // CUSTOM CODE FOR AN OUTPUT
-
-	// If denominator is 0, return both 0
-	if inputStruct.Denominator.Cmp(big.NewInt(0)) == 0 {
-		output.SimplDenom = big.NewInt(0)
-		output.SimplNum = big.NewInt(0)
-	} else {
-		// First, find common denominator
-		var gcd big.Int
-		gcd.GCD(nil, nil, inputStruct.Numerator, inputStruct.Denominator)
-
-		// Now, simplify fraction
-		output.SimplNum = big.NewInt(0).Div(inputStruct.Numerator, &gcd)
-		output.SimplDenom = big.NewInt(0).Div(inputStruct.Denominator, &gcd)
-	}
-
-	packedOutput, err := PackSimplFracOutput(output)
-	if err != nil {
-		return nil, remainingGas, err
-	}
-
-	// Return the packed output and the remaining gas
-	return packedOutput, remainingGas, nil
-}
-
-// createCalculatorplusPrecompile returns a StatefulPrecompiledContract with getters and setters for the precompile.
-
-func createCalculatorplusPrecompile() contract.StatefulPrecompiledContract {
-	var functions []*contract.StatefulPrecompileFunction
-
-	abiFunctionMap := map[string]contract.RunStatefulPrecompileFunc{
-		"moduloPlus": moduloPlus,
-		"powOfThree": powOfThree,
-		"simplFrac":  simplFrac,
-	}
-
-	for name, function := range abiFunctionMap {
-		method, ok := CalculatorplusABI.Methods[name]
-		if !ok {
-			panic(fmt.Errorf("given method (%s) does not exist in the ABI", name))
-		}
-		functions = append(functions, contract.NewStatefulPrecompileFunction(method.ID, function))
-	}
-	// Construct the contract with no fallback function.
-	statefulContract, err := contract.NewStatefulPrecompileContract(nil, functions)
-	if err != nil {
-		panic(err)
-	}
-	return statefulContract
-}
-```
-
-</Accordion>
-</Accordions>
diff --git a/content/course/customizing-evm/08-calculator-precompile/05-set-configkey-contractaddr.mdx b/content/course/customizing-evm/08-calculator-precompile/05-set-configkey-contractaddr.mdx
deleted file mode 100644
index 0c265347..00000000
--- a/content/course/customizing-evm/08-calculator-precompile/05-set-configkey-contractaddr.mdx
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Setting the ConfigKey & ContractAddress
-description: Learn how to set the ConfigKey, ContractAddress and register the Precompile.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-## ConfigKey
-
-Just as with the MD5 precompile in the previous section, go to the `module.go` file and set a `ConfigKey`.
-
-## Contract Address
-
-In the same file, set a `ContractAddress`. Choose one that has not been used by other precompiles of earlier sections.
-
-## Registration
-
-Go to the `plugin/main.go` file and register the new precompile.
\ No newline at end of file
diff --git a/content/course/customizing-evm/08-calculator-precompile/06-create-genesis-block.mdx b/content/course/customizing-evm/08-calculator-precompile/06-create-genesis-block.mdx
deleted file mode 100644
index 2b554342..00000000
--- a/content/course/customizing-evm/08-calculator-precompile/06-create-genesis-block.mdx
+++ /dev/null
@@ -1,72 +0,0 @@
----
-title: Creating Genesis Block with precompileConfig
-description: Learn how to create a genesis block with precompileConfig.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-In order to create a new Blockchain from our customized EVM, we have to define a Genesis block just as we did in out section earlier.
-
-To incorporate the CalculatorPlus precompile as part of the genesis block, we need to create a new genesis file and include a key for the CalculatorPlus precompile in the configuration JSON. This key, in particular, is the `configKey` that we specified in the `module.go` file of the Calculator precompile in the previous section.
-
-Copy over `Calculator.json` into a new file called `CalculatorPlus.json` and add the necessary key-pair value to the config.
-
-<Accordions>
-<Accordion title="Solution">
-
-```json title="CalculatorPlus.json"
-{
-  "config": {
-    "chainId": 99999,
-    "homesteadBlock": 0,
-    "eip150Block": 0,
-    "eip150Hash": "0x2086799aeebeae135c246c65021c82b4e15a2c451340993aacfd2751886514f0",
-    "eip155Block": 0,
-    "eip158Block": 0,
-    "byzantiumBlock": 0,
-    "constantinopleBlock": 0,
-    "petersburgBlock": 0,
-    "istanbulBlock": 0,
-    "muirGlacierBlock": 0,
-    "subnetEVMTimestamp": 0,
-    "feeConfig": {
-      "gasLimit": 20000000,
-      "minBaseFee": 1000000000,
-      "targetGas": 100000000,
-      "baseFeeChangeDenominator": 48,
-      "minBlockGasCost": 0,
-      "maxBlockGasCost": 10000000,
-      "targetBlockRate": 2,
-      "blockGasCostStep": 500000
-    },
-    "sha256Config": {
-      "blockTimestamp": 0
-    },
-    "calculatorConfig": {
-      "blockTimestamp": 0
-    },
-    "calculatorplusConfig" : {
-        "blockTimestamp": 0
-    }
-  },
-  "alloc": {
-    "8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC": {
-      "balance": "0x52B7D2DCC80CD2E4000000"
-    }
-  },
-  "nonce": "0x0",
-  "timestamp": "0x0",
-  "extraData": "0x00",
-  "gasLimit": "0x1312D00",
-  "difficulty": "0x0",
-  "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
-  "coinbase": "0x0000000000000000000000000000000000000000",
-  "number": "0x0",
-  "gasUsed": "0x0",
-  "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000"
-}
-```
-
-</Accordion>
-</Accordions>
\ No newline at end of file
diff --git a/content/course/customizing-evm/08-calculator-precompile/07-testing-precompile.mdx b/content/course/customizing-evm/08-calculator-precompile/07-testing-precompile.mdx
deleted file mode 100644
index f151f030..00000000
--- a/content/course/customizing-evm/08-calculator-precompile/07-testing-precompile.mdx
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Testing Precompiles via Go
-description: Learn how to test your Precompiles using Golang.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-> Program testing can be used to show the presence of bugs, but never to show their absence. - Edsger W. Dijkstra
-
-Let's once again examine the functions of the Calculator precompile and what each one does (in layman terms):
-
-- `add`: computes the sum of two numbers
-- `nextTwo`: returns the next two numbers that come after the input given 
-- `repeat`: repeats a string N number of times
-
-While we spent a good amount of time in the previous sections examining Calculator Solidity interface and the Go logic, we forgot to do one thing: *test the functionality of Calculator*.
-
-But why test? For some, it may seems pointless to test such basic functions. However, testing all functions is important because it helps validate our belief that the logic of our functions is what we intended them to be.
-
-In this section, we will focus on utilizing three types of tests for our Calculator precompile:
-
-1. Autogenerated Tests
-2. Unit Tests
-3. Fuzz Tests
\ No newline at end of file
diff --git a/content/course/customizing-evm/08-calculator-precompile/08-autogenerated-tests.mdx b/content/course/customizing-evm/08-calculator-precompile/08-autogenerated-tests.mdx
deleted file mode 100644
index be092489..00000000
--- a/content/course/customizing-evm/08-calculator-precompile/08-autogenerated-tests.mdx
+++ /dev/null
@@ -1,172 +0,0 @@
----
-title: Modify Autogenerated Tests
-description: Learn how to modify autogenerated tests in Go.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-The autogenerated tests will help us making sure, that our precompile throw an error in case not enough gas is supplied. To start, go to calculator/contract_test.go, where you will see the following:
-
-```go
-// Code generated
-// This file is a generated precompile contract test with the skeleton of test functions.
-// The file is generated by a template. Please inspect every code and comment in this file before use.
-
-package calculator
-
-import (
-    "testing"
-
-    "github.com/ava-labs/subnet-evm/core/state"
-    "github.com/ava-labs/subnet-evm/precompile/testutils"
-    "github.com/ava-labs/subnet-evm/vmerrs"
-    "github.com/ethereum/go-ethereum/common"
-    "github.com/stretchr/testify/require"
-)
-
-// These tests are run against the precompile contract directly with
-// the given input and expected output. They're just a guide to
-// help you write your own tests. These tests are for general cases like
-// allowlist, readOnly behaviour, and gas cost. You should write your own
-// tests for specific cases.
-var (
-    tests = map[string]testutils.PrecompileTest{
-        "insufficient gas for add should fail": {
-            Caller: common.Address{1},
-            InputFn: func(t testing.TB) []byte {
-                // CUSTOM CODE STARTS HERE
-                // populate test input here
-                testInput := AddInput{}
-                input, err := PackAdd(testInput)
-                require.NoError(t, err)
-                return input
-            },
-            SuppliedGas: AddGasCost - 1,
-            ReadOnly:    false,
-            ExpectedErr: vmerrs.ErrOutOfGas.Error(),
-        },
-        "insufficient gas for nextTwo should fail": {
-            Caller: common.Address{1},
-            InputFn: func(t testing.TB) []byte {
-                // CUSTOM CODE STARTS HERE
-                // set test input to a value here
-                var testInput *big.Int
-                input, err := PackNextTwo(testInput)
-                require.NoError(t, err)
-                return input
-            },
-            SuppliedGas: NextTwoGasCost - 1,
-            ReadOnly:    false,
-            ExpectedErr: vmerrs.ErrOutOfGas.Error(),
-        },
-        "insufficient gas for repeat should fail": {
-            Caller: common.Address{1},
-            InputFn: func(t testing.TB) []byte {
-                // CUSTOM CODE STARTS HERE
-                // populate test input here
-                testInput := RepeatInput{}
-                input, err := PackRepeat(testInput)
-                require.NoError(t, err)
-                return input
-            },
-            SuppliedGas: RepeatGasCost - 1,
-            ReadOnly:    false,
-            ExpectedErr: vmerrs.ErrOutOfGas.Error(),
-        },
-    }
-)
-
-// TestCalculatorEmptyRun tests the Run function of the precompile contract.
-func TestCalculatorEmptyRun(t *testing.T) {
-    // Run tests.
-    for name, test := range tests {
-        t.Run(name, func(t *testing.T) {
-            test.Run(t, Module, state.NewTestStateDB(t))
-        })
-    }
-}
-
-func BenchmarkCalculatorEmpty(b *testing.B) {
-    // Benchmark tests.
-    for name, test := range tests {
-        b.Run(name, func(b *testing.B) {
-            test.Bench(b, Module, state.NewTestStateDB(b))
-        })
-    }
-}
-```
-
-There is a lot to digest in `contract_test.go`, but the file can be divided into the following three sections:
-
-- Unit Tests
-- TestCalculatorEmptyRun
-- BenchmarkCalculator
-
-The autogenerated unit tests are stored in the variable var, which is a mapping from strings (the description of the tests cases) to individual unit tests (`testutils.PrecompileTest`). Upon inspecting the keys of each pair, you will see that all three autogenerated unit tests are checking the same thing that: `add`, `nextTwo`, and `repeat` fail if not enough gas is provided. Each test expects to fail when supplying too little gas:
-
-```go
-{
-  // ...
-  SuppliedGas: RepeatGasCost - 1,
-  ExpectedErr: vmerrs.ErrOutOfGas.Error(),
-}
-```
-
-As of currently, if you attempt to build and run the test cases, you will not get very far because there is one step we need to do to: pass in arguments for each autogenerated unit test. For each variable testInput defined in each unit test, add an argument. What argument to put down does not matter, it just needs to be a valid argument. An example of what arguments to put in can be found below:
-
-```go
-var (
-    tests = map[string]testutils.PrecompileTest{
-        "insufficient gas for add should fail": {
-            Caller: common.Address{1},
-            InputFn: func(t testing.TB) []byte {
-                // CUSTOM CODE STARTS HERE
-                // populate test input here
-                testInput := AddInput{big.NewInt(1), big.NewInt(1)}
-                input, err := PackAdd(testInput)
-                require.NoError(t, err)
-                return input
-            },
-            SuppliedGas: AddGasCost - 1,
-            ReadOnly:    false,
-            ExpectedErr: vmerrs.ErrOutOfGas.Error(),
-        },
-        "insufficient gas for nextTwo should fail": {
-            Caller: common.Address{1},
-            InputFn: func(t testing.TB) []byte {
-                // CUSTOM CODE STARTS HERE
-                // set test input to a value here
-                // var testInput *big.Int
-                testInput := big.NewInt(1)
-                input, err := PackNextTwo(testInput)
-                require.NoError(t, err)
-                return input
-            },
-            SuppliedGas: NextTwoGasCost - 1,
-            ReadOnly:    false,
-            ExpectedErr: vmerrs.ErrOutOfGas.Error(),
-        },
-        "insufficient gas for repeat should fail": {
-            Caller: common.Address{1},
-            InputFn: func(t testing.TB) []byte {
-                // CUSTOM CODE STARTS HERE
-                // populate test input here
-                testInput := RepeatInput{big.NewInt(1), "EGS"}
-                input, err := PackRepeat(testInput)
-                require.NoError(t, err)
-                return input
-            },
-            SuppliedGas: RepeatGasCost - 1,
-            ReadOnly:    false,
-            ExpectedErr: vmerrs.ErrOutOfGas.Error(),
-        },
-    }
-)
-```
-
-Now run the test by running the following command from the project root:
-
-```bash
-./scripts/build_test.sh
-```
\ No newline at end of file
diff --git a/content/course/customizing-evm/08-calculator-precompile/09-unit-tests.mdx b/content/course/customizing-evm/08-calculator-precompile/09-unit-tests.mdx
deleted file mode 100644
index c6680fe1..00000000
--- a/content/course/customizing-evm/08-calculator-precompile/09-unit-tests.mdx
+++ /dev/null
@@ -1,110 +0,0 @@
----
-title: Adding Unit Tests
-description: Learn how to add unit tests.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-Although the autogenerated units tests were useful in finding whether if the gas requirements of our functions were being fulfilled, we are yet to test the actual logic of our functions. We can add more unit tests by simply adding more mappings to the tests variable.
-
-To start, lets define the tests that we want to write for each function within our Calculator precompile:
-
-- `add`: check that **add(1, 2)** returns 3
-- `nextTwo`: check that **nextTwo(1)** returns 2, 3
-- `repeat`: check that **repeat(2, "EGS")** returns "EGSEGS"
-
-With this in mind, lets add the three units tests to the tests variable! Below is a code excerpt which shows the three unit tests incorporated:
-
-```go
-var (
-    expectedNextTwoOutcome, _ = PackNextTwoOutput(NextTwoOutput{big.NewInt(2), big.NewInt(3)})
-    expectedRepeatOutcome, _  = PackRepeatOutput("EGSEGS")
-    expectedAddOutcome        = common.LeftPadBytes(big.NewInt(3).Bytes(), common.HashLength)
-
-    tests = map[string]testutils.PrecompileTest{
-        "insufficient gas for add should fail": {
-            Caller: common.Address{1},
-            InputFn: func(t testing.TB) []byte {
-                // CUSTOM CODE STARTS HERE
-                // populate test input here
-                testInput := AddInput{big.NewInt(1), big.NewInt(1)}
-                input, err := PackAdd(testInput)
-                require.NoError(t, err)
-                return input
-            },
-            SuppliedGas: AddGasCost - 1,
-            ReadOnly:    false,
-            ExpectedErr: vmerrs.ErrOutOfGas.Error(),
-        },
-        "insufficient gas for nextTwo should fail": {
-            Caller: common.Address{1},
-            InputFn: func(t testing.TB) []byte {
-                // CUSTOM CODE STARTS HERE
-                // set test input to a value here
-                // var testInput *big.Int
-                testInput := big.NewInt(1)
-                input, err := PackNextTwo(testInput)
-                require.NoError(t, err)
-                return input
-            },
-            SuppliedGas: NextTwoGasCost - 1,
-            ReadOnly:    false,
-            ExpectedErr: vmerrs.ErrOutOfGas.Error(),
-        },
-        "insufficient gas for repeat should fail": {
-            Caller: common.Address{1},
-            InputFn: func(t testing.TB) []byte {
-                // CUSTOM CODE STARTS HERE
-                // populate test input here
-                testInput := RepeatInput{big.NewInt(1), "EGS"}
-                input, err := PackRepeat(testInput)
-                require.NoError(t, err)
-                return input
-            },
-            SuppliedGas: RepeatGasCost - 1,
-            ReadOnly:    false,
-            ExpectedErr: vmerrs.ErrOutOfGas.Error(),
-        },
-        "testing add": {
-            Caller: common.Address{1},
-            InputFn: func(t testing.TB) []byte {
-                value1 := big.NewInt(1)
-                value2 := big.NewInt(2)
-                testInput := AddInput{value1, value2}
-                input, err := PackAdd(testInput)
-                require.NoError(t, err)
-                return input
-            },
-            SuppliedGas: AddGasCost,
-            ReadOnly:    true,
-            ExpectedRes: expectedAddOutcome,
-        },
-        "testing nextTwo": {
-            Caller: common.Address{1},
-            InputFn: func(t testing.TB) []byte {
-                testInput := big.NewInt(1)
-                input, err := PackNextTwo(testInput)
-                require.NoError(t, err)
-                return input
-            },
-            SuppliedGas: NextTwoGasCost,
-            ReadOnly:    true,
-            ExpectedRes: expectedNextTwoOutcome,
-        },
-        "testing repeat": {
-            Caller: common.Address{1},
-            InputFn: func(t testing.TB) []byte {
-                baseString := "EGS"
-                timesToRepeat := big.NewInt(2)
-                input, err := PackRepeat(RepeatInput{timesToRepeat, baseString})
-                require.NoError(t, err)
-                return input
-            },
-            SuppliedGas: RepeatGasCost,
-            ReadOnly:    true,
-            ExpectedRes: expectedRepeatOutcome,
-        },
-    }
-)
-```
diff --git a/content/course/customizing-evm/08-calculator-precompile/10-fuzz-tests.mdx b/content/course/customizing-evm/08-calculator-precompile/10-fuzz-tests.mdx
deleted file mode 100644
index 57ff34e1..00000000
--- a/content/course/customizing-evm/08-calculator-precompile/10-fuzz-tests.mdx
+++ /dev/null
@@ -1,80 +0,0 @@
----
-title: Adding Fuzz Tests
-description: Learn how to add Fuzz tests.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-Units tests are useful when comparing the outcome of a predetermined input with the expected outcome. If we wanted to check that our function works as expected for all given inputs, the only way to show this would be to test every possible input.
-
-However, this is not possible for types such as uint256, as it would require us to test for 2^256 possible inputs. Even if we tested 1 input per second (or 2, 3, 4, 1000, etc.), this process would outlast the universe itself.
-
-Rather than testing every possible output, we can strengthen our confidence of the expected behavior of a function by testing a random sample of inputs. By testing randomly, we can test for inputs that we wouldn't have originally thought of and are able to see how our function behaves over a range of values.
-
-However, given that generating random inputs is not deterministic, we cannot use the tests variable itself. Rather, we will need to leverage the `TestCalculatorRun` function:
-
-```go
-// TestCalculatorEmptyRun tests the Run function of the precompile contract.
-func TestCalculatorRun(t *testing.T) {
-    // Run tests.
-    for name, test := range tests {
-        t.Run(name, func(t *testing.T) {
-            test.Run(t, Module, state.NewTestStateDB(t))
-        })
-    }
-}
-```
-
-The `TestCalculatorRun` function, by default, iterates through each unit test defined in the tests variable on runs said tests. However, we are not limited to just using `TestCalculatorRun` for the unit tests in tests. We can expand the functionality of `TestCalculatorRun` by adding our fuzz tests.
-
-In particular, we can define the following logic for `TestCalculatorRun`:
-
-- Iterate N number of times
-- For each iteration, pick two numbers in the range from 0 to n
-- After picking two random numbers, create a unit test with the two random numbers as inputs and execute said unit test
-
-With this logic in mind, below is the code for how we would go about implementing fuzzing in `TestCalculatorRun`:
-
-```go
-// TestCalculatorRun tests the Run function of the precompile contract.
-func TestCalculatorRun(t *testing.T) {
-    // Run tests.
-    for name, test := range tests {
-        t.Run(name, func(t *testing.T) {
-            test.Run(t, Module, state.NewTestStateDB(t))
-        })
-    }
-    // Defining own test cases here
-    N := 1_000
-    n := new(big.Int).Exp(big.NewInt(2), big.NewInt(int64(128)), nil)
-
-    // Fuzzing N times
-    for i := 0; i < N; i++ {
-        // Adding randomization test here
-        randomInt1, err := rand.Int(rand.Reader, n)
-        randomInt2, err := rand.Int(rand.Reader, n)
-        // Expected outcome
-        expectedRandOutcome := common.LeftPadBytes(big.NewInt(0).Add(randomInt1, randomInt2).Bytes(), common.HashLength)
-
-        // Pack add input
-        randTestInput := AddInput{randomInt1, randomInt2}
-        randInput, err := PackAdd(randTestInput)
-        require.NoError(t, err)
-
-        randTest := testutils.PrecompileTest{
-            Caller:      common.Address{1},
-            Input:       randInput,
-            SuppliedGas: AddGasCost,
-            ReadOnly:    true,
-            ExpectedRes: expectedRandOutcome,
-        }
-
-        t.Run("Testing random sum!", func(t *testing.T) {
-            randTest.Run(t, Module, state.NewTestStateDB(t))
-        })
-
-    }
-
-}
-```
diff --git a/content/course/customizing-evm/08-calculator-precompile/11-test-calculatorplus.mdx b/content/course/customizing-evm/08-calculator-precompile/11-test-calculatorplus.mdx
deleted file mode 100644
index d4e6ae84..00000000
--- a/content/course/customizing-evm/08-calculator-precompile/11-test-calculatorplus.mdx
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title: Testing CalculatorPlus
-description: Learn how to test CalculatorPlus precompile.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-import { Callout } from 'fumadocs-ui/components/callout';
-
-Now that we have gone through an example of how to test the Calculator precompile, it is time that you develop your own tests for CalculatorPlus.
-
-Rather than explicitly tell you what test cases to write, we decided to leave that to you. After all, testing is a subjective profession - a test suite that fits one security needs might be inadequate for someone else.
-
-However, if you want an idea for what to test for, the following are some recommendations:
-
-- Unit Tests: create some unit tests involving values that you can come up with. Ideally, write 3-5 unit tests for each function. 
-- Fuzz Tests: test more than 1000 random inputs for each function
-
-<Callout title="Note">For both unit and fuzz tests, make sure to account for the case when the denominator is equal to 0 in `simplFrac`.</Callout>
\ No newline at end of file
diff --git a/content/course/customizing-evm/09-stateful-precompiles/00-intro.mdx b/content/course/customizing-evm/09-stateful-precompiles/00-intro.mdx
deleted file mode 100644
index 54b984c0..00000000
--- a/content/course/customizing-evm/09-stateful-precompiles/00-intro.mdx
+++ /dev/null
@@ -1,142 +0,0 @@
----
-title: What are Stateful Precompiles?
-description: Learn about Stateful Precompiles in Avalanche L1 EVM.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Book
----
-
-When building the MD5 and Calculator precompiles, we emphasized their behavior. We focused on building precompiles that developers could call in Solidity to perform some algorithm and then simply return a result.
-
-However, one aspect that we have yet to explore is the statefulness of precompiles. Simply put, precompiles can store data which is persistent. To understand how this is possible, recall the interface that our precompile needed to implement:
-
-```go
-// StatefulPrecompiledContract is the interface for executing a precompiled contract
-type StatefulPrecompiledContract interface {
-    // Run executes the precompiled contract.
-    Run(accessibleState AccessibleState, 
-        caller common.Address, 
-        addr common.Address, 
-        input []byte, 
-        suppliedGas uint64, 
-        readOnly bool) 
-        (ret []byte, remainingGas uint64, err error)
-}
-```
-
-We also examined all parameters except for the `AccessibleState` parameter. As the name suggests, this parameter lets us access the blockchain's state. Looking at the interface of `AccessibleState`, we have the following:
-
-```go
-// AccessibleState defines the interface exposed to stateful precompile contracts
-type AccessibleState interface {
-    GetStateDB() StateDB
-    GetBlockContext() BlockContext
-    GetSnowContext() *snow.Context
-}
-```
-
-Looking closer, we see that `AccessibleState` gives us access to **StateDB**, which is used to store the state of the EVM. However, as we will see throughout this section, `AccessibleState` also gives us access to other useful parameters, such as `BlockContext` and `snow.Context`.
-
-## StateDB
-
-The parameter we will use the most when it comes to stateful precompiles, StateDB, is a key-value mapping that maps:
-
-- **Key**: a tuple consisting of an address and the storage key of the type Hash
-- **Value**: any data encoded in a Hash, also called a word in the EVM
-
-A Hash in go-ethereum is a 32-byte array. In this context, we do not refer to hashing in the cryptographic sense. Rather, "hashing a value" means encoding it to a hash, a 32-byte array usually represented in hexadecimal digits in Ethereum.
-
-```go
-const (
-    // HashLength is the expected length of the hash
-    HashLength = 32
-)
-
-// Hash represents the 32 byte of arbitrary data.
-type Hash [HashLength]byte
-
-// Example of a data encoded in a Hash: 
-// 0x00000000000000000000000000000000000000000048656c6c6f20576f726c64
-Below is the interface of StateDB:
-// StateDB is the interface for accessing EVM state
-type StateDB interface {
-    GetState(common.Address, common.Hash) common.Hash
-    SetState(common.Address, common.Hash, common.Hash)
-
-    SetNonce(common.Address, uint64)
-    GetNonce(common.Address) uint64
-
-    GetBalance(common.Address) *big.Int
-    AddBalance(common.Address, *big.Int)
-
-    CreateAccount(common.Address)
-    Exist(common.Address) bool
-
-    AddLog(addr common.Address, topics []common.Hash, data []byte, blockNumber uint64)
-    GetPredicateStorageSlots(address common.Address) ([]byte, bool)
-
-    Suicide(common.Address) bool
-    Finalise(deleteEmptyObjects bool)
-
-    Snapshot() int
-    RevertToSnapshot(int)
-}
-```
-
-As you can see in the interface of the **StateDB**, the two functions for writing to and reading from the EVM state all work with the Hash type.
-
-1. The function **GetState** takes an address and a Hash (the storage key) as inputs and returns the Hash stored at that slot.
-2. The function **SetState** takes an address, a Hash (the storage key), and another Hash (data to be stored) as inputs.
-
-We can also see that the **StateDB** interface allows us to read and write account balances of the native token (via GetBalance/SetBalance), check whether an account exists (via Exist), and some other methods.
-
-## BlockContext
-
-`BlockContext` provides info about the current block. In particular, we can get the current block number and the current block timestamp. Below is the interface of `BlockContext`:
-
-```go
-// BlockContext defines an interface that provides information to a stateful precompile about the current block.
-// The BlockContext may be provided during both precompile activation and execution.
-type BlockContext interface {
-    Number() *big.Int
-    Timestamp() *big.Int
-}
-```
-
-An example of how we could leverage `BlockContext` in precompiles: *building a voting precompile that only accepts votes within a certain time frame*.
-
-## snow.Context
-
-`snow.Context` gives us info regarding the environment of the precompile. In particular, `snow.Context` tells us about the state of the network the precompile is hosted on. Below is the interface of `snow.Context`:
-
-```go
-// Context is information about the current execution.
-// [NetworkID] is the ID of the network this context exists within.
-// [ChainID] is the ID of the chain this context exists within.
-// [NodeID] is the ID of this node
-type Context struct {
-    NetworkID uint32
-    Avalanche L1ID  ids.ID
-    ChainID   ids.ID
-    NodeID    ids.NodeID
-    PublicKey *bls.PublicKey
-
-    XChainID    ids.ID
-    CChainID    ids.ID
-    AVAXAssetID ids.ID
-
-    Log          logging.Logger
-    Lock         sync.RWMutex
-    Keystore     keystore.BlockchainKeystore
-    SharedMemory atomic.SharedMemory
-    BCLookup     ids.AliaserReader
-    Metrics      metrics.OptionalGatherer
-
-    WarpSigner warp.Signer
-
-    // snowman++ attributes
-    ValidatorState validators.State // interface for P-Chain validators
-    // Chain-specific directory where arbitrary data can be written
-    ChainDataDir string
-}
-```
\ No newline at end of file
diff --git a/content/course/customizing-evm/09-stateful-precompiles/01-interacting-with-precompile.mdx b/content/course/customizing-evm/09-stateful-precompiles/01-interacting-with-precompile.mdx
deleted file mode 100644
index 82d417df..00000000
--- a/content/course/customizing-evm/09-stateful-precompiles/01-interacting-with-precompile.mdx
+++ /dev/null
@@ -1,74 +0,0 @@
----
-title: Interacting with StringStore Precompile
-description: Learn how to interact with StringStore Stateful precompile.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-Rather than understanding the statefulness of precompiles only in theory, we can also play around with an example of a stateful precompile to learn how they work in practice.
-
-In this section, we'll interact with the **StringStore** precompile, a precompiled smart contract that stores a string.
-
-## Checking the Genesis JSON
-
-As part of all Avalanche Academy branches, your Precompile-EVM should include the **StringStore/** folder along with all other relevant files for StringStore to be recognized by Precompile-EVM. This includes a genesis JSON for StringStore.
-
-Go to `tests/precompile/genesis/` and double-check that you have a `StringStore.json` folder in said directory. This JSON files will instantiate both the **SHA256** precompile and **StringStore**.
-
-```json title="StringStore.json"
-{
-    "config": {
-      "chainId": 99999,
-      // ...
-      "stringStoreConfig" : {
-        "blockTimestamp": 0,
-        "defaultString": "Cornell"
-     }
-    },
-    // ...
-}
-```
-
-## Building the EVM with StringStore Precompile
-
-The **avalanche-academy-start** branch already contains the StringStore and SHA256 precompile. If you are working from that branch, you can simply use the built binary from your latest exercise without making any changes.
-
-To verify, check if the **stringstore** directory is in your workspace and if the precompile is noted in the `plugin/main.go` file. If not, switch to the **avalanche-academy-start** branch and build the VM there.
-
-## Start the Avalanche Network
-
-Use the Avalanche-CLI to start the server and the network. Use the provided genesis file `stringstore.json` mentioned above when you start the network.
-
-If all goes well, you will have successfully deployed a blockchain containing both the StringStore and SHA256 precompile.
-
-## Connecting Core
-
-Similar to previous chapters, navigate to the **Add Network** section in the Core Wallet. You can find the RPC URL in the Avalanche-CLI logs or by executing the command: `avalanche blockchain list --deployed`
-
-Note: Make sure the RPC URL ends with **/rpc**. The RPC URL should look something like this: http://127.0.0.1:9650/ext/bc/P9nKPGPoAfFGkdvD3Ac6YxZieaG8ahpbR9xZosrWNPbJCzByu/rpc
-
-Once you have added the blockchain network, switch Core Wallet to your blockchain.
-
-## Interact through Remix
-
-We will now load in the Solidity interface letting us interact with the **StringStore** precompile. To do this, open the link below, which will open a Remix workspace containing the StringStore precompile: [Workspace](https://remix.ethereum.org/#url=https://github.com/ava-labs/precompile-evm/blob/avalanche-academy-start/contracts/contracts/interfaces/IStringStore.sol&lang=en&optimize=false&runs=200&evmVersion=null&version=soljson-v0.8.26+commit.8a97fa7a.js)
-
-As usual, we will need to compile our Solidity interface.
-
-1. Click the **Solidity** logo on the left sidebar.
-2. In the new page, you will see a **Compile IStringStore.sol** button. After clicking the button, a green checkmark should appear next to the Solidity logo.
-3. Next, go to the **Environment** tab and select the **Injected Provider** option. If successful, a text saying **Custom [99999] Network** will appear below. If not, change your network.
-4. Enter the precompile address (find it in `precompile/stringstore/module.go`) and click **At Address**.
-
-First, we will call the `getString` function. By default, `getString` will return whatever was specified in the genesis JSON. Since we set our StringStore precompile to store the string **Cornell**, it'll return this value.
-
-![](/course-images/customizing-evm/48.png)
-
-As you might have noticed, we can also set the string that **StringStore** stores. For example, if we wanted to change the string to Avalanche, we would type Avalanche in the box next to `setString` method, press the `setString` button, and then you would see in the Remix terminal a message displaying the success of your transaction.
-
-If we call `getString` again, you will see that the string has been changed to Avalanche.
-
-Congrats, you've just interacted with the stateful **StringStore** precompile 🎉
-
-<Callout type="info">In contrast to the precompiles we have built earlier, the StringStore precompile has access to the EVM state. This way we can utilize precompile not only to perform calculations, but also persist something to the EVM state. This allows us to move even larger portions of our dApp from the solidity smart contract layer to the precompile layer. </Callout>
diff --git a/content/course/customizing-evm/10-stateful-counter-precompile/00-intro.mdx b/content/course/customizing-evm/10-stateful-counter-precompile/00-intro.mdx
deleted file mode 100644
index 5e185d25..00000000
--- a/content/course/customizing-evm/10-stateful-counter-precompile/00-intro.mdx
+++ /dev/null
@@ -1,31 +0,0 @@
----
-title: Creating Counter Precompile
-description: Learn how to create a Stateful Counter Precompiles in Avalanche L1 EVM.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Book
----
-
-## What We Are Building
-
-It's time to build our first stateful precompile. In particular, we'll build a counter that keeps track of an integer. Our Counter precompile will have the following logic:
-
-- Users are able to get the current value of the counter
-- Users are able to set a new value to the counter
-- Users are able to increment the value of the counter
-
-To help you understand, we've provided a reference stateful precompile: **StringStore**. As the name suggests, StringStore stores a string that users can change. This string is stored in the EVM state.
-
-## Overview of Steps
-
-Compared to the process before, we must also add tests for our precompile. Here's a quick overview of the steps we'll follow:
-
-1. Create a Solidity interface for the precompile and generate the ABI
-2. Generate the precompile Go boilerplate files
-3. Write the precompile code in Go with access to the EVM state
-4. Set the initial state in the configurator and register the precompile
-5. Add and run tests
-6. Build and run your customized EVM
-7. Connect Remix to your customized EVM and interact with the counter
-
-This tutorial will help you create more complex precompiles. Let's begin!
diff --git a/content/course/customizing-evm/10-stateful-counter-precompile/01-create-solidity-interface.mdx b/content/course/customizing-evm/10-stateful-counter-precompile/01-create-solidity-interface.mdx
deleted file mode 100644
index 05a55482..00000000
--- a/content/course/customizing-evm/10-stateful-counter-precompile/01-create-solidity-interface.mdx
+++ /dev/null
@@ -1,74 +0,0 @@
----
-title: Create Solidity Interface
-description: Learn how to create a solidity interface for your counter precompile.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-Now, we'll create a Solidity interface for our Stateful Precompile.
-
-## StringStore Solidity Interface
-
-To start, let's look at the interface of the **StringStore** precompile:
-
-```solidity title="contracts/contracts/interfaces/IStringStore.sol"
-// SPDX-License-Identifier: MIT
-
-pragma solidity >=0.8.0;
-
-interface IStringStore {
-    function getString() external view returns (string memory value);
-    function setString(string memory value) external;
-}
-```
-
-As seen above, we have the following two functions defined:
-
-1. `getString`: retreives the string from the stateful precompile
-2. `setString`: sets a string in the stateful precompile
-
-## Create Solidity Interface for Counter
-
-Create an interface for the counter in the same directory called `ICounter.sol`. Your interface should have the following three functions declared:
-
-1. `getCounter`: returns the counter value from the stateful precompile
-2. `incrementCounter`: when called, this function increments the current counter
-3. `setCounter`: takes in a value, and sets it as the counter of the stateful precompile
-
-For any argument/return value, make sure it is named as `value`.
-
-<Accordions>
-<Accordion title="Solution">
-
-```solidity
-// SPDX-License-Identifier: MIT
-
-pragma solidity >=0.8.0;
-
-interface ICounter {
-
-    function getCounter() external view returns (uint value);
-    function incrementCounter() external;
-    function setCounter(uint value) external;
-
-}
-```
-
-</Accordion>
-</Accordions>
-
-## Generate the ABI
-
-Now that we have an interface of our precompile, let's create an ABI of our Solidity interface. Open the terminal (control + \`), change to the `/contracts` directory, and run the command to compile the solidity interface to ABI:
-
-```bash
-# Move to contracts directory
-cd contracts
-
-# Compile ICounter.sol to ABI
-npx solc@latest --abi ./contracts/interfaces/ICounter.sol -o ./abis --base-path . --include-path ./node_modules
-
-# Rename 
-mv ./abis/contracts_interfaces_ICounter_sol_ICounter.abi ./abis/ICounter.abi
-```
diff --git a/content/course/customizing-evm/10-stateful-counter-precompile/02-store-data-in-evm.mdx b/content/course/customizing-evm/10-stateful-counter-precompile/02-store-data-in-evm.mdx
deleted file mode 100644
index 8ac8b987..00000000
--- a/content/course/customizing-evm/10-stateful-counter-precompile/02-store-data-in-evm.mdx
+++ /dev/null
@@ -1,142 +0,0 @@
----
-title: Store Data in EVM State
-description: Learn how to store data in the EVM state.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-Like all stateful machines, the EVM provides us with a way to save data. In particular, the EVM exposes a key-value mapping we can leverage to create stateful precompiles. The specifics of this mapping are as follows:
-
-- Key: a tuple consisting of an address and the storage key of the type Hash
-- Value: any data encoded in a Hash, also called a word in the EVM
-
-## Storage Slots
-
-Each storage slot is uniquely identified by the combination of an address and a storage key. To keep things organized, smart contracts and precompiles use their own address and a storage key to store data related to them. 
-
-Look at the reference implementation `StringStore`. The storage key is defined in the second variable group in `contract.go`:
-
-```go
-// Singleton StatefulPrecompiledContract and signatures.
-var (
-
-    // StringStoreRawABI contains the raw ABI of StringStore contract.
-    //go:embed contract.abi
-    StringStoreRawABI string
-
-    StringStoreABI = contract.ParseABI(StringStoreRawABI)
-
-    StringStorePrecompile = createStringStorePrecompile()
-
-    // Key that defines where our string will be stored
-    storageKeyHash = common.BytesToHash([]byte("storageKey"))
-)
-```
-
-We can use any string as our storage key. Then we convert it to a byte array and convert it to the hex representation.
-
-> The common.BytesToHash is not hashing the string, but converting it to a 32 byte array in hex representation.
-
-If we store multiple variables in the EVM state, we will define multiple keys here. Since we only use a single storage slot in this example, we can just call it `storageKey`.
-
-At this point, we are not restricted in what state we can access from the precompile. We have access to the entire `stateDB` and can modify the entire EVM state including data other precompiles saved to state or balances of accounts. **This is very powerful, but also potentially dangerous**.
-
-## Converting the Value to Hash Type
-
-Since the StateDB only stores data of the type *Hash*, we need to convert all values to the type *Hash* before passing it to the **stateDB**.
-
-### Converting Numbers
-
-To convert numbers of type `big.Int`, we can utilize a function from the common package:
-
-```go
-valueHash := common.BigToHash(value)
-```
-
-Since the `big.Int` data structure already is 32-bytes long, the conversion is straightforward.
-
-```go
-// BigToHash sets byte representation of b to hash.
-// If b is larger than len(h), b will be cropped from the left.
-func BigToHash(b *big.Int) Hash { return BytesToHash(b.Bytes()) }
-```
-
-### Converting Strings
-
-Converting strings is more challenging, since they are variable in length. Let's see an example:
-
-```go
-input := "Hello World"
-```
-
-To start, let's convert input into type bytes:
-
-```go
-inputAsBytes := []byte(input) 
-// [72 101 108 108 111 32 87 111 114 108 100]
-```
-
-This is how you would convert input to type bytes in Go. Notice that the comment in the code snippet is the byte-representation of input, where each integer represents a byte. Right now, inputAsBytes is of length 11. We want it to be of length 32. Therefore, we pad `inputAsBytes`, adding however many zeros to the front until `inputAsBytes` has 32 integers:
-
-```go
-inputPadded := common.LeftPadBytes(inputAsBytes, common.HashLength) 
-// [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 72 101 108 108 111 32 87 111 114 108 100]
-```
-
-In Go, we would do that using the function common.LeftPadBytes, which takes the byte array to be padded and the desired length. The desired length is supplied with the common.HashLength variable, which has the value 32. As seen in the comment, inputPadded is now of length 32. 
-
-In the next step, we convert the bytes to a Hash with the function `common.BytesToHash`:
-
-```go
-inputHash := common.BytesToHash(inputPadded) 
-// 0x00000000000000000000000000000000000000000048656c6c6f20576f726c64
-```
-
-## Helper Functions
-
-To make the code reusable and keep the precompile function clean, it makes sense to create helper functions for converting and storing the data. The first one we'll see is StoreString:
-
-```go
-// StoreString sets the value of the storage key "storageKey" in the contract storage.
-func StoreString(stateDB contract.StateDB, newValue string) {
-    newValuePadded := common.LeftPadBytes([]byte(newValue), common.HashLength)
-    newValueHash := common.BytesToHash(newValuePadded)
-    stateDB.SetState(ContractAddress, storageKeyHash, newValueHash)
-}
-```
-
-`StoreString` takes in the underlying key-value mapping, known as **StateDB**, and the new value, and updates the current string stored to be the new one. `StoreString` takes care of any type conversions and state management for us. Focusing now on `setString`, defining the logic is relatively easy. All we need to do is pass in **StateDB** and our string to `StoreString`.
-
-Thus, we have the following:
-
-```go
-func setString(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-    if remainingGas, err = contract.DeductGas(suppliedGas, SetStringGasCost); err != nil {
-        return nil, 0, err
-    }
-    if readOnly {
-        return nil, remainingGas, vmerrs.ErrWriteProtection
-    }
-    // attempts to unpack [input] into the arguments to the SetStringInput.
-    // Assumes that [input] does not include selector
-    // You can use unpacked [inputStruct] variable in your code
-    inputStruct, err := UnpackSetStringInput(input)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // CUSTOM CODE STARTS HERE
-    // Get K-V Mapping
-    currentState := accessibleState.GetStateDB()
-
-    // Set the value
-    StoreString(currentState, inputStruct)
-
-    // this function does not return an output, leave this one as is
-    packedOutput := []byte{}
-
-    // Return the packed output and the remaining gas
-    return packedOutput, remainingGas, nil
-}
-```
diff --git a/content/course/customizing-evm/10-stateful-counter-precompile/03-implement-set-counter.mdx b/content/course/customizing-evm/10-stateful-counter-precompile/03-implement-set-counter.mdx
deleted file mode 100644
index 84e1882c..00000000
--- a/content/course/customizing-evm/10-stateful-counter-precompile/03-implement-set-counter.mdx
+++ /dev/null
@@ -1,64 +0,0 @@
----
-title: Implementing setCounter
-description: Learn how to implement the setCounter method.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-Having seen how strings are stored in `StringStore`, its time for us to store integers with Counter. The thought process for this section can be defined as follows:
-
-- Define the storage hash for our counter
-- Implement `StoreCounterValue`, a helper function which acts like `StoreString` in the previous
-- Implement `setCounter`
-
-<Accordions>
-<Accordion title="Solution">
-
-```go title="contract.go"
-// storageKeyHash
-storageKeyHash = common.BytesToHash([]byte("counterValue"))
-
-// StoreGreeting sets the value of the storage key in the contract storage.
-func StoreCounterValue(stateDB contract.StateDB, value *big.Int) {
-	// Convert uint to left padded bytes
-	inputPadded := common.LeftPadBytes(value.Bytes(), 32)
-	inputHash := common.BytesToHash(inputPadded)
-
-	stateDB.SetState(ContractAddress, storageKeyHash, inputHash)
-}
-
-//setCounter sets the counter value in the contract storage.
-func setCounter(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-	if remainingGas, err = contract.DeductGas(suppliedGas, SetCounterGasCost); err != nil {
-		return nil, 0, err
-	}
-	if readOnly {
-		return nil, remainingGas, vmerrs.ErrWriteProtection
-	}
-	// attempts to unpack [input] into the arguments to the SetCounterInput.
-	// Assumes that [input] does not include selector
-	// You can use unpacked [inputStruct] variable in your code
-	inputStruct, err := UnpackSetCounterInput(input)
-	if err != nil {
-		return nil, remainingGas, err
-	}
-
-	// CUSTOM CODE STARTS HERE
-
-	// Get the current state
-	currentState := accessibleState.GetStateDB()
-
-	// Set the value
-	StoreCounterValue(currentState, inputStruct)
-
-	// this function does not return an output, leave this one as is
-	packedOutput := []byte{}
-
-	// Return the packed output and the remaining gas
-	return packedOutput, remainingGas, nil
-}
-```
-
-</Accordion>
-</Accordions>
\ No newline at end of file
diff --git a/content/course/customizing-evm/10-stateful-counter-precompile/04-read-date-from-evm.mdx b/content/course/customizing-evm/10-stateful-counter-precompile/04-read-date-from-evm.mdx
deleted file mode 100644
index 39c5f0c4..00000000
--- a/content/course/customizing-evm/10-stateful-counter-precompile/04-read-date-from-evm.mdx
+++ /dev/null
@@ -1,51 +0,0 @@
----
-title: Read Data From EVM State
-description: Learn how to read the data from EVM state.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-In the section about storing data in the EVM, we learned about how to store our string in the EVM State. An equally important skill is how to read data from the EVM state.
-
-In this section, we'll learn about how to retrieve our string from the EVM state.
-
-## Defining Helper Function
-
-Just like with setting the string in the EVM state, there are some conversions we'll have to perform to our string. In particular, we'll need to unhash the value stored in StateDB to get our original string. Thus, our helper function can be defined as follows:
-
-```go
-// GetString returns the value of the storage key "storageKey" in the contract storage,
-// with leading zeroes trimmed.
-func GetString(stateDB contract.StateDB) string {
-    // Get the value set at recipient
-    value := stateDB.GetState(ContractAddress, storageKeyHash)
-    return string(common.TrimLeftZeroes(value.Bytes()))
-}
-```
-
-With our helper function defined, we can implement the logic for `getString`. This will consists of retrieving the underlying key-value mapping and then passing it to `GetString`.
-
-```go
-func getString(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-    if remainingGas, err = contract.DeductGas(suppliedGas, GetStringGasCost); err != nil {
-        return nil, 0, err
-    }
-    // no input provided for this function
-
-    // CUSTOM CODE STARTS HERE
-
-    var output string // CUSTOM CODE FOR AN OUTPUT
-
-    currentState := accessibleState.GetStateDB()
-    output = GetString(currentState)
-
-    packedOutput, err := PackGetStringOutput(output)
-    if err != nil {
-        return nil, remainingGas, err
-    }
-
-    // Return the packed output and the remaining gas
-    return packedOutput, remainingGas, nil
-}
-```
\ No newline at end of file
diff --git a/content/course/customizing-evm/10-stateful-counter-precompile/05-implement-getcounter-increment.mdx b/content/course/customizing-evm/10-stateful-counter-precompile/05-implement-getcounter-increment.mdx
deleted file mode 100644
index 787ebe92..00000000
--- a/content/course/customizing-evm/10-stateful-counter-precompile/05-implement-getcounter-increment.mdx
+++ /dev/null
@@ -1,95 +0,0 @@
----
-title: Implementing getCounter & increment
-description: Learn how to implement getCounter and increment.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-Having seen how to retrieve strings from the EVM state with the StoreString precompile, we are now ready to implement `getCounter`. Also, now that we are familiar with reading and writing to the EVM state, we can implement increment, which requires both read and write operations.
-
-## Implementing getCounter
-
-For `getCounter`, the following thought process is helpful:
-
-- Create a helper function `GetCounterValue`, which takes in the current StateDB and returns the integer stored at the `storageKeyHash`
-- In `getCounter`, get the current StateDB and pass it to `GetCounterValue`
-
-<Accordions>
-<Accordion title="Solution">
-
-```go
-// GetCounterValue gets the value of the storage key in the contract storage.
-func GetCounterValue(stateDB contract.StateDB) *big.Int {
-	// Get the value
-	value := stateDB.GetState(ContractAddress, storageKeyHash)
-
-	// Convert bytes to uint
-	return new(big.Int).SetBytes(value.Bytes())
-}
-
-func getCounter(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-	if remainingGas, err = contract.DeductGas(suppliedGas, GetCounterGasCost); err != nil {
-		return nil, 0, err
-	}
-	// no input provided for this function
-
-	// Get the current state
-	currentState := accessibleState.GetStateDB()
-	// Get the value set at recipient
-	value := GetCounterValue(currentState)
-
-	packedOutput, err := PackGetCounterOutput(value)
-	if err != nil {
-		return nil, remainingGas, err
-	}
-
-	// Return the packed output and the remaining gas
-	return packedOutput, remainingGas, nil
-}
-```
-
-</Accordion>
-</Accordions>
-
-## Implementing increment
-
-For increment, the following thought process is helpful:
-
-- Get the current StateDB and pass it to GetCounterValue
-- Once you have the current counter, increment it by one
-- Store the new counter with StoreCounterValue
-
-<Accordions>
-<Accordion title="Solution">
-
-```go
-func incrementCounter(accessibleState contract.AccessibleState, caller common.Address, addr common.Address, input []byte, suppliedGas uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
-	if remainingGas, err = contract.DeductGas(suppliedGas, IncrementCounterGasCost); err != nil {
-		return nil, 0, err
-	}
-	if readOnly {
-		return nil, remainingGas, vmerrs.ErrWriteProtection
-	}
-	// no input provided for this function
-
-	// CUSTOM CODE STARTS HERE
-	// Get the current state
-	currentState := accessibleState.GetStateDB()
-
-	// Get the value of the counter
-	value := GetCounterValue(currentState)
-
-	// Set the value
-	StoreCounterValue(currentState, value.Add(value, big.NewInt(1)))
-
-	// this function does not return an output, leave this one as is
-	packedOutput := []byte{}
-
-	// Return the packed output and the remaining gas
-	return packedOutput, remainingGas, nil
-}
-```
-
-</Accordion>
-</Accordions>
\ No newline at end of file
diff --git a/content/course/customizing-evm/10-stateful-counter-precompile/06-setting-base-gasfees.mdx b/content/course/customizing-evm/10-stateful-counter-precompile/06-setting-base-gasfees.mdx
deleted file mode 100644
index f741f87a..00000000
--- a/content/course/customizing-evm/10-stateful-counter-precompile/06-setting-base-gasfees.mdx
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title: Setting Base Gas Fees of Your Precompile
-description: Learn how to set the base gas fees of your precompile.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-Gas is used for spam prevention. If our precompile is accessible to everyone on our Avalanche L1, it is important to set the gas cost in a way that lets users economically utilize it in their apps, yet prevents spammers from spamming our blockchain with calls to the precompile.
-
-In this section, we'll modify the default values of the gas costs of our Calculator precompile. By default, all user-defined functions have a gas cost of 1. While this is good news for the average user, allowing users to call computationally expensive functions can leave our blockchain vulnerable to Denial-of-Service (DoS) attacks. 
-
-We can find the default gas cost values for our functions in calculator/contract.go. Following the import statements, you should see:
-
-```go title-"calculator/contract.go"
-const (
-    // Gas costs for each function. These are set to 1 by default.
-    // You should set a gas cost for each function in your contract.
-    // Generally, you should not set gas costs very low as this may cause your network to be vulnerable to DoS attacks.
-    // There are some predefined gas costs in contract/utils.go that you can use.
-    AddGasCost     uint64 = 1 /* SET A GAS COST HERE */
-    NextTwoGasCost uint64 = 1 /* SET A GAS COST HERE */
-    RepeatGasCost  uint64 = 1 /* SET A GAS COST HERE */
-)
-```
-
-The variables `AddGasCost`, `NextTwoGasCost`, and `RepeatGasCost` are the gas costs of the `add`, `nextTwo`, and `repeat` functions, respectively. As you can see, they are currently set to 1.
-
-However, changing the gas cost is as easy as changing the values themselves. As an example, change the gas costs to 7.
diff --git a/content/course/customizing-evm/10-stateful-counter-precompile/07-set-configkey-contractaddr.mdx b/content/course/customizing-evm/10-stateful-counter-precompile/07-set-configkey-contractaddr.mdx
deleted file mode 100644
index 497b3994..00000000
--- a/content/course/customizing-evm/10-stateful-counter-precompile/07-set-configkey-contractaddr.mdx
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Setting ConfigKey and ContractAddress
-description: Learn how to set the ConfigKey and ContractAddress, and Register the Precompile.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-## ConfigKey
-
-Just as with the MD5 precompile in the previous section, go to the `module.go` file and set a ConfigKey.
-
-## Contract Address
-
-In the same file, set a ContractAddress. Choose one that has not been used by other precompiles of earlier sections.
\ No newline at end of file
diff --git a/content/course/customizing-evm/10-stateful-counter-precompile/08-initial-state.mdx b/content/course/customizing-evm/10-stateful-counter-precompile/08-initial-state.mdx
deleted file mode 100644
index 9d23a3b3..00000000
--- a/content/course/customizing-evm/10-stateful-counter-precompile/08-initial-state.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Initial State
-description: Setting the Initial State.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-Throughout this chapter, we've covered storing variables in the EVM state. However, all of this was through the use of StringStore/Counter Solidity interface. An important part of stateful precompiles is the ability to initialize values stored by our precompiled contracts.
-
-In the next few chapters, we'll see how to initialize the values of our precompiled contracts by manually setting the values or allowing for the values to be defined in the `genesis.json` file.
\ No newline at end of file
diff --git a/content/course/customizing-evm/10-stateful-counter-precompile/09-define-default-values-via-go.mdx b/content/course/customizing-evm/10-stateful-counter-precompile/09-define-default-values-via-go.mdx
deleted file mode 100644
index 17c8f1d2..00000000
--- a/content/course/customizing-evm/10-stateful-counter-precompile/09-define-default-values-via-go.mdx
+++ /dev/null
@@ -1,51 +0,0 @@
----
-title: Defining Default Values via Golang
-description: Learn how to set the default values of precompiled contracts using Go.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-In this section, we'll cover defining default values of precompiled contracts using Go. We'll refer to StringStore for this section.
-
-## Configure Function
-
-To start, go to `StringStore/module.go` and scroll to the end of the file. There, you will find the Configure function:
-
-```go
-// Configure configures [state] with the given [cfg] precompileconfig.
-// This function is called by the EVM once per precompile contract activation.
-// You can use this function to set up your precompile contract's initial state,
-// by using the [cfg] config and [state] stateDB.
-func (*configurator) Configure(chainConfig precompileconfig.ChainConfig, cfg precompileconfig.Config, state contract.StateDB, blockContext contract.ConfigurationBlockContext) error {
-    config, ok := cfg.(*Config)
-    if !ok {
-        return fmt.Errorf("incorrect config %T: %v", config, config)
-    }
-    // CUSTOM CODE STARTS HERE
-    return nil
-}
-```
-
-Configure handles the initialization of a precompiled contract. We want to use Configure to define the default value for the string we are storing. 
-
-But how? Configure gives us access to the StateDB (as one of the function parameters) and also lets us call any functions defined in `contract.go`. For example, if we wanted the default string to be "EGS," then we would just have to write one line of code:
-
-```go
-// Configure configures [state] with the given [cfg] precompileconfig.
-// This function is called by the EVM once per precompile contract activation.
-// You can use this function to set up your precompile contract's initial state,
-// by using the [cfg] config and [state] stateDB.
-func (*configurator) Configure(chainConfig precompileconfig.ChainConfig, cfg precompileconfig.Config, state contract.StateDB, blockContext contract.ConfigurationBlockContext) error {
-    config, ok := cfg.(*Config)
-    if !ok {
-        return fmt.Errorf("incorrect config %T: %v", config, config)
-    }
-    // CUSTOM CODE STARTS HERE
-    StoreString(state, "EGS")
-
-    return nil
-}
-```
-
-We have just set a default value for our precompiled contract.
\ No newline at end of file
diff --git a/content/course/customizing-evm/10-stateful-counter-precompile/10-define-default-values-via-genesis.mdx b/content/course/customizing-evm/10-stateful-counter-precompile/10-define-default-values-via-genesis.mdx
deleted file mode 100644
index 249ca950..00000000
--- a/content/course/customizing-evm/10-stateful-counter-precompile/10-define-default-values-via-genesis.mdx
+++ /dev/null
@@ -1,75 +0,0 @@
----
-title: Defining Default Values via Genesis
-description: Learn how to set the default values of precompiled contracts using genesis JSON file.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-In the last section, we saw how to initialize the default values of our precompiled contracts via the Configure function. While straightforward, it would be ideal for us (and developers who don't write in Go) to initialize default values via the genesis JSON. Here's how to do just that.
-
-## Modifying config.go
-
-The first step is to extract the value from the JSON file. Go to `config.go` and look at the Config struct:
-
-```go
-// Config implements the precompileconfig.Config interface and
-// adds specific configuration for StringStore.
-type Config struct {
-    precompileconfig.Upgrade
-    // CUSTOM CODE STARTS HERE
-    // Add your own custom fields for Config here
-}
-```
-
-Within the Config struct, we can find another struct: the Upgrade struct. It is not necessary to look at the definition of this struct. However, it is useful to know that this struct allows for the `blockTimestamp` key to be parsed in our `genesis.json` file. 
-
-```go
-"stringStoreConfig" : {
-    "blockTimestamp": 0,
-}
-```
-
-To pass in default values via the genesis JSON, we must complete the following:
-
-- Define a key-value in the genesis JSON
-- Update our Config struct so it is able to parse our new key-value
-
-In the case of StringStore, after defining blockTimestamp, we will add another key-pair for our default string:
-
-```go
-"stringStoreConfig" : {
-    "blockTimestamp": 0,
-    "defaultString": "EGS"
-}
-```
-
-Next, we will want to update our Config struct:
-
-```go
-type Config struct {
-    precompileconfig.Upgrade
-    // CUSTOM CODE STARTS HERE
-    // Add your own custom fields for Config here
-    DefaultString string `json:"defaultString,omitempty"`
-}
-```
-
-In the above snippet, we are defining a new field of type string named `DefaultString`. With respect to its initialization, the value of `DefaultString` is derived from the JSON key `defaultString` from our genesis JSON (the value `json:"defaultString,omitempty"` tells Go to ignore the JSON field if we do not define it in our genesis JSON).
-
-At this point, we have defined our new key-value pair in the genesis JSON and incorporated the logic so that precompile-evm can parse the new key-value.
-
-However, one step remains. Although precompile-evm can parse the new key-value, we are not actually utilizing it anywhere. Our last-step is to update `Configure` method in `module.go` so it can read our new key-value pair.
-
-```go
-func (*configurator) Configure(chainConfig contract.ChainConfig, cfg precompileconfig.Config, state contract.StateDB, _ contract.BlockContext) error {
-    config, ok := cfg.(*Config)
-    if !ok {
-        return fmt.Errorf("incorrect config %T: %v", config, config)
-    }
-    // CUSTOM CODE STARTS HERE
-    StoreString(state, config.DefaultString)
-
-    return nil
-}
-```
diff --git a/content/course/customizing-evm/10-stateful-counter-precompile/11-testing-precompile-hardhat.mdx b/content/course/customizing-evm/10-stateful-counter-precompile/11-testing-precompile-hardhat.mdx
deleted file mode 100644
index 40f071cf..00000000
--- a/content/course/customizing-evm/10-stateful-counter-precompile/11-testing-precompile-hardhat.mdx
+++ /dev/null
@@ -1,247 +0,0 @@
----
-title: Testing Your Precompile
-description: Learn how to test your precompile using Hardhat.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-Just like with the Calculator precompile, we want to test the functionality of our precompile to make sure it behaves as intended.
-
-Although we can write tests in Go, this is not the only way we can test our precompile. We can leverage Hardhat, a popular smart contract testing framework, for testing.
-
-In this section, we'll cover writing the smart contract component of our tests and setting up our testing environment so that precompile-evm can execute these tests for us.
-
-## Structure of Testing with Hardhat
-
-For `StringStore`, we'll need to complete the following tasks in order to leverage Hardhat:
-
-1. Define the Genesis JSON file we want to use for testing
-2. Tell precompile-evm what Hardhat script to use to test `StringStore` 
-3. Write the smart contract that will hold the test cases for us
-4. Write the actual script that will execute the Hardhat tests for us
-
-## Defining the Genesis JSON
-
-The easiest part of this tutorial, we will need to define the genesis state of our testing environment. For all intents and purposes, you can copy the genesis JSON that you used in the Defining Default Values section and paste it in `precompile-evm/tests/precompile/genesis`, naming it `StringStore.json` (it is important that you name the genesis file the name of your precompile).
-
-## Telling Precompile-EVM What To Test
-
-The next step is to modify `suites.go` and update the file so that precompile-evm can call the Hardhat tests for StringStore. Go to `precompile-evm/tests/precompile/solidity` and find `suites.go`. Currently, your file should look like the following:
-
-```go title="suites.go"
-// Copyright (C) 2019-2023, Ava Labs, Inc. All rights reserved.
-// See the file LICENSE for licensing terms.
-// Implements solidity tests.
-package solidity
-
-import (
-    "context"
-    "time"
-
-    "github.com/ava-labs/subnet-evm/tests/utils"
-    ginkgo "github.com/onsi/ginkgo/v2"
-)
-
-var _ = ginkgo.Describe("[Precompiles]", ginkgo.Ordered, func() {
-    utils.RegisterPingTest()
-    // Each ginkgo It node specifies the name of the genesis file (in ./tests/precompile/genesis/)
-    // to use to launch the subnet and the name of the TS test file to run on the subnet (in ./contract-examples/tests/)
-
-    // ADD YOUR PRECOMPILE HERE
-    /*
-        ginkgo.It("your precompile", ginkgo.Label("Precompile"), ginkgo.Label("YourPrecompile"), func() {
-            ctx, cancel := context.WithTimeout(context.Background(), time.Minute)
-            defer cancel()
-​
-            // Specify the name shared by the genesis file in ./tests/precompile/genesis/{your_precompile}.json
-            // and the test file in ./contracts/tests/{your_precompile}.ts
-            // If you want to use a different test command and genesis path than the defaults, you can
-            // use the utils.RunTestCMD. See utils.RunDefaultHardhatTests for an example.
-            utils.RunDefaultHardhatTests(ctx, "your_precompile")
-        })
-    */
-})
-```
-
-If you view the comments generated, you will already see a general structure for how we can declare our tests for precompiles. Let's take this template and use it to declare the tests for StringStore!
-
-```go title="suites.go"
-// Copyright (C) 2019-2023, Ava Labs, Inc. All rights reserved.
-// See the file LICENSE for licensing terms.
-// Implements solidity tests.
-package solidity
-
-import (
-    "context"
-    "time"
-
-    "github.com/ava-labs/subnet-evm/tests/utils"
-    ginkgo "github.com/onsi/ginkgo/v2"
-)
-
-var _ = ginkgo.Describe("[Precompiles]", ginkgo.Ordered, func() {
-    utils.RegisterPingTest()
-    // Each ginkgo It node specifies the name of the genesis file (in ./tests/precompile/genesis/)
-    // to use to launch the subnet and the name of the TS test file to run on the subnet (in ./contract-examples/tests/)
-
-    // ADD YOUR PRECOMPILE HERE
-    /*
-        ginkgo.It("your precompile", ginkgo.Label("Precompile"), ginkgo.Label("YourPrecompile"), func() {
-            ctx, cancel := context.WithTimeout(context.Background(), time.Minute)
-            defer cancel()
-​
-            // Specify the name shared by the genesis file in ./tests/precompile/genesis/{your_precompile}.json
-            // and the test file in ./contracts/tests/{your_precompile}.ts
-            // If you want to use a different test command and genesis path than the defaults, you can
-            // use the utils.RunTestCMD. See utils.RunDefaultHardhatTests for an example.
-            utils.RunDefaultHardhatTests(ctx, "your_precompile")
-        })
-    */
-
-    ginkgo.It("StringStore", ginkgo.Label("Precompile"), ginkgo.Label("StringStore"), func() {
-        ctx, cancel := context.WithTimeout(context.Background(), time.Minute)
-        defer cancel()
-
-        utils.RunDefaultHardhatTests(ctx, "StringStore")
-    })
-})
-```
-
-Again, the naming conventions are important. We recommend you use the same name as your precompile whenever possible.
-
-## Defining Test Contract
-
-In contrast to using just Go, Hardhat allows us to test our precompiles using Solidity.
-
-To start, create a new file called `StringStoreTest.sol` in `precompile-evm/contract/contracts`. We can start defining our file by including the following:
-
-```solidity title="StringStoreTest.sol"
-// SPDX-License-Identifier: MIT
-pragma solidity >= 0.8.0;
-
-import "ds-test/src/test.sol"; 
-import {IStringStore} from "../contracts/interfaces/IStringStore.sol";
-```
-
-As of right now, there are two important things to note.
-
-We are first importing `test.sol`, a testing file that includes a range of assertion functions to assert that our outputs are as expected. In particular, these assertion functions are methods of the DSTest contract.
-
-Next, we are importing the interface of the StringStore precompile that we want to test.
-
-With this in mind, let's fill in the rest of our test file:
-
-```solidity title="StringStoreTest.sol"
-contract StringStoreTest is DSTest {
-
-    IStringStore stringStore = IStringStore(0x0300000000000000000000000000000000000005);
-
-    function step_getString() public {
-        assertEq(stringStore.getString(), "Cornell");
-    }
-
-    function step_getSet() public {
-        string memory newStr = "Apple";
-        stringStore.setString(newStr);
-        assertEq(stringStore.getString(), newStr);
-    }
-}
-```
-
-In the contract `StringStoreTest`, we are inheriting the DSTest contract so that we can leverage the provided assertion functions. Afterward, we are declaring the variable stringStore so that we can directly call the StringStore precompile. Next, we have the two testing functions.
-
-Briefly looking at the logic of each test function:
-
-- `step_getString`: We are testing that the getString function returns the default string defined in the genesis JSON (in this example, the default string is set to "Cornell")
-- `step_getSet`: We are assigning a new string to our precompile and making sure that setString does so correctly
-
-We now want to note the following two details regarding Solidity test functions in Hardhat:
-
-- Any test functions that you want to be called must start with the prefix "step"
-- The assertion function you use to check your outputs is `assertEq`
-
-With our Solidity test contract defined, let's write actual Hardhat script! 
-
-## Writing Your Hardhat Script
-
-To start, go to `precompile-evm/contracts/test` and create a new file called `StringStore.ts`. It is important to name your TypeScript file the same name as your precompile. Here are the steps to take when defining our Hardhat script:
-
-1. Specify the address at which our precompile is located
-2. Deploy our testing contract so that we can call the test functions
-3. Tell Hardhat to execute said test functions
-
-To make our lives even easier, Avalanche L1-EVM (a library that Precompile-EVM leverages) has helper functions to call our test functions simply by specifying the names of the test functions. You can find the helper functions here: https://github.com/ava-labs/subnet-evm/blob/master/contracts/test/utils.ts.
-
-In the end, our testing file will look as follows:
-
-```ts title="StringStore.ts"
-// (c) 2019-2022, Ava Labs, Inc. All rights reserved.
-// See the file LICENSE for licensing terms.
-
-import { ethers } from "hardhat"
-import { test } from "@avalabs/subnet-evm-contracts"
-import { factory } from "typescript"
-
-const STRINGSTORE_ADDRESS = "0x0300000000000000000000000000000000000005"
-
-describe("StringStoreTest", function() {
-    this.timeout("30s")
-
-    beforeEach("Setup DS-Test", async function () {
-        const stringStorePromise = ethers.getContractAt("IStringStore", STRINGSTORE_ADDRESS)
-
-        return ethers.getContractFactory("StringStoreTest").then(factory => factory.deploy())
-        .then(contract => {
-          this.testContract = contract
-          return contract.deployed().then(() => contract)
-        })
-    })
-
-    test("Testing get function", "step_getString")
-
-    test("Testing get and set function", "step_getSet")
-})
-```
-
-## Running Your Hardhat Test
-
-To run your HardHat tests, first change to the root directory of precompile-evm and run the following command:
-
-```bash
-./scripts/build.sh
-```
-
-Afterward, run the following command:
-
-```bash
-GINKGO_LABEL_FILTER=StringStore ./scripts/run_ginkgo.sh
-```
-
-The variable `GINKGO_LABEL_FILTER` simply tells precompile-evm which tests suite from `suites.go` to execute. Execute the `StringStore` test suite.
-
-However, if you have multiple precompiles to test, set `GINKGO_LABEL_FILTER` equal to "Precompile." You should see something like the following:
-
-```bash title="Combined output"
-  StringStoreTest
-    ✓ Testing get function (4126ms)
-    ✓ Testing get and set function (4070ms)
-
-  2 passing (12s)
-
-  < Exit [It] StringStore - /Users/Rodrigo.Villar/go/src/github.com/ava-labs/precompile-evm/tests/precompile/solidity/suites.go:40 @ 07/19/23 15:37:03.574 (16.134s)
-• [16.134 seconds]
-------------------------------
-[AfterSuite] 
-/Users/Rodrigo.Villar/go/pkg/mod/github.com/ava-labs/subnet-evm@v0.5.2/tests/utils/command.go:85
-  > Enter [AfterSuite] TOP-LEVEL - /Users/Rodrigo.Villar/go/pkg/mod/github.com/ava-labs/subnet-evm@v0.5.2/tests/utils/command.go:85 @ 07/19/23 15:37:03.575
-  < Exit [AfterSuite] TOP-LEVEL - /Users/Rodrigo.Villar/go/pkg/mod/github.com/ava-labs/subnet-evm@v0.5.2/tests/utils/command.go:85 @ 07/19/23 15:37:03.575 (0s)
-[AfterSuite] PASSED [0.000 seconds]
-------------------------------
-
-Ran 2 of 3 Specs in 50.822 seconds
-SUCCESS! -- 2 Passed | 0 Failed | 0 Pending | 1 Skipped
-PASS
-```
-
-Congrats, you can now write Hardhat tests for your stateful precompiles!
diff --git a/content/course/customizing-evm/10-stateful-counter-precompile/12-build-your-precompile.mdx b/content/course/customizing-evm/10-stateful-counter-precompile/12-build-your-precompile.mdx
deleted file mode 100644
index f91f7467..00000000
--- a/content/course/customizing-evm/10-stateful-counter-precompile/12-build-your-precompile.mdx
+++ /dev/null
@@ -1,45 +0,0 @@
----
-title: Build Your Precompile
-description: Learn how to build and run your precompile as a custom EVM blockchain.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-## Build Your Custom VM
-
-There's a simple build script in the Precompile-EVM we can utilize to build. First, make sure you are in the root folder of you Precompile-EVM:
-
-```bash
-cd $GOPATH/src/github.com/ava-labs/precompile-evm
-```
-
-Then run the command to initiate the build script:
-
-```bash
-./scripts/build.sh
-```
-
-If you do not see any error, the build was successful.
-
-## Run a Local Network with Your Custom VM
-
-You can run you customized Precompile-EVM by using the Avalanche CLI.
-
-First, create the configuration for your blockchain with custom VM.
-
-```bash
-avalanche blockchain create myblockchain --custom --vm $AVALANCHEGO_PLUGIN_PATH/srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy --genesis ./.devcontainer/genesis-example.json
-```
-
-<Callout type="info">
-Make sure you replace the binary name with the actual binary name of your Precompile-EVM, and genesis file with the actual path to your genesis file.
-</Callout>
-
-Next, launch the Avalanche L1 with your custom VM:
-
-```bash
-avalanche subnet deploy myblockchain
-```
-
-After around 1 minute the blockchain should have been created and some more output should appear in the terminal. You'll also see the RPC URL of your blockchain in the terminal.
\ No newline at end of file
diff --git a/content/course/customizing-evm/index.mdx b/content/course/customizing-evm/index.mdx
deleted file mode 100644
index d84f9500..00000000
--- a/content/course/customizing-evm/index.mdx
+++ /dev/null
@@ -1,123 +0,0 @@
----
-title: Welcome to the Course
-description: Learn how to customize the Ethereum Virtual Machine.
-updated: 2024-09-27
-authors: [ashucoder9, owenwahlgren]
-icon: Smile
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-## Why take this Course?
-
-A significant innovation in blockchain is the development of multi-chain systems, such as Avalanche, which provide a significant improvement in scalability, interoperability, and flexibility. At the core of these multi-chain systems is the ability to run multiple blockchains powered by different virtual machines simultaneously. Each VM of a chain is optimized for specialized use cases, thereby boosting the network's overall performance.
-
-
-Configuring and modifying the EVM is an efficient way to create a specialized virtual machine, as it allows developers to build upon years of active community work and leverage the extensive ecosystem surrounding the EVM, including wallets, explorers, and development frameworks.
-## Course Content
-
-<Steps>
-<Step>
-
-### EVM Basics & Precompiles
-
-In the first section of the course we will go through some basic concepts of the EVM, such as the account-based model, keys, addresses, transactions, and blocks. Furthermore, we will explain what a precompile is and show you how to interact with a precompile on the Fuji testnet.
-</Step>
-<Step>
-### Development Environment Setup
-
-We will explore various ways to set up a development environment for building customized EVMs. You'll learn about GitHub Codespaces and Development Containers (`.devcontainer`). If you choose a local setup, you'll install a code editor, the Go language, configure your shell, and install additional dependencies.
-</Step>
-<Step>
-### Hands-On Exercises
-
-The following sections contain hands-on exercises where you customize the EVM. The difficulty of the customizations will increase from section to section. Find out more about each exercise by clicking its name below:
-
-<Accordions>
-    <Accordion title="Create your own EVM Blockchain">
-
-    - Learn how the Avalanche Network Runner Works
-    - Create a your own Avalanche Network
-    - Create an EVM Blockchain on your network 
-    - Connect Core Wallet to your blockchain
-
-    </Accordion>
-    <Accordion title="Customize the EVM with chainConfig">
-
-    - Learn what the genesis block is and how the data is structured
-    - Create a custom gas fee structure for your blockchain
-    - Define the initial token allocation at launch
-    - Configure pre-installed precompiles
-    - Create the blockchain and connect to it
-
-    </Accordion>
-    <Accordion title="Build a Hash Function Precompile">
-
-    Learn about the basic building blocks of a precompile by building a precompile for the md5 hash function:
-
-    - Generate boilerplate code for the precompile from a solidity interface
-    - Learn how to unpack inputs and pack outputs into 32 byte arrays
-    - Configure and register your md5 precompile
-    - Create a new blockchain, connect to it and interact with your precompile
-
-    </Accordion>
-    <Accordion title="Build a Calculator Precompile">
-
-    Learn to build more complex precompiles by building a calculator precompile and master the following skills in addition to the previous section:
-    
-    - Unpack multiple inputs and pack multiple outputs into 32 byte arrays
-    - Set a gas cost for your precompile
-    - Add go tests for your precompile
-
-    </Accordion>
-    <Accordion title="Build a Counter Stateful Precompile">
-
-    Learn to build stateful precompiles by building a counter precompile and master the following skills in addition to the previous sections:
-    
-    - Read from and write to the EVM state
-    - Define the initial state in the precompileConfig
-    - Add solidity tests for your precompile
-
-    </Accordion>
-    <Accordion title="Build a Permissioned Precompile (Coming Soon)">
-
-    Learn to build permissioned precompiles by building a XXX precompile and master the following skills in addition to the previous sections:
-    
-    - Add permissions to only allow certain addresses to interact with the precompile 
-    - Define the initial permissions in the precompileConfig
-    - Change the permissions on the fly
-
-    </Accordion>
-
-</Accordions>
-</Step>
-</Steps>
-
-## Prerequisites
-
-### Avalanche
-
-This course is intended for people with a solid understanding of the basic concepts of Avalanche. You should be familiar with these concepts:
-
-1. **Virtual Machines**: What they are and what VM customization means
-2. **Blockchains**: What the components are of a blockchain and how they interact, specifically how Avalanche L1s leverage precompiles.
-
-If some of this is not clear, I strongly recommend taking the [Avalanche Fundamentals](/course/avalanche-fundamentals) and [Multi-Chain Architecture](/course/multi-chain-architecture) courses first.
-
-### Coding
-
-You will need a general understanding of software development. You won't have to write a lot of code, but you will have to be able to understand some. Therefore, we recommend:
-
-1. **Solidity**: Basic knowledge, familiarity with types and interfaces. Familiarity with Foundry will help in advanced sections. 
-2. **Go**: You don't necessarily need to know Go, but should have some experience with an advanced object-oriented and typed language (C, C++, Java, Typescript)
-3. **Testing**: It will help you in later sections if you are generally familiar with the concept of unit testing
-
-## Learning Outcomes
-
-By the end of this course, students will be able to:
-
-- Understand what Precompiles are and when to use them.
-- Understand how developing precompiles allows developers to create more optimized and capable blockchain systems, enabling them to address entirely new use cases that were previously unattainable.
-- Apply the knowledge gained in the course by building multiple precompiles
-
-
-![](/wolfie/wolfie-hack.png)
diff --git a/content/course/customizing-evm/meta.json b/content/course/customizing-evm/meta.json
deleted file mode 100644
index e9f64d4d..00000000
--- a/content/course/customizing-evm/meta.json
+++ /dev/null
@@ -1,26 +0,0 @@
-{
-  "title": "customizing-evm",
-  "root": true,
-  "pages": [
-    "index",
-    "---Intro to EVM & Precompiles---",
-    "...02-intro-to-evm",
-    "---Development Environment Setup---",
-    "...03-development-env-setup",
-    "---Your Own EVM Blockchain---",
-    "...04-your-evm-blockchain",
-    "---Genesis Configuration---",
-    "...05-genesis-configuration",
-    "---Precompiles---",
-    "...06-precompiles",
-    "---Hash Function Precompile---",
-    "...07-hash-function-precompile",
-    "---Calculator Precompile---",
-    "...08-calculator-precompile",
-    "---Stateful Precompiles---",
-    "...09-stateful-precompiles",
-    "---Stateful Counter Precompile---",
-    "...10-stateful-counter-precompile"
-
-  ]
-}
diff --git a/content/course/hypersdk/01-hypersdk-starter-kit/01-hypersdk-starter-kit.mdx b/content/course/hypersdk/01-hypersdk-starter-kit/01-hypersdk-starter-kit.mdx
deleted file mode 100644
index 1c4cea7e..00000000
--- a/content/course/hypersdk/01-hypersdk-starter-kit/01-hypersdk-starter-kit.mdx
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: HyperSDK Starter Kit
-description: Learn how to set up the HyperSDK Starter Kit in a hosted environment on Github.
-updated: 2024-10-03
-authors: [martineckardt]
-icon: Book
----
-
-
-To make easier your journey through this course, we have prepared a HyperSDK Starter Kit [repo](https://github.com/ava-labs/hypersdk-starter-kit) consisting of everything you will need to start developing your own HyperSDK based virtual machine on Avalanche. This repo will provide a containerized environment with the following components:
-
-- Boilerplate VM based on MorpheusVM
-- Universal frontend
-- Metamask Snap wallet
-
-You can follow the course without the need of installing anything and you can just launch the environment in a Development Container.
-
-## Prerequisites
-- Docker (recent version)
-- Optional: Golang v1.22.5+
-- Optional: NodeJS v20+
-- Optional: [Metamask Flask](https://chromewebstore.google.com/detail/metamask-flask-developmen/ljfoeinjpaedjfecbmggjgodbgkmjkjk). Disable normal Metamask, Core wallet, and other wallets. Do not use your real private key with Flask.
diff --git a/content/course/hypersdk/01-hypersdk-starter-kit/02-set-up.mdx b/content/course/hypersdk/01-hypersdk-starter-kit/02-set-up.mdx
deleted file mode 100644
index 134d2770..00000000
--- a/content/course/hypersdk/01-hypersdk-starter-kit/02-set-up.mdx
+++ /dev/null
@@ -1,43 +0,0 @@
----
-title: Set Up
-description: Learn how to set up the HyperSDK Starter Kit in a hosted environment on Github.
-updated: 2024-10-03
-authors: [martineckardt]
-icon: Terminal
----
-
-import Link from 'next/link';
-import { cn } from '@/utils/cn';
-import { buttonVariants } from '@/components/ui/button.tsx'
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-The HyperSDK Starter Kit contains everything you need to get started quickly with the HyperSDK.
-
-In this course we will run the HyperSDK Starter Kit in a hosted environment on Github. This is the most quick way to get started. You can alternatively run the HyperSDK Starter Kit locally on your machine with docker and docker compose.
-
-<Steps>
-<Step>
-
-### Clone the HyperSDK Starter Kit Repo
-
-```bash
-git clone https://github.com/ava-labs/hypersdk-starter-kit.git
-```
-
-</Step>
-<Step>
-
-### Launch this example
-
-Open the terminal with `` Ctrl + ` ``. Now run the following command to start the devnet, faucet, and frontend:
-
-```bash
-docker compose up -d --build devnet faucet frontend
-```
-
-This may take 5 minutes to download dependencies.
-
-</Step>
-</Steps>
-
-You can wind everything down after the exercises with `docker compose down`.
\ No newline at end of file
diff --git a/content/course/hypersdk/01-hypersdk-starter-kit/03-explore-morpheusvm.mdx b/content/course/hypersdk/01-hypersdk-starter-kit/03-explore-morpheusvm.mdx
deleted file mode 100644
index 9bd460a6..00000000
--- a/content/course/hypersdk/01-hypersdk-starter-kit/03-explore-morpheusvm.mdx
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title: Explore MorpheusVM
-description: Learn how to set up the HyperSDK Starter Kit in a hosted environment on Github.
-updated: 2024-10-03
-authors: [martineckardt]
-icon: Terminal
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-The HyperSDK Starter Kit includes MorpheusVM, the simplest HyperSDK VM. It just implements a single action (Transfer) for moving funds and tracking balances.
-
-<Steps>
-<Step>
-
-## Connect Wallet
-
-Open http://localhost:5173 to see the frontend.
-
-![MorpheusVM Frontend](/common-images/hypersdk/frontend/frontend.png)
-
-We recommend using a Snap (requires [Metamask Flask](https://chromewebstore.google.com/detail/metamask-flask-developmen/ljfoeinjpaedjfecbmggjgodbgkmjkjk)) for the full experience, but a temporary wallet works too.
-
-</Step>
-<Step>
-
-## Execute a read-only action
-
-Actions can be executed on-chain (in a transaction) with results saved to a block, or off-chain (read-only). MorpheusVM has one action. Try executing it read-only. It shows expected balances of the sender and receiver. 
-
-![Execute Read Only Action](/common-images/hypersdk/frontend/execute-read-only-action.png)
-
-</Step>
-<Step>
-
-##  Issue a transaction
-
-Execute the Transfer action on-chain. This will move funds from the sender to the receiver. Click "Execute in transaction". All fields are pre-filled with default values.
-
-![Issue a Transaction](/common-images/hypersdk/frontend/issue-transaction.png)
-
-After the block ins finalized, the transaction appears in the right column. This column shows all non-empty blocks on the chain.
-
-</Step>
-<Step>
-
-## Check the Logs
-
-Logs are located inside the Docker container. To view them, you'll need to open a bash terminal inside the container and navigate to the folder with the current network:
-
-```bash
-docker exec -it devnet bash -c "cd /root/.tmpnet/networks/latest_morpheusvm-e2e-tests && bash"
-```
-
-This isn't the best developer experience, and we're working on improving it.
-
-</Step>
-</Steps>
-
diff --git a/content/course/hypersdk/02-concepts/01-concepts-of-hypersdk.mdx b/content/course/hypersdk/02-concepts/01-concepts-of-hypersdk.mdx
deleted file mode 100644
index 4c4932f7..00000000
--- a/content/course/hypersdk/02-concepts/01-concepts-of-hypersdk.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Concepts of HyperSDK
-description: Learn about the concepts of HyperSDK, the framework to build high-performance VMs on Avalanche.
-updated: 2024-10-03
-authors: [martineckardt]
-icon: Book
----
-
-The HyperSDK aims to provide good defaults, making it simple to build high performance blockchains, while enabling customization at each level of the stack. In this chapter we will explore some of these concepts.
-
-You can see the code snippets in this course, but you can also browse through the HyperSDK Starter Kit to see the code in the context of a full project.
\ No newline at end of file
diff --git a/content/course/hypersdk/02-concepts/02-actions.mdx b/content/course/hypersdk/02-concepts/02-actions.mdx
deleted file mode 100644
index eb5e399b..00000000
--- a/content/course/hypersdk/02-concepts/02-actions.mdx
+++ /dev/null
@@ -1,97 +0,0 @@
----
-title: Actions
-description: Learn about the concept of Actions of the HyperSDK.
-updated: 2024-10-03
-authors: [martineckardt]
-icon: BookOpen
----
-
-Actions represent the smallest unit of customization in the HyperSDK. Each action is packaged and signed within a transaction type defined by the HyperSDK, which allows developers to focus exclusively on their application logic.
-
-Actions implement the following `chain.Action` interface. It requires additional functions to provide state prefetching, pessimistic concurrency control, and multi-dimensional fees.
-
-```go
-ComputeUnits(Rules) uint64
-StateKeys(actor codec.Address) state.Keys
-GetTypeID() uint8
-ValidRange(Rules) (start int64, end int64)
-Execute(
-       ctx context.Context,
-       r Rules,
-       mu state.Mutable,
-       timestamp int64,
-       actor codec.Address,
-       actionID ids.ID,
-   ) (outputs [][]byte, err error)
-```
-
-## Fees and Pessimistic Concurrency Control
-StateKeys() provides a description of exactly how key-value pairs in the state will be manipulated during the action's execution. This method returns the set of keys and the set of permissions that are required to operate on them (ie. Read/Write/Allocate).
-
-For example, a Transfer action implements this method as:
-
-```go
-func (t *Transfer) StateKeys(actor codec.Address) state.Keys {
- return state.Keys{
-  string(storage.BalanceKey(actor)): state.Read | state.Write,
-  string(storage.BalanceKey(t.To)):  state.All,
- }
-}
-```
-
-This indicates that the actor's balance key can be read or written, but will not be allocated during execution. The To address may be read, written, or allocated, since transferring may allocate a new account in storage.
-
-`ComputeUnits()` returns a measure of the units of compute required to execute the action.
-
-These functions, along with the size of the action itself, determine the total amount of each resource (bandwidth, compute, read, write, and allocate) consumed by the action. The HyperSDK uses this information to calculate the fees required by the action.
-
-## Action Validity
-
-`GetTypeID()` returns a unique identifier of the action.
-
-`ValidRange()` returns the start and stop timestamp where the action is considered valid.
-
-## Action Execution
-
-Finally, each action implements an `Execute()` function, which performs the state transition described by the action.
-
-This is typically structured as follows:
-- Check the required invariants
-- If the invariants hold, update the state
-
-For the Transfer action it could be implemented as:
-
-- Verify the memo field is less than the maximum length
-- Check the sender has the required balance
-- Transfer the specified value from the sender to receiver
-
-```go
-func (t *Transfer) Execute(
-	ctx context.Context,
-	_ chain.Rules,
-	mu state.Mutable,
-	_ int64,
-	actor codec.Address,
-	_ ids.ID,
-) (codec.Typed, error) {
-	if t.Value == 0 {
-		return nil, ErrOutputValueZero
-	}
-	if len(t.Memo) > MaxMemoSize {
-		return nil, ErrOutputMemoTooLarge
-	}
-	senderBalance, err := storage.SubBalance(ctx, mu, actor, t.Value)
-	if err != nil {
-		return nil, err
-	}
-	receiverBalance, err := storage.AddBalance(ctx, mu, t.To, t.Value, true)
-	if err != nil {
-		return nil, err
-	}
-
-	return &TransferResult{
-		SenderBalance:   senderBalance,
-		ReceiverBalance: receiverBalance,
-	}, nil
-}
-```
diff --git a/content/course/hypersdk/02-concepts/03-storage.mdx b/content/course/hypersdk/02-concepts/03-storage.mdx
deleted file mode 100644
index f2ed79cc..00000000
--- a/content/course/hypersdk/02-concepts/03-storage.mdx
+++ /dev/null
@@ -1,209 +0,0 @@
----
-title: Storage
-description: Learn about the concept of Storage of the HyperSDK.
-updated: 2024-10-03
-authors: [martineckardt]
-icon: BookOpen
----
-
-The storage package provides higher level helper functions to define a state schema and interact directly with the key-value store. This package is not strictly necessary, but helps to better organize the code, so that actions can call higher level functions instead of directly interacting with the key-value store and state schema.
-
-## State Prefixes and State Keys
-
-Different types of data are stored in the key-value store with different prefixes. This helps to organize the data and makes it easier to query and manage the data.
-
-```go
-const (
-	// Active state
-	balancePrefix   = 0x0
-	heightPrefix    = 0x1
-	timestampPrefix = 0x2
-	feePrefix       = 0x3
-)
-```
-
-Single values that are stored the in the key-value store, the prefix and the state key are the same. For example, the height, timestamp, and fee exist only once in the state and therefore, their state key is equivalent to the prefix.
-
-```go
-var (
-	heightKey    = []byte{heightPrefix}
-	timestampKey = []byte{timestampPrefix}
-	feeKey       = []byte{feePrefix}
-)
-
-func HeightKey() (k []byte) {
-	return heightKey
-}
-
-func TimestampKey() (k []byte) {
-	return timestampKey
-}
-
-func FeeKey() (k []byte) {
-	return feeKey
-}
-```
-
-For objects that are stored multiple times, the state key is a combination of the prefix and the object's unique identifier. For example, there are multiple accounts (identified by their addresses) that each have a balance. Therefore, the state key is derived from the balance prefix and the address of the account.
-
-```go 
-// [balancePrefix] + [address]
-func BalanceKey(addr codec.Address) (k []byte) {
-	k = make([]byte, 1+codec.AddressLen+consts.Uint16Len)
-	k[0] = balancePrefix
-	copy(k[1:], addr[:])
-	binary.BigEndian.PutUint16(k[1+codec.AddressLen:], BalanceChunks)
-	return
-}
-```
-
-## Reading State
-
-Reading from state does not require changing the state, so it can be done on an immutable state.
-
-```go
-// If locked is 0, then account does not exist
-func GetBalance(
-	ctx context.Context,
-	im state.Immutable,
-	addr codec.Address,
-) (uint64, error) {
-	_, bal, _, err := getBalance(ctx, im, addr)
-	return bal, err
-}
-```
-
-First we need to get the state key for the balance we want to read. Then we can use the `GetValue` function to get the value from the key-value store. 
-
-```go
-func getBalance(
-	ctx context.Context,
-	im state.Immutable,
-	addr codec.Address,
-) ([]byte, uint64, bool, error) {
-	k := BalanceKey(addr)
-	bal, exists, err := innerGetBalance(im.GetValue(ctx, k))
-	return k, bal, exists, err
-}
-```
-
-Next we can check if the value has been found, parse the value from the key-value store and return it.
-
-```go
-func innerGetBalance(
-	v []byte,
-	err error,
-) (uint64, bool, error) {
-	if errors.Is(err, database.ErrNotFound) {
-		return 0, false, nil
-	}
-	if err != nil {
-		return 0, false, err
-	}
-	val, err := database.ParseUInt64(v)
-	if err != nil {
-		return 0, false, err
-	}
-	return val, true, nil
-}
-```
-
-## Writing State
-
-Writing to state requires changing the state, so it can only be done on a mutable state. Similar to when we read the state we need to determine the state key for the balance we want to write.
-
-```go
-func SetBalance(
-	ctx context.Context,
-	mu state.Mutable,
-	addr codec.Address,
-	balance uint64,
-) error {
-	k := BalanceKey(addr)
-	return setBalance(ctx, mu, k, balance)
-}
-```
-
-Then we can use the `Insert` function to write the value to the key-value store:
-
-```go
-func setBalance(
-	ctx context.Context,
-	mu state.Mutable,
-	key []byte,
-	balance uint64,
-) error {
-	return mu.Insert(ctx, key, binary.BigEndian.AppendUint64(nil, balance))
-}
-```
-
-### Adding and Subtracting Balances
-
-We can add more functions to the storage package to make it easier to interact with the key-value store. For example, we can add functions to add and subtract balances.
-
-If we wanted to make sure that an account exists before adding a balance, we can add a `create` parameter to the `AddBalance` function.
-
-```go
-func AddBalance(
-	ctx context.Context,
-	mu state.Mutable,
-	addr codec.Address,
-	amount uint64,
-	create bool,
-) (uint64, error) {
-	key, bal, exists, err := getBalance(ctx, mu, addr)
-	if err != nil {
-		return 0, err
-	}
-	// Don't add balance if account doesn't exist. This
-	// can be useful when processing fee refunds.
-	if !exists && !create {
-		return 0, nil
-	}
-	nbal, err := smath.Add(bal, amount)
-	if err != nil {
-		return 0, fmt.Errorf(
-			"%w: could not add balance (bal=%d, addr=%v, amount=%d)",
-			ErrInvalidBalance,
-			bal,
-			addr,
-			amount,
-		)
-	}
-	return nbal, setBalance(ctx, mu, key, nbal)
-}```
-
-When subtracting a balance, we should also check if the account exists and return an error if the balance would go below zero. Furthermore, if the balance would be zero after subtracting, we should delete the record to not store unnecessary data on disk instead of setting it to zero.
-
-```go
-func SubBalance(
-	ctx context.Context,
-	mu state.Mutable,
-	addr codec.Address,
-	amount uint64,
-) (uint64, error) {
-	key, bal, exists, err := getBalance(ctx, mu, addr)
-	if !exists {
-		return 0, ErrInvalidAddress
-	}
-	if err != nil {
-		return 0, err
-	}
-	nbal, err := smath.Sub(bal, amount)
-	if err != nil {
-		return 0, fmt.Errorf(
-			"%w: could not subtract balance (bal=%d, addr=%v, amount=%d)",
-			ErrInvalidBalance,
-			bal,
-			addr,
-			amount,
-		)
-	}
-	if nbal == 0 {
-		// If there is no balance left, we should delete the record instead of
-		// setting it to 0.
-		return 0, mu.Remove(ctx, key)
-	}
-	return nbal, setBalance(ctx, mu, key, nbal)
-}
-```
\ No newline at end of file
diff --git a/content/course/hypersdk/03-creating-actions/01-create-custom-action.mdx b/content/course/hypersdk/03-creating-actions/01-create-custom-action.mdx
deleted file mode 100644
index 945459cb..00000000
--- a/content/course/hypersdk/03-creating-actions/01-create-custom-action.mdx
+++ /dev/null
@@ -1,113 +0,0 @@
----
-title: Create Custom Action
-description: Learn how to create a custom action in Hyper SDK
-updated: 2024-10-03
-authors: [owenwahlgren]
-icon: Book
----
-
-## Add Your Own Custom Action
-
-Think of actions in HyperSDK like functions in EVMs. They have inputs, outputs, and execution logic.
-
-Let's add the Greeting action. This action doesn’t change anything; it simply prints your balance and the current date. However, if it's executed in a transaction, the output will be recorded in a block on the chain.
-
-
-### Create an Action File
-
-We will create a simple `Greeting` action that will greet the user with their name, the current date, and their balance. This action will not change the state of the chain, but it will read the user's balance.
-
-Place the following code in `actions/greeting.go`. The code includes some comments, but for more details, check out the [docs folder in HyperSDK](https://github.com/ava-labs/hypersdk/tree/main/docs).
-
-```go title="actions/greeting.go"
-package actions
-
-import (
-	"context"
-	"fmt"
-	"time"
-
-	"github.com/ava-labs/avalanchego/ids"
-
-	"github.com/ava-labs/hypersdk-starter/consts"
-	"github.com/ava-labs/hypersdk-starter/storage"
-	"github.com/ava-labs/hypersdk/chain"
-	"github.com/ava-labs/hypersdk/codec"
-	"github.com/ava-labs/hypersdk/state"
-	"github.com/ava-labs/hypersdk/utils"
-)
-
-// Please see chain.Action interface description for more information
-var _ chain.Action = (*Greeting)(nil)
-
-// Action struct. All "serialize" marked fields will be saved on chain
-type Greeting struct {
-	Name string `serialize:"true" json:"name"`
-}
-
-// TypeID, has to be unique across all actions
-func (*Greeting) GetTypeID() uint8 {
-	return consts.HiID
-}
-
-// All database keys that could be touched during execution.
-// Will fail if a key is missing or has wrong permissions
-func (g *Greeting) StateKeys(actor codec.Address) state.Keys {
-	return state.Keys{
-		string(storage.BalanceKey(actor)): state.Read,
-	}
-}
-
-// The "main" function of the action
-func (g *Greeting) Execute(
-	ctx context.Context,
-	_ chain.Rules,
-	mu state.Mutable, // That's how we read and write to the database
-	timestamp int64, // Timestamp of the block or the time of simulation
-	actor codec.Address, // Whoever signed the transaction, or a placeholder address in case of read-only action
-	_ ids.ID, // actionID
-) (codec.Typed, error) {
-	balance, err := storage.GetBalance(ctx, mu, actor)
-	if err != nil {
-		return nil, err
-	}
-	currentTime := time.Unix(timestamp/1000, 0).Format("January 2, 2006")
-	greeting := fmt.Sprintf(
-		"Hi, dear %s! Today, %s, your balance is %s %s.",
-		g.Name,
-		currentTime,
-		utils.FormatBalance(balance),
-		consts.Symbol,
-	)
-
-	return &GreetingResult{
-		Greeting: greeting,
-	}, nil
-}
-
-// How many compute units to charge for executing this action. Can be dynamic based on the action.
-func (*Greeting) ComputeUnits(chain.Rules) uint64 {
-	return 1
-}
-
-// ValidRange is the timestamp range (in ms) that this [Action] is considered valid.
-// -1 means no start/end
-func (*Greeting) ValidRange(chain.Rules) (int64, int64) {
-	return -1, -1
-}
-
-// Result of execution of greeting action
-type GreetingResult struct {
-	Greeting string `serialize:"true" json:"greeting"`
-}
-
-// Has to implement codec.Typed for on-chain serialization
-var _ codec.Typed = (*GreetingResult)(nil)
-
-// TypeID of the action result, could be the same as the action ID
-func (g *GreetingResult) GetTypeID() uint8 {
-	return consts.HiID
-}
-```
-
-Notice how the action requires state keys for the balance. This is because the action reads the balance from the database. The `Execute` function is where the action logic is defined. The `GreetingResult` struct is the output of the action.
diff --git a/content/course/hypersdk/03-creating-actions/02-register-action.mdx b/content/course/hypersdk/03-creating-actions/02-register-action.mdx
deleted file mode 100644
index 602401cf..00000000
--- a/content/course/hypersdk/03-creating-actions/02-register-action.mdx
+++ /dev/null
@@ -1,100 +0,0 @@
----
-title: Register Action with VM
-description: Learn how to register an action with the VM in Hyper SDK
-updated: 2024-10-03
-authors: [owenwahlgren]
-icon: Book
----
-
-### Register Your Action
-Now, you need to make both the VM and clients (via ABI) aware of this action.
-
-To do this, register your action in `vm/vm.go` after the line `ActionParser.Register(&actions.Transfer{}, nil)`:
-
-```go
-ActionParser.Register(&actions.Greeting{}, nil),
-```
-
-Then, register its output after the line `OutputParser.Register(&actions.TransferResult{}, nil)`:
-
-```go
-OutputParser.Register(&actions.GreetingResult{}, nil),
-```
-
-It should look like this when complete:
-```go title="vm/vm.go"
-// Copyright (C) 2024, Ava Labs, Inc. All rights reserved.
-// See the file LICENSE for licensing terms.
-
-package vm
-
-import (
-	"github.com/ava-labs/avalanchego/utils/wrappers"
-
-	"github.com/ava-labs/hypersdk-starter/actions"
-	"github.com/ava-labs/hypersdk-starter/consts"
-	"github.com/ava-labs/hypersdk-starter/storage"
-	"github.com/ava-labs/hypersdk/auth"
-	"github.com/ava-labs/hypersdk/chain"
-	"github.com/ava-labs/hypersdk/codec"
-	"github.com/ava-labs/hypersdk/genesis"
-	"github.com/ava-labs/hypersdk/vm"
-	"github.com/ava-labs/hypersdk/vm/defaultvm"
-)
-
-var (
-	ActionParser *codec.TypeParser[chain.Action]
-	AuthParser   *codec.TypeParser[chain.Auth]
-	OutputParser *codec.TypeParser[codec.Typed]
-)
-
-// Setup types
-func init() {
-	ActionParser = codec.NewTypeParser[chain.Action]()
-	AuthParser = codec.NewTypeParser[chain.Auth]()
-	OutputParser = codec.NewTypeParser[codec.Typed]()
-
-	errs := &wrappers.Errs{}
-	errs.Add(
-		// When registering new actions, ALWAYS make sure to append at the end.
-		// Pass nil as second argument if manual marshalling isn't needed (if in doubt, you probably don't)
-		ActionParser.Register(&actions.Transfer{}, nil),
-        ActionParser.Register(&actions.Greeting{}, nil), // [!code highlight]
-
-		// When registering new auth, ALWAYS make sure to append at the end.
-		AuthParser.Register(&auth.ED25519{}, auth.UnmarshalED25519),
-		AuthParser.Register(&auth.SECP256R1{}, auth.UnmarshalSECP256R1),
-		AuthParser.Register(&auth.BLS{}, auth.UnmarshalBLS),
-
-		OutputParser.Register(&actions.TransferResult{}, nil),
-        OutputParser.Register(&actions.GreetingResult{}, nil), // [!code highlight]
-
-	)
-	if errs.Errored() {
-		panic(errs.Err)
-	}
-}
-
-// NewWithOptions returns a VM with the specified options
-func New(options ...vm.Option) (*vm.VM, error) {
-	options = append(options, With()) // Add MorpheusVM API
-	return defaultvm.New(
-		consts.Version,
-		genesis.DefaultGenesisFactory{},
-		&storage.StateManager{},
-		ActionParser,
-		AuthParser,
-		OutputParser,
-		auth.Engines(),
-		options...,
-	)
-}
-```
-
-### Rebuild Your VM
-
-Rebuilding the docker container will update the VM with your new action.
-
-```bash
-docker compose down -t 1; docker compose up -d --build devnet faucet frontend
-```
\ No newline at end of file
diff --git a/content/course/hypersdk/03-creating-actions/03-test-action.mdx b/content/course/hypersdk/03-creating-actions/03-test-action.mdx
deleted file mode 100644
index 5f141599..00000000
--- a/content/course/hypersdk/03-creating-actions/03-test-action.mdx
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title: Test The Action
-description: Test your custom action in Hyper SDK through the frontend
-updated: 2024-10-03
-authors: [owenwahlgren]
-icon: Book
----
-
-### Test on Frontend
-HyperSDK uses ABI, an autogenerated description of all the actions in your VM. Thanks to this, the frontend already knows how to interact with your new action. Every action you add will be displayed on the frontend and supported by the wallet as soon as the node restarts.
-
-Now, enter your name and see the result:
-
-
-![MorpheusVM Frontend](/common-images/hypersdk/frontend/greeting.png)
-
-
-You can also send it as a transaction, but this doesn't make much sense since there’s nothing to write to the chain's state.
-
-
-### Next Steps
-Congrats! You've just created your first action for HyperSDK.
-
-This covers nearly half of what you need to build your own blockchain on HyperSDK. The remaining part is state management, which you can explore in `storage/storage.go`. Dive in and enjoy your journey!
\ No newline at end of file
diff --git a/content/course/hypersdk/index.mdx b/content/course/hypersdk/index.mdx
deleted file mode 100644
index 94ad7dfa..00000000
--- a/content/course/hypersdk/index.mdx
+++ /dev/null
@@ -1,52 +0,0 @@
----
-title: Welcome to the course
-description: Learn about HyperSDK, the framework to build high-performance VMs on Avalanche.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Smile
----
-
-HyperSDK is a high performance, customizable framework for building virtual machines for blockchains in the Avalanche network. The HyperSDK aims to provide good defaults, making it simple to build high performance blockchains, while enabling customization at each level of the stack.
-
-Many blockchains are powered by a single Virtual Machine (VM) that is optimized for general-purpose use cases, such as the EVM or a MoveVM. The application logic is implemented in smart contracts that run on top of the VM. While this approach allows anyone do deploy their application on the blockchain, this additional layer introduces inefficiencies and complexity.
-
-Multi-chain systems, like Avalanche, allow for the customization of the execution layer of the blockchain. They have the ability to run multiple blockchains with customized Virtual Machines. This gives developers the option to implement their application logic into the Virtual Machine itself. With that each blockchain's VM is optimized for specialized use cases and much more efficient that building on top of a general-purpose VM.
-
-## Why Take This Course?
-
-This course will teach you how to build a special-purpose VM utilizing the HyperSDK. It will enable you to build high-performance blockchain applications that wouldn't be possible with a general-purpose VM.
-
-## Course Content
-
-- **Introduction to HyperSDK:** Learn about the HyperSDK and its architecture.
-- **Creating Actions:** Learn how to create custom actions in HyperSDK.
-- **Registering Actions:** Learn how to register your custom actions with the VM.
-- **Testing Actions:** Learn how to test your custom actions in HyperSDK.
-- **State Management:** Learn how to manage state in HyperSDK.
-
-## Prerequisites
-
-### Avalanche
-This course is meant for people with a solid understanding of the basic concepts of Avalanche. You should be familiar with these concepts:
-
-- **Virtual Machines:** What they are and what VM customization means
-- **Avalanche L1s & Blockchains:** What the difference between a VM, Blockchain, and an Avalanche L1 is
-
-If any of this is unclear, we strongly recommend taking the Avalanche Fundamentals and Multi-Chain Architecture courses first.
-
-### Software Development
-
-You will need a general understanding of Software Development. You won't have to write a lot of code, but you will have to understand some. Therefore, we recommend:
-
-- **Golang:** Familiarity with most concepts of the language. All exercises will mainly consist of writing Golang code.
-- **Docker Compose:** The exercises of the course will occur in contained environments for easy setup. It will help if you're generally familiar with the concept of containerization, docker, and docker compose.
-- **Testing:** Having some experience or familiarity with unit testing is ideal.
-
-
-## Learning Outcomes
-
-By the end of this course, students will:
-
-- ...
-
-Overall, this course aims to provide an advanced understanding of HyperSDK. By completing this course, students will be better prepared to build advanced blockchain applications.
diff --git a/content/course/hypersdk/meta.json b/content/course/hypersdk/meta.json
deleted file mode 100644
index a8b82ae3..00000000
--- a/content/course/hypersdk/meta.json
+++ /dev/null
@@ -1,13 +0,0 @@
-{
-  "title": "HyperSDK",
-  "root": true,
-  "pages": [
-    "index",
-    "---HyperSDK Starter Kit---",
-    "...01-hypersdk-starter-kit",
-    "---Concepts---",
-    "...02-concepts",
-    "---Creating Actions---",
-    "...03-creating-actions"
-  ]
-} 
diff --git a/content/course/icm-chainlink/01-access-chainlink-vrf-services/01-introduction.mdx b/content/course/icm-chainlink/01-access-chainlink-vrf-services/01-introduction.mdx
deleted file mode 100644
index bdb76d1c..00000000
--- a/content/course/icm-chainlink/01-access-chainlink-vrf-services/01-introduction.mdx
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Introduction
-description: Learn how to use ICM to access Chainlink VRF services on L1 networks that do not have direct Chainlink support.
-updated: 2024-10-21
-authors: [0xstt]
-icon: Book
----
-
-As decentralized applications (dApps) expand across multiple blockchains, some Layer 1 (L1) networks lack direct support from essential services like **Chainlink VRF (Verifiable Random Functions)**. This presents a significant challenge for developers who rely on verifiable randomness for use cases such as gaming, lotteries, NFT minting, and other decentralized functions that require unbiased, unpredictable random numbers.
-
-The challenge arises because not every L1 network has integrated with Chainlink, meaning developers on those chains are left without native access to VRF services. Without verifiable randomness, critical aspects of dApps, such as fairness and security, can be compromised.
-
-### Why ICM is Necessary
-
-To address this gap, **Interchain Messaging (ICM)** provides a solution by allowing L1 networks that don’t have direct Chainlink support to still access these services. Through ICM, any blockchain can request VRF outputs from a Chainlink-supported network (e.g., Fuji) and receive the results securely on their own L1. 
-
-This cross-chain solution unlocks the ability to use Chainlink VRF on unsupported networks, bypassing the need for native integration and ensuring that dApp developers can continue building secure and fair decentralized applications.
-
-In the following sections, we will explore how to use ICM to access Chainlink VRF services across different chains by deploying two key smart contracts: one on the Chainlink-supported network and another on the target L1.
\ No newline at end of file
diff --git a/content/course/icm-chainlink/01-access-chainlink-vrf-services/02-understanding-the-flow.mdx b/content/course/icm-chainlink/01-access-chainlink-vrf-services/02-understanding-the-flow.mdx
deleted file mode 100644
index 91931691..00000000
--- a/content/course/icm-chainlink/01-access-chainlink-vrf-services/02-understanding-the-flow.mdx
+++ /dev/null
@@ -1,68 +0,0 @@
----
-title: Understanding the Flow
-description: Learn how requests for random words flow across chains using ICM.
-updated: 2024-10-21
-authors: [0xstt]
-icon: BookOpen
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-This section explains how random words are requested and fulfilled using Chainlink VRF across two different blockchains through **Interchain Messaging (ICM)**. The entire process involves several key components: the decentralized application (DApp), `CrossChainVRFConsumer`, `CrossChainVRFWrapper`, and `TeleporterMessenger`.
-
-Let’s walk through the flow step by step:
-
-<Steps>
-<Step>
-
-### DApp Submits Request for Random Words
-
-The DApp, running on an L1 without direct Chainlink support, initiates a request for verifiable randomness by interacting with the `CrossChainVRFConsumer` contract deployed on its chain.
-
-</Step>
-<Step>
-
-### `CrossChainVRFConsumer` Sends Cross-Chain Message
-
-Once the DApp submits the request, the `CrossChainVRFConsumer` prepares a message containing the necessary VRF request parameters (such as `keyHash`, `request confirmations`, `gas limit`, etc.). This message is sent across chains via the `TeleporterMessenger` to the `CrossChainVRFWrapper` on the Chainlink-supported network (e.g., Fuji).
-
-</Step>
-<Step>
-
-### `TeleporterMessenger` Receives Message & Calls `CrossChainVRFWrapper`
-1. On the Chainlink-supported network, the `TeleporterMessenger` receives the cross-chain message sent by the `CrossChainVRFConsumer`. It passes the message to the `CrossChainVRFWrapper`, which is authorized to handle VRF requests.
-2. The `CrossChainVRFWrapper` contract, deployed on the supported network, sends the request to **Chainlink VRF** for random words, using the parameters received in the message (e.g., `subscription ID`, `callback gas limit`, etc.).
-
-</Step>
-
-<Step>
-
-### Chainlink VRF Fulfills Random Words Request
-
-1. The **Chainlink VRF** fulfills the request and returns the random words to the `CrossChainVRFWrapper` contract by invoking its callback function.
-2. Once the random words are received, the `CrossChainVRFWrapper` encodes the fulfilled random words and sends them back as a cross-chain message to the `CrossChainVRFConsumer` on the original L1.
-
-</Step>
-
-<Step>
-
-### `TeleporterMessenger` Returns Random Words to `CrossChainVRFConsumer`
-   
-The `TeleporterMessenger` on the original L1 receives the message containing the random words and passes it to the `CrossChainVRFConsumer`.
-
-</Step>
-
-<Step>
-
-### `CrossChainVRFConsumer` Returns Random Words to the DApp
-
-Finally, the `CrossChainVRFConsumer` processes the random words and sends them to the DApp that originally requested them, completing the flow.
-
-</Step>
-
-</Steps>
-
-![](/course-images/interchain-messaging/cross-chain-vrf.png)
-
-This end-to-end process demonstrates how decentralized applications on unsupported L1 networks can request verifiable randomness from Chainlink VRF, leveraging **ICM** to handle cross-chain communication.
-
diff --git a/content/course/icm-chainlink/01-access-chainlink-vrf-services/03-orchestrating-vrf-requests.mdx b/content/course/icm-chainlink/01-access-chainlink-vrf-services/03-orchestrating-vrf-requests.mdx
deleted file mode 100644
index de93e2ec..00000000
--- a/content/course/icm-chainlink/01-access-chainlink-vrf-services/03-orchestrating-vrf-requests.mdx
+++ /dev/null
@@ -1,126 +0,0 @@
----
-title: Orchestrating VRF Requests Over Multiple Chains (Wrapper)
-description: Learn how the CrossChainVRFWrapper contract on a Chainlink-supported L1 handles cross-chain requests for VRF.
-updated: 2024-10-21
-authors: [0xstt]
-icon: BookOpen
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-The `CrossChainVRFWrapper` contract plays a critical role in handling requests for randomness from an unsupported L1. It is deployed on a **Chainlink-supported network** (like Avalanche Fuji) and serves as the intermediary that interacts with Chainlink VRF to request random words.
-
-Here’s how it functions as the provider for VRF services:
-
-## Receives Cross-Chain Messages
-
-<Steps>
-<Step>
-
-When the `CrossChainVRFConsumer` on the unsupported L1 initiates a request for randomness, it sends a cross-chain message via the `TeleporterMessenger` to the `CrossChainVRFWrapper` on the supported network.
-
-</Step>
-<Step>
-
-The `CrossChainVRFWrapper` verifies that the request came from an authorized address. This is essential to ensure that only verified consumers can request randomness.
-
-</Step>
-<Step>
-
-Upon receiving a valid request, the **VRFWrapper** calls **Chainlink VRF** and sends the request with the required parameters, such as the number of random words, request confirmations, and gas limits.
-
-</Step>
-<Step>
-
-The `CrossChainVRFWrapper` keeps track of all pending requests using a mapping, associating each request ID with its destination (the L1 where the `CrossChainVRFConsumer` resides). This ensures that the random words are returned to the correct destination once fulfilled.
-
-</Step>
-</Steps>
-
-<Accordions>
-<Accordion title="Implementation">
-```solidity
-function receiveTeleporterMessage(
-    bytes32 originChainID,
-    address originSenderAddress,
-    bytes calldata message
-) external {
-    require(msg.sender == address(teleporterMessenger), "Caller is not the TeleporterMessenger");
-    // Verify that the origin sender address is authorized
-    require(authorizedSubscriptions[originSenderAddress].isAuthorized, "Origin sender is not authorized");
-    uint256 subscriptionId = authorizedSubscriptions[originSenderAddress].subscriptionId;
-    // Verify that the subscription ID belongs to the correct owner
-    (,,,, address[] memory consumers) = s_vrfCoordinator.getSubscription(subscriptionId);
-    // Check wrapper contract is a consumer of the subscription
-    bool isConsumer = false;
-    for (uint256 i = 0; i < consumers.length; i++) {
-        if (consumers[i] == address(this)) {
-            isConsumer = true;
-            break;
-        }
-    }
-    require(isConsumer, "Contract is not a consumer of this subscription");
-    // Decode message to get the VRF parameters
-    CrossChainRequest memory vrfMessage = abi.decode(message, (CrossChainRequest));
-    // Request random words
-    VRFV2PlusClient.RandomWordsRequest memory req = VRFV2PlusClient.RandomWordsRequest({
-        keyHash: vrfMessage.keyHash,
-        subId: subscriptionId,
-        requestConfirmations: vrfMessage.requestConfirmations,
-        callbackGasLimit: vrfMessage.callbackGasLimit,
-        numWords: vrfMessage.numWords,
-        extraArgs: VRFV2PlusClient._argsToBytes(VRFV2PlusClient.ExtraArgsV1({nativePayment: vrfMessage.nativePayment}))
-    });
-    uint256 requestId = s_vrfCoordinator.requestRandomWords(req);
-    pendingRequests[requestId] = CrossChainReceiver({
-        destinationBlockchainId: originChainID,
-        destinationAddress: originSenderAddress
-    });
-}   
-```
-</Accordion>
-</Accordions>
-
-## Handles Callback from Chainlink VRF
-
-<Steps>
-<Step>
-
-When **Chainlink VRF** fulfills the randomness request, the `CrossChainVRFWrapper` receives the random words through a callback function. This ensures that the request has been successfully processed.
-
-</Step>
-<Step>
-
-After receiving the random words, the `CrossChainVRFWrapper` encodes the result and sends it back as a cross-chain message to the `CrossChainVRFConsumer` on the unsupported L1. This is done using the `TeleporterMessenger`.
-
-</Step>
-</Steps>
-
-<Accordions>
-<Accordion title="Implementation">
-```solidity
-function fulfillRandomWords(uint256 requestId, uint256[] calldata randomWords) internal override {
-    require(pendingRequests[requestId].destinationAddress != address(0), "Invalid request ID");
-    // Create CrossChainResponse struct
-    CrossChainResponse memory crossChainResponse = CrossChainResponse({
-        requestId: requestId,
-        randomWords: randomWords
-    });
-    bytes memory encodedMessage = abi.encode(crossChainResponse);
-    // Send cross chain message using ITeleporterMessenger interface
-    TeleporterMessageInput memory messageInput = TeleporterMessageInput({
-        destinationBlockchainID: pendingRequests[requestId].destinationBlockchainId,
-        destinationAddress: pendingRequests[requestId].destinationAddress,
-        feeInfo: TeleporterFeeInfo({ feeTokenAddress: address(0), amount: 0 }),
-        requiredGasLimit: 100000,
-        allowedRelayerAddresses: new address[](0),
-        message: encodedMessage
-    });
-    teleporterMessenger.sendCrossChainMessage(messageInput);
-    delete pendingRequests[requestId];
-}
-```
-</Accordion>
-</Accordions>
-
-In summary, the `CrossChainVRFWrapper` contract acts as the **bridge** between the unsupported L1 and Chainlink’s VRF services, ensuring that random words are requested, fulfilled, and delivered back across chains efficiently.
diff --git a/content/course/icm-chainlink/01-access-chainlink-vrf-services/04-bring-vrf-to-unsupported-l1.mdx b/content/course/icm-chainlink/01-access-chainlink-vrf-services/04-bring-vrf-to-unsupported-l1.mdx
deleted file mode 100644
index 0a0ee796..00000000
--- a/content/course/icm-chainlink/01-access-chainlink-vrf-services/04-bring-vrf-to-unsupported-l1.mdx
+++ /dev/null
@@ -1,101 +0,0 @@
----
-title: Bringing Chainlink VRF to Unsupported L1s (Consumer)
-description: Learn how to request VRF from an unsupported L1 using CrossChainVRFConsumer.
-updated: 2024-10-21
-authors: [0xstt]
-icon: BookOpen
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-The `CrossChainVRFConsumer` contract enables DApps on an unsupported L1 to request random words from Chainlink VRF using a cross-chain communication mechanism. Since Chainlink does not natively support all blockchains, this setup allows developers to access Chainlink's VRF service even on networks that don’t have direct support.
-
-<Steps>
-<Step>
-
-## Requesting Random Words
-
-The `CrossChainVRFConsumer` contract sends a cross-chain message to the `CrossChainVRFWrapper` on a Chainlink-supported L1, requesting random words. This request is sent using `TeleporterMessenger`, which handles cross-chain communication.
-
-<Accordions>
-<Accordion title="Implementation">
-```solidity
-function requestRandomWords(
-    bytes32 keyHash,
-    uint16 requestConfirmations,
-    uint32 callbackGasLimit,
-    uint32 numWords,
-    bool nativePayment,
-    uint32 requiredGasLimit
-) external {
-    // Create CrossChainRequest struct
-    CrossChainRequest memory crossChainRequest = CrossChainRequest({
-        keyHash: keyHash,
-        requestConfirmations: requestConfirmations,
-        callbackGasLimit: callbackGasLimit,
-        numWords: numWords,
-        nativePayment: nativePayment
-    });
-    // Send Teleporter message
-    bytes memory encodedMessage = abi.encode(crossChainRequest);
-    TeleporterMessageInput memory messageInput = TeleporterMessageInput({
-        destinationBlockchainID: DATASOURCE_BLOCKCHAIN_ID, 
-        destinationAddress: vrfRequesterContract,
-        feeInfo: TeleporterFeeInfo({ feeTokenAddress: address(0), amount: 0 }),
-        requiredGasLimit: requiredGasLimit,
-        allowedRelayerAddresses: new address[](0),
-        message: encodedMessage
-    });
-    teleporterMessenger.sendCrossChainMessage(messageInput);
-}
-```
-</Accordion>
-</Accordions>
-
-</Step>
-
-<Step>
-
-## Processing the Request
-Once the request is received by the `CrossChainVRFWrapper`, it interacts with the Chainlink VRF Coordinator to request the random words on behalf of the consumer on the unsupported L1.
-
-</Step>
-
-<Step>
-
-## Receiving Random Words
-
-Once Chainlink fulfills the request, the `CrossChainVRFWrapper` sends the random words back to the `CrossChainVRFConsumer` via a cross-chain message, enabling the DApp on the unsupported L1 to use them.
-
-<Accordions>
-<Accordion title="Implementation">
-```solidity
-function receiveTeleporterMessage(
-    bytes32 originChainID,
-    address originSenderAddress,
-    bytes calldata message
-) external {
-    require(originChainID == DATASOURCE_BLOCKCHAIN_ID, "Invalid originChainID");
-    require(msg.sender == address(teleporterMessenger), "Caller is not the TeleporterMessenger");
-    require(originSenderAddress == vrfRequesterContract, "Invalid sender");
-    
-    // Decode the message to get the request ID and random words
-    CrossChainResponse memory response = abi.decode(message, (CrossChainResponse));
-    
-    // Fulfill the request by calling the internal function
-    fulfillRandomWords(response.requestId, response.randomWords);
-}
-
-function fulfillRandomWords(uint256 requestId, uint256[] memory randomWords) internal {
-    // Logic to handle the fulfillment of random words
-    // Implement your custom logic here
-
-    // Emit event for received random words
-    emit RandomWordsReceived(requestId);
-}
-```
-</Accordion>
-</Accordions>
-
-</Step>
-</Steps>
diff --git a/content/course/icm-chainlink/01-access-chainlink-vrf-services/05-deploy-vrf-wrapper.mdx b/content/course/icm-chainlink/01-access-chainlink-vrf-services/05-deploy-vrf-wrapper.mdx
deleted file mode 100644
index 49f0f94a..00000000
--- a/content/course/icm-chainlink/01-access-chainlink-vrf-services/05-deploy-vrf-wrapper.mdx
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: Deploy Wrapper
-description: Learn how to deploy the CrossChainVRFWrapper contract to handle cross-chain VRF requests.
-updated: 2024-10-21
-authors: [0xstt]
-icon: Terminal
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-Once you have set up your Chainlink VRF subscription and have your LINK tokens ready, the next step is to deploy the **CrossChainVRFWrapper** contract. This contract will act as the bridge between your unsupported L1 and the Chainlink VRF network on a supported L1, enabling cross-chain requests for random words.
-
-<Steps>
-<Step>
-
-## Prerequisites
-Before deployment, make sure you have:
-- A valid **Chainlink VRF Subscription ID** (see previous section for details).
-- The `TeleporterMessenger` contract address on your supported L1 (e.g., Avalanche Fuji).
-</Step>
-<Step>
-
-## Deploy the Contract
-Using the `forge create` command, deploy the `CrossChainVRFWrapper` contract to the supported L1 (e.g., Avalanche Fuji).
-
-```bash
-forge create --rpc-url <RPC_URL> --private-key <PRIVATE_KEY> src/CrossChainVRFWrapper.sol:CrossChainVRFWrapper --constructor-args <TELEPORTER_MESSENGER_ADDRESS>
-```
-
-Replace the following:
-
-- `<RPC_URL>`: The RPC URL for the L1.
-- `<PRIVATE_KEY>`: The private key for the account used to deploy the contract.
-- `<TELEPORTER_MESSENGER_ADDRESS>`: The address of the deployed `TeleporterMessenger` contract.
-
-After deployment, save the `Deployed to` address in an environment variable for future use.
-
-```bash
-export VRF_WRAPPER=<address>
-```
-
-</Step>
-<Step>
-
-## Verify the Deployment
-After deploying the contract, verify that the `CrossChainVRFWrapper` has been successfully deployed by checking its address on a block explorer.
-
-</Step>
-<Step>
-
-## Configure Authorized Subscriptions
-Once deployed, the `CrossChainVRFWrapper` contract needs to be configured with authorized subscriptions to process requests for random words.
-
-- Call the `addAuthorizedAddress` function to authorize a specific address with a given subscription ID.
-- This ensures that only authorized addresses can request random words via the wrapper.
-
-```bash
-cast send --rpc-url <RPC_URL> --private-key <PRIVATE_KEY> $VRF_WRAPPER "addAuthorizedAddress(address caller, uint256 subscriptionId)" <CALLER_ADDRESS> <SUBSCRIPTION_ID>
-```
-
-Replace the following:
-
-- `<CALLER_ADDRESS>`: The address that will be authorized to request random words.
-- `<SUBSCRIPTION_ID>`: The ID of your Chainlink VRF subscription.
-</Step>
-</Steps>
\ No newline at end of file
diff --git a/content/course/icm-chainlink/01-access-chainlink-vrf-services/06-deploy-vrf-consumer.mdx b/content/course/icm-chainlink/01-access-chainlink-vrf-services/06-deploy-vrf-consumer.mdx
deleted file mode 100644
index 85e08f1f..00000000
--- a/content/course/icm-chainlink/01-access-chainlink-vrf-services/06-deploy-vrf-consumer.mdx
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: Deploy Consumer
-description: Learn how to deploy the CrossChainVRFConsumer contract on any L1 that does not support Chainlink VRF.
-updated: 2024-10-21
-authors: [0xstt]
-icon: Terminal
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-Now that the `CrossChainVRFWrapper` is deployed on a Chainlink-supported L1, it’s time to deploy the `CrossChainVRFConsumer` contract on the L1 where Chainlink VRF is not supported. This contract will handle requests for random words and interact with the **TeleporterMessenger** to communicate with the supported L1.
-
-<Steps>
-<Step>
-## Prerequisites
-Make sure you have:
-- The `TeleporterMessenger` contract address on the unsupported L1.
-- The deployed `CrossChainVRFWrapper` on the supported L1. `($VRF_WRAPPER)`
-</Step>
-<Step>
-## Deploy the Contract
-Use the following command to deploy the `CrossChainVRFConsumer` contract on your unsupported L1.
-
-```bash
-forge create --rpc-url <RPC_URL> --private-key <PRIVATE_KEY> src/CrossChainVRFConsumer.sol:CrossChainVRFConsumer --constructor-args <TELEPORTER_MESSENGER_ADDRESS> $VRF_WRAPPER
-```
-
-Replace the following:
-
-- `<RPC_URL>`: The RPC URL for the L1.
-- `<PRIVATE_KEY>`: The private key for the account used to deploy the contract.
-- `<TELEPORTER_MESSENGER_ADDRESS>`: The address of the `TeleporterMessenger` contract on your unsupported L1.
-
-After deployment, save the `Deployed to` address in an environment variable for future use.
-
-```bash
-export VRF_CONSUMER=<address>
-```
-</Step>
-<Step>
-## Verify the Deployment
-Once the `CrossChainVRFConsumer` contract is deployed, verify the contract’s address and confirm that it has been successfully deployed on your L1 using a block explorer.
-</Step>
-</Steps>
\ No newline at end of file
diff --git a/content/course/icm-chainlink/01-access-chainlink-vrf-services/07-create-vrf-subscription.mdx b/content/course/icm-chainlink/01-access-chainlink-vrf-services/07-create-vrf-subscription.mdx
deleted file mode 100644
index 5c525e60..00000000
--- a/content/course/icm-chainlink/01-access-chainlink-vrf-services/07-create-vrf-subscription.mdx
+++ /dev/null
@@ -1,63 +0,0 @@
----
-title: Create Chainlink VRF Subscription
-description: Learn how to create a Chainlink VRF subscription to enable cross-chain randomness requests.
-updated: 2024-10-21
-authors: [0xstt]
-icon: BookOpen
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-Before you can request random words using Chainlink VRF, you need to set up a **Chainlink VRF subscription**. This subscription allows you to fund requests for randomness and manage the list of consumers that are authorized to use the VRF service.
-
-<Steps>
-<Step>
-
-## Access Chainlink's VRF Subscription Manager
-
-To create a subscription, go to the Chainlink VRF Subscription Manager on the network where you plan to request VRF (e.g., Avalanche Fuji). You can access the manager here: [VRF | Subscription Management for Fuji](https://vrf.chain.link/fuji).
-![](/common-images/chainlink-vrf/visit-subscription-management.png)
-
-</Step>
-<Step>
-
-## Create a New Subscription
-
-Once on the subscription manager, create a new subscription. The subscription will have a unique ID, which you'll need to reference in your `CrossChainVRFWrapper` contract. This ID is used to track your random word requests and the balance associated with them.
-![](/common-images/chainlink-vrf/create-subscription.png)
-
-</Step>
-<Step>
-
-## Fund the Subscription
-
-After creating the subscription, you need to fund it with LINK tokens. These tokens are used to pay for the randomness requests made through Chainlink VRF. Make sure your subscription has enough funds to cover your requests.
-You can get testnet LINK tokens from the Fuji Faucet: [Chainlink Faucet for Fuji](https://faucets.chain.link/fuji)
-
-![](/common-images/chainlink-vrf/faucet.png)
-
-![](/common-images/chainlink-vrf/add-funds.png)
-
-</Step>
-<Step>
-
-## Add Consumers
-
-After funding your subscription, add the `CrossChainVRFWrapper` contract `($VRF_WRAPPER)` as a consumer. This step authorizes the contract to make randomness requests on behalf of your subscription. You can add other consumers, such as other contracts or addresses, depending on your use case.
-![](/common-images/chainlink-vrf/add-consumer.png)
-
-</Step>
-<Step>
-
-## Save Subscription ID
-
-After completing these steps, save your subscription ID. You will need this ID when configuring the `CrossChainVRFWrapper` contract to request random words.
-
-```bash
-export VRF_SUBSCRIPTION_ID=<subscription_id>
-```
-
-</Step>
-</Steps>
-
----
diff --git a/content/course/icm-chainlink/01-access-chainlink-vrf-services/08-request-random-words.mdx b/content/course/icm-chainlink/01-access-chainlink-vrf-services/08-request-random-words.mdx
deleted file mode 100644
index 17db2929..00000000
--- a/content/course/icm-chainlink/01-access-chainlink-vrf-services/08-request-random-words.mdx
+++ /dev/null
@@ -1,47 +0,0 @@
----
-title: Request Random Words
-description: Learn how to request random words using CrossChainVRFConsumer.
-updated: 2024-10-21
-authors: [0xstt]
-icon: Terminal
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-In this section, you will learn how to request random words from Chainlink VRF using both the `CrossChainVRFConsumer` contracts.
-
-<Steps>
-<Step>
-
-## Authorize an Address to Request Random Words
-
-After deploying the `CrossChainVRFWrapper` contract, the first step is to authorize an address to make requests for random words. This ensures that only specific addresses linked to a subscription can request VRF.
-
-- Use the `addAuthorizedAddress` function to authorize a specific address with a given subscription ID. This step allows the address to make random word requests through the wrapper.
-
-```bash
-cast send --rpc-url <RPC_URL> --private-key <PRIVATE_KEY> $VRF_WRAPPER "addAuthorizedAddress(address caller, uint256 subscriptionId)" $VRF_CONSUMER $VRF_SUBSCRIPTION_ID
-```
-
-</Step>
-<Step>
-
-## Request Random Words from `CrossChainVRFConsumer`
-
-Once the address is authorized, the next step is to send a request for random words from the `CrossChainVRFConsumer` contract on the unsupported L1. This request is then sent to the `CrossChainVRFWrapper` via a cross-chain message.
-
-```bash
-cast send --rpc-url <RPC_URL> --private-key <PRIVATE_KEY> $VRF_CONSUMER "requestRandomWords(bytes32 keyHash, uint16 requestConfirmations, uint32 callbackGasLimit, uint32 numWords, bool nativePayment, uint32 requiredGasLimit)" <KEY_HASH> <CONFIRMATIONS> <GAS_LIMIT> <NUM_WORDS> <NATIVE_PAYMENT> <REQUIRED_GAS_LIMIT>
-```
-
-Replace the placeholders with:
-
-- `<KEY_HASH>`: The VRF key hash used for random word generation.
-- `<CONFIRMATIONS>`: Number of confirmations required for the request.
-- `<GAS_LIMIT>`: The gas limit for the VRF callback function.
-- `<NUM_WORDS>`: The number of random words requested.
-- `<NATIVE_PAYMENT>`: Indicates whether the payment will be made in the native token.
-- `<REQUIRED_GAS_LIMIT>`: The gas limit required for the cross-chain message to be processed.
-
-</Step>
-</Steps>
\ No newline at end of file
diff --git a/content/course/icm-chainlink/02-access-chainlink-functions/01-introduction.mdx b/content/course/icm-chainlink/02-access-chainlink-functions/01-introduction.mdx
deleted file mode 100644
index 45e9a828..00000000
--- a/content/course/icm-chainlink/02-access-chainlink-functions/01-introduction.mdx
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: Introduction
-description: Learn how to use ICM to access Chainlink VRF services on L1 networks that do not have direct Chainlink support.
-updated: 2024-10-21
-authors: [Andrea]
-icon: Book
----
-
-TBD
\ No newline at end of file
diff --git a/content/course/icm-chainlink/03-access-chainlink-automation/01-introduction copy.mdx b/content/course/icm-chainlink/03-access-chainlink-automation/01-introduction copy.mdx
deleted file mode 100644
index 45e9a828..00000000
--- a/content/course/icm-chainlink/03-access-chainlink-automation/01-introduction copy.mdx	
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: Introduction
-description: Learn how to use ICM to access Chainlink VRF services on L1 networks that do not have direct Chainlink support.
-updated: 2024-10-21
-authors: [Andrea]
-icon: Book
----
-
-TBD
\ No newline at end of file
diff --git a/content/course/icm-chainlink/04-ccip-icm/01-introduction.mdx b/content/course/icm-chainlink/04-ccip-icm/01-introduction.mdx
deleted file mode 100644
index 45e9a828..00000000
--- a/content/course/icm-chainlink/04-ccip-icm/01-introduction.mdx
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: Introduction
-description: Learn how to use ICM to access Chainlink VRF services on L1 networks that do not have direct Chainlink support.
-updated: 2024-10-21
-authors: [Andrea]
-icon: Book
----
-
-TBD
\ No newline at end of file
diff --git a/content/course/icm-chainlink/certificate.mdx b/content/course/icm-chainlink/certificate.mdx
deleted file mode 100644
index c2c1726d..00000000
--- a/content/course/icm-chainlink/certificate.mdx
+++ /dev/null
@@ -1,14 +0,0 @@
----
-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/icm-chainlink/index.mdx b/content/course/icm-chainlink/index.mdx
deleted file mode 100644
index 9531d6ec..00000000
--- a/content/course/icm-chainlink/index.mdx
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: Welcome to the course
-description: Enable Chainlink services on L1 networks that do not have direct Chainlink support.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Smile
----
-
-In this course, you will learn how to integrate your own blockchain with the Chainlink services that are deployed on C-chain. To do this, we will use Avalanche Interchain Messaging and Chainlink VRF.
-
-## Why Take This Course?
-
-As the blockchain ecosystem grows, developers require robust tools to build secure, scalable, and innovative applications. Chainlink provides a suite of decentralized services, including VRF (Verifiable Random Function), Automation, Chainlink Functions, and CCIP (Cross-Chain Interoperability Protocol), to empower developers in creating high-performance, trustless applications. These services are not integrated by default on Avalanche L1 chains. However, Avalanche’s Interchain Messaging (ICM) enables developers to consume Chainlink services, typically available on the C-Chain, directly within their own L1 environments.
-
-This course equips you with the knowledge to integrate all Chainlink services into your Avalanche L1 blockchain. You will start with Chainlink VRF and progressively expand to advanced features like Automation for task scheduling, Functions for off-chain data computations, and CCIP for bridging data between Ethereum and Avalanche. We suggest you to revisit this course as we will keep on adding new content.
-
-## Course Content
-
-### Introduction
-
-Overview of Chainlink services and their role in decentralized applications. Importance of integrating these tools into Avalanche L1 chains.
-
-### Chainlink VRF
-
-Explanation of VRF and its use cases. Deploying VRF on Avalanche L1 and verifying randomness.
-
-### Chainlink Functions
-
-Overview of off-chain computation and API integrations. Implementing Functions for real-time data feeds.
-
-### Chainlink Automation
-
-Using Automation for task scheduling. Examples include automated smart contracts and dynamic pricing.
-
-### Chainlink CCIP
-
-Bridging data and assets between Ethereum and Avalanche L1. Practical applications such as cross-chain governance and token transfers.
-
-
-## Prerequisites
-
-Avalanche Interchain Messaging (ICM): A solid understanding of Avalanche’s ICM protocol is essential. You should have completed the ICM course, which covers:
-- The fundamentals of cross-chain communication in Avalanche
-- Message formats and flows
-- Security techniques for interchain messaging
-
-Blockchain and Development Knowledge
-- Solidity: Familiarity with the language’s key concepts, especially those related to smart contract interactions and randomness.
-- Oracles: While we will cover the basic components of Chainlink's VRF, having a sense of oracles is desirable.
-
-If any of this is unclear, we strongly recommend taking the Avalanche Interchain Messaging course first.
-
-## Learning Outcomes
-
-By the end of this course, students will:
-
-- Understand the mechanics of Chainlink VRF and other Chainlink Services and its significance in decentralized applications.
-- Gain proficiency in setting up Avalanche L1 chains with Chainlink services enabled.
-- Integrate Chainlink VRF with Avalanche ICM for secure cross-chain randomness.
-- Use Chainlink functions for Off-chain data integration with on-chain logic.
-- Automated smart contract operations
-- Cross-Chain communication with ecosystems outside Avalanche trough Chainlink's CCIP
-- Apply best practices to ensure reliability, security, and cost-efficiency in their applications.
-
-This course prepares developers to leverage Chainlink’s powerful suite of tools for building next-generation blockchain solutions on Avalanche L1.
diff --git a/content/course/icm-chainlink/meta.json b/content/course/icm-chainlink/meta.json
deleted file mode 100644
index e609621f..00000000
--- a/content/course/icm-chainlink/meta.json
+++ /dev/null
@@ -1,15 +0,0 @@
-{
-  "title": "Chainlink ICM",
-  "root": true,
-  "pages": [
-    "index",
-    "---Chainlink VRF on your L1---",
-    "...01-access-chainlink-vrf-services",
-    "---Chainlink Functions on your L1---",
-    "...02-access-chainlink-functions",
-    "---Chainlink Automation on your L1---",
-    "...03-access-chainlink-automation",
-    "---Chainlink CCIP and ICM---",
-    "...04-ccip-icm"
-  ]
-}
diff --git a/content/course/interchain-messaging/02-interoperability/01-interopability-between-blockchains.mdx b/content/course/interchain-messaging/02-interoperability/01-interopability-between-blockchains.mdx
deleted file mode 100644
index 49460440..00000000
--- a/content/course/interchain-messaging/02-interoperability/01-interopability-between-blockchains.mdx
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Interoperability between blockchain
-description: Learn about interoperability and it's importance in multichain systems
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
-
-<YouTube id="eLHOElbSw1k" />
-
-Interoperability between blockchains refers to the ability of different blockchain networks to communicate and interact with one another in a seamless and coordinated manner. It allows these separate blockchain systems to share data, assets, or functionalities, enabling them to work together as if they were part of a single unified network.
-
-These interactions can take many forms, including:
-
-- Asset Bridging (Tokens, NFTs, etc.)
-- DAO Voting across Chains
-- Cross-Chain Liquidity Pools
-
-As you will see soon, these different interactions are based on the same fundamentals of blockchains exchanging messages.
-
-## What you will learn
-
-In this section, you will explore the following topics:
-
-- **Source, Message, and Destination:** What is a message and what are the roles of the source and destination blockchain in interoperability?
-- **Multi-Chain Systems:** A quick recap of multi-chain systems
-- **Interoperability in Multi-Chain Systems:** Learn about the importance of interoperability to multi-chain systems
\ No newline at end of file
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
deleted file mode 100644
index 367faaaa..00000000
--- a/content/course/interchain-messaging/02-interoperability/02-source-message-destination.mdx
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: Source, Message and Destination
-description:  Learn about interoperability and it's importance in multichain systems.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-Interoperability is achieved by enabling blockchains to pass messages to one another. Each message originates from a source chain and is sent to one or more destination chains. These messages encode arbitrary data that can attest some event on the source chains, such as the deposit of an asset or the result of a vote.
-
-<div class="flex space-x-8">
-    <div class="flex-1">
-        ![](/common-images/teleporter/source.png)
-        # Source
-        - Origin of communication
-        - Sender calls contract
-    </div>
-    <div class="flex-1">
-        ![](/common-images/teleporter/message.png)
-        # Message
-        - Contains source, destination, and encoded data
-        - Signature guarantees  authenticity
-    </div>
-    <div class="flex-1">
-        ![](/common-images/teleporter/destination.png)
-        # Destination
-        - Submission of message as transaction
-        - Verifies signatures
-    </div>
-</div>
-
-## Source Chain
-
-The source chain in a cross-blockchain communication system refers to the original blockchain where data, assets, or information originate before being communicated to another blockchain. It acts as the starting point for initiating cross-chain interactions. When a user intends to communicate with another blockchain, they utilize protocols or smart contracts to initiate the communication process from the source chain.
-
-## Message
-
-The message is the data structure that will be sent to to the destination chain. It contains some metadata, the encoded message, and a signature. The signature attests the authenticity of the message, meaning that whatever the message claims has actually happened on the source 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.
-
-<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
deleted file mode 100644
index 02fd8d2e..00000000
--- a/content/course/interchain-messaging/02-interoperability/03-multi-chain-networks.mdx
+++ /dev/null
@@ -1,33 +0,0 @@
----
-title: Recap of Multi-Chain Networks
-description:  Learn about interoperability and it's importance in multichain systems
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-![](/common-images/multi-chain-architecture/subnets.png)
-
-Avalanche is a multi-chain network, meaning the network has multiple chains being validated in parallel, while other networks, such as Bitcoin and Ethereum only have single chain.
-
-This feature provides greater scalability, independence, and customizability. Each blockchain is optimized for specialized use cases, boosting the network's overall performance.
-
-## Transations per Second (TPS) and Time to Finality (TTF)
-
-To measure the performance of a blockchain, we can use two primary metrics: Time to finality (measured in seconds) and throughput (measured in transactions per second, TPS). To illustrate, we can think of a highway an as analogy.
-
-![](/common-images/consensus/tps-vs-ttf.png)
-
-Having a short time to finality is a short highway, taking a direct route from origin (submitting a transaction) to destination (finalization of the transaction) without any unnecessary detours. A finalized transaction is irreversibly written to the ledger. Once a transaction is final, users can be sure it has executed.
-
-Having high transaction throughput is like having many lanes on the highway, meaning many cars (transactions) can use it at the same time. When building blockchain systems, we want to achieve high throughput.
-
-## Scaling For The Masses
-
-Different blockchain networks use different scaling approaches, such as Layer 2s, including roll-ups. Networks aim to maximize the throughput. Multi-chain systems have a simple, but incredible effective way of scaling. By running independent chains in parallel, the overall network can reach a massive combined throughput.
-
-![](/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.
-
-<Quiz quizId="302"/>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/02-interoperability/04-interoperability-in-multi-chain-systems.mdx b/content/course/interchain-messaging/02-interoperability/04-interoperability-in-multi-chain-systems.mdx
deleted file mode 100644
index d94873d1..00000000
--- a/content/course/interchain-messaging/02-interoperability/04-interoperability-in-multi-chain-systems.mdx
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Interoperability in Multi-Chain Systems
-description:  Learn about interoperability and it's importance in multichain systems
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-Interoperability is crucial for multi-chain systems, as the price for easy scalability is fragmentation. However, this interoperability is equally important to all blockchain systems. Even though more dApps are based on the same chain in single-chain systems, many of them require interaction with other chains for liquidity or governance. Therefore, coming up with secure and efficient interoperability solutions is crucial for the entire blockchain space.
-
-![](/common-images/multi-chain-architecture/vm-variety.png)
-
-Avalanche, as a multi-chain system, provides flexibility on the execution and application layer but also offers a standardized messaging protocol. The necessary cryptographic algorithms are implemented in AvalancheGo, enabling cross-Avalanche L1 communication out of the box, even when the application and execution layers of the chains may be completely different. The VMs can utilize these modules to sign and verify messages, making interoperability between Avalanche L1s much easier than between unrelated chains from different networks.
\ No newline at end of file
diff --git a/content/course/interchain-messaging/02-interoperability/05-finality-and-interoperability.mdx b/content/course/interchain-messaging/02-interoperability/05-finality-and-interoperability.mdx
deleted file mode 100644
index 58a9c042..00000000
--- a/content/course/interchain-messaging/02-interoperability/05-finality-and-interoperability.mdx
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: Finality Importance in Interoperabile Systems
-description:  Learn about interoperability and it's importance in multichain systems
-updated: 2024-06-10
-authors: [andyvargtz]
-icon: BookOpen
----
-
-Finality is crucial for building cross-chain applications and interoperable systems because it ensures that transactions on the source chain are confirmed and immutable, therefore whatever action is triggered on the destination chain can securely be executed knowing the source chain won't revert the state induced by that cross chain message.
diff --git a/content/course/interchain-messaging/03-avalanche-starter-kit/01-avalanche-starter-kit.mdx b/content/course/interchain-messaging/03-avalanche-starter-kit/01-avalanche-starter-kit.mdx
deleted file mode 100644
index 76fa9b20..00000000
--- a/content/course/interchain-messaging/03-avalanche-starter-kit/01-avalanche-starter-kit.mdx
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Avalanche Starter Kit
-description: Environment Setup
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
-
-To make easier your journey through this course, we have prepared a Starter Kit repo consisting of everything you will need to start developing your own dApps on Avalanche. This repo will provide a self-contained environment with Avalanche-CLI, and Foundry so you can follow the course without the need of installing anything else other than launching the environment.
-
-## What You Will Learn
-
-In this section, you will go through the following topics:
-
-- How to launch your own Codespace
-- Create your own Interchain Messaging Enabled Custom Blockchain
-- Foundry configuration
-
-At the end of this section, you will have your environment ready to follow with the Cross-Chain dApp development with Interchain Messaging
\ No newline at end of file
diff --git a/content/course/interchain-messaging/03-avalanche-starter-kit/02-set-up.mdx b/content/course/interchain-messaging/03-avalanche-starter-kit/02-set-up.mdx
deleted file mode 100644
index df333867..00000000
--- a/content/course/interchain-messaging/03-avalanche-starter-kit/02-set-up.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Set Up Avalanche Starter Kit
-description: Environment Setup
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-import SetUp from "@/content/common/avalanche-starter-kit/set-up.mdx";
-
-<SetUp />
\ No newline at end of file
diff --git a/content/course/interchain-messaging/03-avalanche-starter-kit/03-close-and-reopen-codespace.mdx b/content/course/interchain-messaging/03-avalanche-starter-kit/03-close-and-reopen-codespace.mdx
deleted file mode 100644
index ffee101e..00000000
--- a/content/course/interchain-messaging/03-avalanche-starter-kit/03-close-and-reopen-codespace.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Close and Reopen Codespace
-description: Environment Setup
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-import CloseAndReopen from "@/content/common/codespaces/close-and-reopen-codespace.mdx";
-
-<CloseAndReopen />
\ No newline at end of file
diff --git a/content/course/interchain-messaging/03-avalanche-starter-kit/03-create-blockchain.mdx b/content/course/interchain-messaging/03-avalanche-starter-kit/03-create-blockchain.mdx
deleted file mode 100644
index 6e251d21..00000000
--- a/content/course/interchain-messaging/03-avalanche-starter-kit/03-create-blockchain.mdx
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Create a Blockchain
-description: Environment Setup
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-import CreateDefaultBlockchain from "@/content/common/avalanche-starter-kit/create-default-blockchain.mdx";
-
-In order to send messages between two chains, we need to create a blockchain. In this guide, we will spin up a local Avalanche network that has it's own Primary Network (C-, P- and X-Chain) using the Avalanche CLI. Furthermore, we will create a blockchain in that Avalanche network, so we can send messages between the C-Chain and the newly created blockchain in the next chapters.
-
-<CreateDefaultBlockchain/>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/03-avalanche-starter-kit/04-networks.mdx b/content/course/interchain-messaging/03-avalanche-starter-kit/04-networks.mdx
deleted file mode 100644
index b7f96423..00000000
--- a/content/course/interchain-messaging/03-avalanche-starter-kit/04-networks.mdx
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Networks
-description: Environment Setup
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-import Networks from "@/content/common/avalanche-starter-kit/networks.mdx";
-
-You just deployed and interacted with your first local network. But what does that mean? You can interact with your Avalanche L1, but you will notice that no one else can. Therefore, we have to understand what different Networks are in Avalanche.
-
-<Networks/>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/03-avalanche-starter-kit/05-foundry-quickstart.mdx b/content/course/interchain-messaging/03-avalanche-starter-kit/05-foundry-quickstart.mdx
deleted file mode 100644
index 86f6fcfe..00000000
--- a/content/course/interchain-messaging/03-avalanche-starter-kit/05-foundry-quickstart.mdx
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Foundry Quickstart
-description: Environment Setup
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-import FoundryQuickstart from "@/content/common/avalanche-starter-kit/foundry-quickstart.mdx";
-
-In this chapter, we will look into the Foundry that will be used to deploy and interact with smart contracts on the Avalanche network in our Avalanche Starter kit.
-
-<FoundryQuickstart/>
\ 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
deleted file mode 100644
index c734a718..00000000
--- a/content/course/interchain-messaging/03-avalanche-starter-kit/06-pause-and-resume.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-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/01-icm-basics.mdx b/content/course/interchain-messaging/04-icm-basics/01-icm-basics.mdx
deleted file mode 100644
index 7f8df439..00000000
--- a/content/course/interchain-messaging/04-icm-basics/01-icm-basics.mdx
+++ /dev/null
@@ -1,31 +0,0 @@
----
-title: ICM Basics
-description: Learn about the Avalanche Interchain Messaging basics.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
-
-<YouTube id="7QZ7_qZfQOA" />
-
-Teleporter enables you to send messages from one blockchain to another blockchain in the Avalanche network by simply calling the `sendCrossChainMessage` on the `TeleporterMessenger` contract. This invokes a smart contract on another Avalanche L1, where the called contract implements the `ITeleporterReceiver` interface to receive messages on the destination Avalanche L1. We will look at what happens under the hood in a later chapter.
-
-![](/common-images/teleporter/teleporter-source-destination.png)
-
-## What You Will Learn
-
-In this section, you will go through the following topics:
-
-- **Recap: Bytes, Encoding, and Decoding:** Understand how data is encoded and decoded in bytes
-- **Sending messages:** Write your first simple sender contract
-- **Receiving messages:** Write your first simple receiver contract
-
-## Exercise
-You will apply your learned knowledge by building your first Cross-Chain application! This application will be deployed on two chains: C-chain and your own Avalanche L1, both running on a Local Network.
-
-Therefore, you will deploy two contracts:
-
-- **Sender on Local C-Chain:** Send a message with a simple string
-- **Receiver on your Avalanche L1:** Receives the message and saves the most recent string
-
-At the end of the section, you will be adapting the example to build an 'Adder'. This application is similar to the example above, but the message will include a number. The receiving contract keeps track of the sum of all sent numbers. 
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
deleted file mode 100644
index 3b06b068..00000000
--- a/content/course/interchain-messaging/04-icm-basics/02-recap-bytes-encoding-decoding.mdx
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: Recap of Bytes, Encoding and Decoding
-description: Recap message encoding/decoding.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-When we send an interchain message, we are just sending a single value of type bytes. This value can contain multiple values of various types (e.g. string, uint & address) using encoding and decoding. 
-
-In this section we will recap these topics:
-
-- **Bytes:** What is this data type and why are we using it? 
-- **Encoding:** How do we turn values into bytes?
-- **Decoding:** How can we turn the bytes back into the values?
-
-We will use these concepts a lot going forward for our messages we send, so make sure you read this carefully.
-
-## Bytes
-In Solidity, the bytes data type serves as a versatile container for encoding multiple values of different types into a single unified value. You can think of it as a flexible box that can hold various forms of data, such as integers, text, images, or any binary information. The bytes data type allows you to mix and match these different types of data and put them all in one box.
-
-This makes it a pragmatic choice for encapsulating diverse data and data type ensures that all the data is efficiently packaged into a single unit for transfer, and recipients can decode and extract the individual components as needed.
-
-## Encoding & Decoding
-
-In Solidity we can use the functions `abi.encode()` and `abi.decode()` for encoding and decoding. These are part of the solidity language, so we do not need to import anything to use them.
-
-![Encoding and Decoding](/common-images/solidity/encoding-decoding.png)
-
-### Encoding
-When we encode data, we convert it into a byte array. This is useful when we want to send data from one contract to another. We can encode multiple values into a single byte array, which can then be decoded by the receiving contract.
-
-```solidity
-string memory someString = "test";
-uint someNumber = 42;
-
-bytes message = abi.encode(someString, someNumber);
-```
-
-This single value message here we can now use as a message for Teleporter.
-
-### Decoding
-When we decode data, we convert it from a byte array back into its original form. This is useful when we receive data from another contract. We can decode the byte array into its original values.
-
-```solidity
-( 
-  string memory someString,
-  uint someNumber
-) = 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.
-
-<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
deleted file mode 100644
index e2372964..00000000
--- a/content/course/interchain-messaging/04-icm-basics/03-sending-a-message.mdx
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: Sending a Message
-description: Learn to send messages with Avalanche Interchain Messaging.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-Sending a message is nothing more than a simple contract call to the Interchain Messaging messenger contract.
-
-<img src="/common-images/teleporter/teleporter-source.png" width="400" class="mx-auto"/>
-
-The dApp on the Source Subnet has to call the `sendCrossChainMessage` function of the Interchain Messaging contract. The Interchain Messaging contract implements the `ITeleporterMessenger` interface below. Note that the dApp itself does not have to implement the interface.
-
-```solidity title="/lib/teleporter/contracts/src/Teleporter/ITeleporterMessenger.sol"
-pragma solidity 0.8.18;
-
-struct TeleporterMessageInput {
-    bytes32 destinationBlockchainID;
-    address destinationAddress;
-    TeleporterFeeInfo feeInfo;
-    uint256 requiredGasLimit;
-    address[] allowedRelayerAddresses;
-    bytes message;
-}
-
-struct TeleporterFeeInfo {
-    address feeTokenAddress;
-    uint256 amount;
-}
-
-/**
- * @dev Interface that describes functionalities for a cross chain messenger.
- */
-interface ITeleporterMessenger {
-    /**
-     * @dev Emitted when sending a interchain message cross chain.
-     */
- 	event SendCrossChainMessage(
-        uint256 indexed messageID,
-        bytes32 indexed destinationBlockchainID,
-        TeleporterMessage message,
-        TeleporterFeeInfo feeInfo
-    );
-
-    /**
-     * @dev Called by transactions to initiate the sending of a cross subnet message.
-     */
-	function sendCrossChainMessage(TeleporterMessageInput calldata messageInput)
-        external
-        returns (uint256);
-
-}
-```
-
-The `sendCrossChainMessage` function takes `TeleporterMessageInput` struct as an input. In that multiple values are contained: This data will then be included in the payload of the Warp message:
-
-- **`destinationChainID`:** The chainID where the contract that should receive the message is deployed. This is not the EVM chain ID you may know from adding a network to a wallet, but the blockchain ID on the P-Chain. The P-Chain uses the transaction ID of the transaction that created those blockchain on the P-Chain for the chain ID, e.g.: 0xd7cdc6f08b167595d1577e24838113a88b1005b471a6c430d79c48b4c89cfc53
-- **`destinationAddress`:** The address of the contract that should receive the message
-- **`feeInfo`:** A struct consisting of a contract address of an ERC20 which the fee is paid in as well as the amount of tokens to be paid as an incentive for the relayer. We will look at this later in more detail.
-- **`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/04-create-sender-contract.mdx b/content/course/interchain-messaging/04-icm-basics/04-create-sender-contract.mdx
deleted file mode 100644
index 9eae8a11..00000000
--- a/content/course/interchain-messaging/04-icm-basics/04-create-sender-contract.mdx
+++ /dev/null
@@ -1,153 +0,0 @@
----
-title: Sender Contract
-description: Create a contract to send messages with Teleporter.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-Lets start by deploying our sender contract on C-Chain. It will be responsible for calling the the TeleporterMessenger contract, encoding our message and sending it to the destination chain. 
-
-<Steps>
-<Step>
-### Read the Sender Contract
-
-The following contract is located inside `contracts/interchain-messaging/send-receive` directory. Read through the contract below and and understand what is happening:
-
-```solidity title="contracts/interchain-messaging/send-receive/senderOnCChain.sol"
-// (c) 2023, Ava Labs, Inc. All rights reserved.
-// See the file LICENSE for licensing terms.
-
-// SPDX-License-Identifier: Ecosystem
-
-pragma solidity ^0.8.18;
-
-import "@teleporter/ITeleporterMessenger.sol"; // [!code highlight]
-
-contract SenderOnCChain {
-    ITeleporterMessenger public immutable messenger = ITeleporterMessenger(0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf); // [!code highlight]
-
-    /**
-     * @dev Sends a message to another chain.
-     */
-    function sendMessage(address destinationAddress, string calldata message) external {
-        messenger.sendCrossChainMessage( // [!code highlight]
-            TeleporterMessageInput({
-                // Replace with blockchainID of your Avalanche L1 (see instructions in Readme)
-                destinationBlockchainID: 0x3861e061737eaeb8d00f0514d210ad1062bfacdb4bd22d1d1f5ef876ae3a8921, // [!code highlight]
-                destinationAddress: destinationAddress, 
-                feeInfo: TeleporterFeeInfo({feeTokenAddress: address(0), amount: 0}),
-                requiredGasLimit: 100000,
-                allowedRelayerAddresses: new address[](0),
-                message: abi.encode(message)
-            })
-        );
-    }
-}
-```
-
-The key things to understand:
-
-- **Importing ITeleporterMessenger (Line 8):** We are importing the `ITeleporterMessenger` Interface we looked at in the previous activity.
-- **Defining teleporterMessenger contract (Line 12):** We are defining a `teleporterMessenger` contract using the imported interface. It is important to note, that our cross-chain dApp is not implementing the interface itself, but initializes a contract using that interface.
-- **Sending the message (Line 21):** We are sending the message by calling the function of our `teleporterMessenger`. As an input we are defining a `TeleporterMessageInput`. Make sure to replace the `destinationChainId` with the one of your Blockchain. We will need to provide the address of the receiving contract on the Avalanche L1 as a parameter to the function, since we have not deployed it yet and don't know the address at this time.   
-- **No fees (Line 25):** In this exercise we are not providing any fees to the relayer for relaying the message. This is only possible since the relayer we are running here is configured to pick up any message even if it does not provide any rewards.
-- **Encoding the Message (Line 31):** The `TeleporterMessageInput` defines a message as an array of bytes. For now we will just simply encode the string with `abi.encode()`. In the future activities, you will see how we can encode multiple values of any type in that message.
-
-</Step>
-<Step>
-
-### Get destinationBlockchainID
-
-To get the blockchainID on our Avalanche L1 let's use the Avalanche-CLI built in feature with the command:
-
-``` bash
-avalanche blockchain describe myblockchain
-```
-
-In the output you will find the blockchain details:
- 
-```
-+---------------------------------------------------------------------------------------------------------------+
-|                                                  MYBLOCKCHAIN                                                 |
-+---------------+-----------------------------------------------------------------------------------------------+
-| Name          | myblockchain                                                                                  |
-+---------------+-----------------------------------------------------------------------------------------------+
-| VM ID         | qDNV9vtxZYYNqm7TN1mYBuaaknLdefDbFK8bFmMLTJQJKaWjV                                             |
-+---------------+-----------------------------------------------------------------------------------------------+
-| VM Version    | v0.6.9                                                                                        |
-+---------------+--------------------------+--------------------------------------------------------------------+
-| Local Network | ChainID                  | 1                                                                  |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | SubnetID                 | 2AKbBT8jFUfUsUJ2hhRiDUnAAajJdNhTKeNgEe3q77spMj1N8F                 |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | Owners (Threhold=1)      | P-custom18jma8ppw3nhx5r4ap8clazz0dps7rv5u9xde7p                    |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | BlockchainID (CB58)      | krN11ZE6BNgenbX71Wu3YWv2SS5C3p9pD3WLkkRLVhuETGNJb                  |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | BlockchainID (HEX)       | 0x6391b85bafc78f1b10aec35695c2399c2fb7fff9f3b18ea903f77345e9e96e3e | // [!code highlight]
-+---------------+--------------------------+--------------------------------------------------------------------+
-```
-
-</Step>
-<Step>
-
-### Replace `destinationBlockchainID`
-
-Replace the destinationBlockchainID in `senderOnCChain.sol` with `BlockchainID (HEX)`
-
-```solidity
-contract SenderOnCChain {
-    ITeleporterMessenger public immutable messenger = ITeleporterMessenger(0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf);
-
-    /**
-     * @dev Sends a message to another chain.
-     */
-    function sendMessage(address destinationAddress, string calldata message) external {
-        messenger.sendCrossChainMessage(
-            TeleporterMessageInput({
-                // Replace with blockchainID of your Subnet (see instructions in Readme)
-                destinationBlockchainID: 0x6391b85bafc78f1b10aec35695c2399c2fb7fff9f3b18ea903f77345e9e96e3e, // [!code highlight]
-                destinationAddress: destinationAddress,
-                feeInfo: TeleporterFeeInfo({feeTokenAddress: address(0), amount: 0}),
-                requiredGasLimit: 100000,
-                allowedRelayerAddresses: new address[](0),
-                message: abi.encode(message)
-            })
-        );
-    }
-}
-```
-</Step>
-<Step>
-
-### Deploy Sender Contract
-
-To deploy a contract using Foundry use the following command:
-
-```bash
-forge create --rpc-url local-c --private-key $PK contracts/interchain-messaging/send-receive/senderOnCChain.sol:SenderOnCChain
-```
-```
-[⠊] Compiling...
-[⠒] Compiling 2 files with Solc 0.8.18
-[⠢] Solc 0.8.18 finished in 81.53ms
-Compiler run successful!
-Deployer: 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-Deployed to: 0x5DB9A7629912EBF95876228C24A848de0bfB43A9 // [!code highlight]
-Transaction hash: 0xcde7873e9e3c68fb00a2ad6644dceb64a01a41941da46de5a0f559d6d70a1638
-```
-</Step>
-<Step>
-
-### Save Sender Address
-
-Then save the sender contract address in an environment variable:
-
-```bash
-export SENDER_ADDRESS=0x5DB9A7629912EBF95876228C24A848de0bfB43A9
-```
-
-</Step>
-</Steps>
\ 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
deleted file mode 100644
index 4d624d6b..00000000
--- a/content/course/interchain-messaging/04-icm-basics/05-receiving-a-message.mdx
+++ /dev/null
@@ -1,93 +0,0 @@
----
-title: Receiving a Message
-description: Learn to receive messages with Avalanche Interchain Messaging.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-To receive a message we need to enable our cross-L1 dApps to being called by the Interchain Messaging contract.
-
-![](/course-images/teleporter/teleporter-source-destination-with-relayer.png)
-
-The Interchain Messaging does not know our contract and what functions it has. Therefore, our dApp on the destination Subnet has to implement the ITeleporterReceiver interface. It is very straight forward and only requires a single method for receiving the message that then can be called by the Interchain Messaging contract:
-
-```solidity
-pragma solidity 0.8.18;
-
-/**
- * @dev Interface that cross-chain applications must implement to receive messages from Teleporter.
- */
-interface ITeleporterReceiver {
-    /**
-     * @dev Called by TeleporterMessenger on the receiving chain.
-     *
-     * @param originChainID is provided by the TeleporterMessenger contract.
-     * @param originSenderAddress is provided by the TeleporterMessenger contract.
-     * @param message is the TeleporterMessage payload set by the sender.
-     */
-    function receiveTeleporterMessage(
-        bytes32 originChainID,
-        address originSenderAddress,
-        bytes calldata message
-    ) external;
-}
-```
-
-The function receiveTeleporterMessage has three parameters:
-
-- **`originChainID`**: The chainID where the message originates from, meaning where the user or contract called the `sendCrossChainMessage` function of the Interchain Messaging contract
-- **`originSenderAddress`**: The address of the user or contract that called the `sendCrossChainMessage` function of the Interchain Messaging contract on the origin Subnet
-- **`message`**: The message encoded in bytes
-
-An example for a contract being able to receive Interchain Messaging messages and storing these in a mapping could look like this:
-
-```solidity
-pragma solidity 0.8.18;
-
-import "https://github.com/ava-labs/teleporter/blob/main/contracts/src/Teleporter/ITeleporterMessenger.sol";
-import "https://github.com/ava-labs/teleporter/blob/main/contracts/src/Teleporter/ITeleporterReceiver.sol";
-
-contract MessageReceiver is ITeleporterReceiver {
-    // Messages sent to this contract.
-    struct Message {
-        address sender;
-        string message;
-    }
-  
-  	mapping(bytes32 => Message) private _messages;
-
-    ITeleporterMessenger public immutable teleporterMessenger;
-
-    // Errors
-    error Unauthorized();
-
-    constructor(address teleporterMessengerAddress) {
-        teleporterMessenger = ITeleporterMessenger(teleporterMessengerAddress);
-    }
-
-    /**
-     * @dev See {ITeleporterReceiver-receiveTeleporterMessage}.
-     *
-     * Receives a message from another chain.
-     */
-    function receiveTeleporterMessage(
-        bytes32 originChainID,
-        address originSenderAddress,
-        bytes calldata message
-    ) external {
-      	// Only the Interchain Messaging receiver can deliver a message.
-        if (msg.sender != address(teleporterMessenger)) {
-            revert Unauthorized();
-        }
-      
-        string memory messageString = abi.decode(message, (string));
-        _messages[originChainID] = Message(originSenderAddress, messageString);
-    }
-
-}
-```
-
-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/04-icm-basics/06-create-receiver-contract.mdx b/content/course/interchain-messaging/04-icm-basics/06-create-receiver-contract.mdx
deleted file mode 100644
index 0b26bcf4..00000000
--- a/content/course/interchain-messaging/04-icm-basics/06-create-receiver-contract.mdx
+++ /dev/null
@@ -1,84 +0,0 @@
----
-title: Receiver Contract
-description: Create a contract to receive messages with Teleporter.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-Now it's time to deploy our receiver contract to our L1. It will implement the callback for the `TeleporterMessenger` contract when the message is received, decoding our message and storing the last received string. 
-
-<Steps>
-<Step>
-
-### Read the Receiver Contract
-
-The following contract is located inside `contracts/interchain-messaging/send-receive` directory. Read through the contract below and and understand what is happening:
-
-```solidity title="contracts/interchain-messaging/send-receive/receiverOnSubnet.sol"
-// (c) 2023, Ava Labs, Inc. All rights reserved.
-// See the file LICENSE for licensing terms.
-
-// SPDX-License-Identifier: Ecosystem
-
-pragma solidity ^0.8.18;
-
-import "@teleporter/ITeleporterMessenger.sol";
-import "@teleporter/ITeleporterReceiver.sol";
-
-contract ReceiverOnSubnet is ITeleporterReceiver {
-    ITeleporterMessenger public immutable messenger = ITeleporterMessenger(0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf);
-
-    string public lastMessage;
-
-    function receiveTeleporterMessage(bytes32, address, bytes calldata message) external {
-        // Only the Interchain Messaging receiver can deliver a message.
-        require(msg.sender == address(messenger), "ReceiverOnSubnet: unauthorized TeleporterMessenger");
-
-        // Store the message.
-        lastMessage = abi.decode(message, (string));
-    }
-}
-```
-
-**The key things to understand:**
-- **Importing Interchain Messaging contracts (L8, L9):** We are importing the `ITeleporterMessenger` and `ITeleporterReceiver` interface we looked at in the previous activity.
-- **Inheriting from ITeleporterReceiver (L11):** We are inheriting the interface that will require us to implement the `receiveTeleporterMessage()` function.
-- **Defining the lastMessage variable (L14):** Setting the `lastMessage` variable as `public`, will make that variable readable from the outside without the need of a `getValue` function.
-- **Implementing receiveTeleporterMessage (L16):** We implement the function that will be called when the message is received. Please note that we are not checking who calls that function for now. So anyone can pretend to deliver messages for now.
-- **Decode message (L21):** We decode the message using `abi.decode(message, (string))`, which takes the bytes array as the first input and a tuple of the types of the encoded data in the message. Since our message only contains a single value, the tuple only has one value.
-
-</Step>
-<Step>
-
-### Deploy Receiver Contract
-
-To deploy a contract using Foundry use the following command:
-
-```bash
-forge create --rpc-url myblockchain --private-key $PK contracts/interchain-messaging/send-receive/receiverOnSubnet.sol:ReceiverOnSubnet
-```
-```
-[⠊] Compiling...
-[⠢] Compiling 2 files with Solc 0.8.18
-[⠆] Solc 0.8.18 finished in 158.51ms
-Compiler run successful!
-Deployer: 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-Deployed to: 0x52C84043CD9c865236f11d9Fc9F56aa003c1f922 // [!code highlight]
-Transaction hash: 0x48a1ffaa8aa8011f842147a908ff35a1ebfb75a5a07eb37ae96a4cc8d7feafd7
-```
-
-<Step>
-</Step>
-
-### Save Receiver Contract Address
-
-Then save the receiver contract address in an environment variable:
-
-```bash
-export RECEIVER_ADDRESS=0x52C84043CD9c865236f11d9Fc9F56aa003c1f922
-```
-
-</Step>
-</Steps>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/04-icm-basics/07-send-a-message.mdx b/content/course/interchain-messaging/04-icm-basics/07-send-a-message.mdx
deleted file mode 100644
index 7ea6a1cf..00000000
--- a/content/course/interchain-messaging/04-icm-basics/07-send-a-message.mdx
+++ /dev/null
@@ -1,40 +0,0 @@
----
-title: Send a Message
-description: Send your first Cross-Chain message with Teleporter.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-The final step, is to send the message between the two chains. Assuming everything went smooth so far, your local C-chain and your Avalanche L1 will have their corresponding parts of the sender/receiver deployed on them.
-
-<Steps>
-<Step>
-
-### Send a Message
-
-```bash
-cast send --rpc-url local-c --private-key $PK $SENDER_ADDRESS "sendMessage(address,string)" $RECEIVER_ADDRESS "Hello"
-```
-
-A relayer launched when you deployed the Avalanche L1 will now take the message and deliver it to the destination.
-
-</Step>
-<Step>
-
-### Verify Message was Received
-
-Now let's check if the "Hello" string sent from our C-chain was actually stored properly on the `lastMessage` variable on our Avalanche L1. Run the following command replacing the receiver contract address.
-
-```bash
-cast call --rpc-url myblockchain $RECEIVER_ADDRESS "lastMessage()(string)"
-```
-
-If the output says `Hello` then the message was successfully delivered and processed.
-
-</Step>
-</Steps>
-
-
-Congratulations 🎉 You have just sent your first cross-chain message. This will be one of many to come!
\ No newline at end of file
diff --git a/content/course/interchain-messaging/04-icm-basics/08-adapting-the-contract-exercise.mdx b/content/course/interchain-messaging/04-icm-basics/08-adapting-the-contract-exercise.mdx
deleted file mode 100644
index f2b7a68c..00000000
--- a/content/course/interchain-messaging/04-icm-basics/08-adapting-the-contract-exercise.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Adapt the contract
-description: Assignment- Modify the Cross-Chain Messenger.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-To create a deeper understanding of the concepts, now change the provided contracts. Instead of sending a string, now send a number and add up the numbers on the destination chain:
-
-Once you finished with the assignment you can review the correct answer at `/contracts/interchain-messaging/send-receive-assignment-solution` in the [Avalanche-Starter-Kit](https://github.com/ava-labs/avalanche-starter-kit)
diff --git a/content/course/interchain-messaging/05-two-way-communication/01-two-way-communication.mdx b/content/course/interchain-messaging/05-two-way-communication/01-two-way-communication.mdx
deleted file mode 100644
index 7608333b..00000000
--- a/content/course/interchain-messaging/05-two-way-communication/01-two-way-communication.mdx
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title: Two-Way Communication
-description: Learn about roundtrip messages.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
-
-When we send messages with Interchain Messaging, we can see check if a message has been delivered, but we do not get any feedback wether the message has been processed correctly or any return value. If we wanted to achieve this, we need to send a message back from the receiver to the original sender.
-
-![](/common-images/teleporter/two-way-communication.png)
-
-## What You Will Learn
-
-In this section, you will go through the following topics:
-
-- **Sender & Receiver:** Understand how we need to change the contracts to send a message back
-- **Send & Track:** Send a roundtrip message and follow the logs
-- **Adapt the example:** Take what you learned and adapt the example
-
-## Exercises
-You will apply your learned knowledge by building your first Cross-Chain application! This application will be deployed on two chains: C-Chain and your own Avalanche L1, both running on a Local Network.
-
-Therefore, you will deploy two contracts:
-
-- **Sender on Local C-Chain:** Send a message with a simple string
-- **Receiver on your Avalanche L1:** Receives the message, adds something to the string and send it back
-
-At the end of the section, you will be adapting the example to build a cross-chain Avalanche L1 dApp that send a number to a contract on another Avalanche L1 then receives the result of a mathematical operation. This application is similar to the example above, but the message will include a number. The receiving contract will perform a mathematical operation. 
\ No newline at end of file
diff --git a/content/course/interchain-messaging/05-two-way-communication/02-sender-contract.mdx b/content/course/interchain-messaging/05-two-way-communication/02-sender-contract.mdx
deleted file mode 100644
index 8b148a3b..00000000
--- a/content/course/interchain-messaging/05-two-way-communication/02-sender-contract.mdx
+++ /dev/null
@@ -1,57 +0,0 @@
----
-title: Sender Contract
-description: Adapt the sender contract to also receive messages
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-The sender contract has now two tasks: 
-
-- **Send a message to the receiver**: Same as in the last example
-- **Receive a message back from the receiver**: Now our sender contract needs to be able to receive a message back from the receiver.
-
-Therefore, we need to change the sender contract to be able to receive a message back. We will need to implement the same interface `ITeleporterReceiver` as the receiver contract and implement the `receiveTeleporterMessage` function. 
-
-```solidity title="contracts/interchain-messaging/send-roundtrip/senderOnCChain.sol"
-// (c) 2023, Ava Labs, Inc. All rights reserved.
-// See the file LICENSE for licensing terms.
-
-// SPDX-License-Identifier: Ecosystem
-
-pragma solidity ^0.8.18;
-
-import "@teleporter/ITeleporterMessenger.sol";
-import "@teleporter/ITeleporterReceiver.sol"; // [!code highlight]
-
-contract SenderOnCChain is ITeleporterReceiver { // [!code highlight]
-    ITeleporterMessenger public immutable messenger = ITeleporterMessenger(0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf);
-
-    string public rountripMessage;
-
-    /**
-     * @dev Sends a message to another chain.
-     */
-    function sendMessage(address destinationAddress) external {
-        messenger.sendCrossChainMessage(
-            TeleporterMessageInput({
-                // Replace with blockchainID of your Avalanche L1 (see instructions in Readme)
-                destinationBlockchainID: 0xb72b346fcc8c1ebb30087e2d2841eac9302dde8fc5969dcc84fad6db5ebd261d,
-                destinationAddress: destinationAddress,
-                feeInfo: TeleporterFeeInfo({feeTokenAddress: address(0), amount: 0}),
-                requiredGasLimit: 100000,
-                allowedRelayerAddresses: new address[](0),
-                message: abi.encode("Hello")
-            })
-        );
-    }
-
-    function receiveTeleporterMessage(bytes32, address, bytes calldata message) external { // [!code highlight:7]
-        // Only the Interchain Messaging receiver can deliver a message.
-        require(msg.sender == address(messenger), "SenderOnCChain: unauthorized TeleporterMessenger");
-
-        // Store the message.
-        rountripMessage = abi.decode(message, (string));
-    }
-}
-```
\ No newline at end of file
diff --git a/content/course/interchain-messaging/05-two-way-communication/03-create-sender-contract.mdx b/content/course/interchain-messaging/05-two-way-communication/03-create-sender-contract.mdx
deleted file mode 100644
index a84fdacb..00000000
--- a/content/course/interchain-messaging/05-two-way-communication/03-create-sender-contract.mdx
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: Create the Sender Contract
-description: Deploy roundtrip sender contract
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-Go ahead and deploy the sender contract on the C-Chain. 
-
-<Steps>
-<Step>
-
-### Adapt the Sender Contract
-
-Perform the changes on `senderOnCChain.sol` described in the [previous section.](/course/interchain-messaging/04-icm-basics/04-create-sender-contract)
-
-<Callout type="warn" title="Don't forget to replace the destinationBlockchainID with the Blockchain ID (HEX) from your Avalanche L1!" />
-
-</Step>
-<Step>
-
-### Deploy the Sender Contract
-
-```bash
-forge create --rpc-url local-c --private-key $PK contracts/interchain-messaging/send-roundtrip/senderOnCChain.sol:SenderOnCChain
-```
-```
-[⠊] Compiling...
-[⠢] Compiling 1 files with Solc 0.8.18
-[⠆] Solc 0.8.18 finished in 165.79ms
-Compiler run successful!
-Deployer: 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-Deployed to: 0xA4cD3b0Eb6E5Ab5d8CE4065BcCD70040ADAB1F00 // [!code highlight]
-Transaction hash: 0x4f41cf829fbc525b64d9773c41dc9fabb3b93dfd03bf6c1568dcc4a4c6bdeb1a
-```
-</Step>
-<Step>
-
-### Update the Sender Address
-
-Overwrite the `SENDER_ADDRESS` environment variable with the new address:
-
-```bash
-export SENDER_ADDRESS=0xA4cD3b0Eb6E5Ab5d8CE4065BcCD70040ADAB1F00
-```
-</Step>
-</Steps>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/05-two-way-communication/04-receiver-contract.mdx b/content/course/interchain-messaging/05-two-way-communication/04-receiver-contract.mdx
deleted file mode 100644
index f5e5027f..00000000
--- a/content/course/interchain-messaging/05-two-way-communication/04-receiver-contract.mdx
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title: Receiver Contract
-description: Adapt the receiver contract to send messages back
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-The receiver contract now has two tasks: 
-
-- **Receive a message from the sender**: Same as in the [last example](/course/interchain-messaging/04-icm-basics/05-receiving-a-message)
-- **Send a message back to the sender**: Now our receiver contract needs to be able to send a message back to the sender.
-
-Therefore, we need to change the receiver contract to be able to send a message back. We will need to instantiate a `TeleporterMessenger` and call the `sendCrossChainMessage()` function. 
-
-```solidity title="contracts/interchain-messaging/send-roundtrip/receiverOnSubnet.sol"
-// (c) 2023, Ava Labs, Inc. All rights reserved.
-// See the file LICENSE for licensing terms.
-
-// SPDX-License-Identifier: Ecosystem
-
-pragma solidity ^0.8.18;
-
-import "@teleporter/ITeleporterMessenger.sol"; // [!code highlight]
-import "@teleporter/ITeleporterReceiver.sol";
-
-contract ReceiverOnSubnet is ITeleporterReceiver {
-    ITeleporterMessenger public immutable messenger = ITeleporterMessenger(0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf); // [!code highlight]
-
-    function receiveTeleporterMessage(bytes32 sourceBlockchainID, address originSenderAddress, bytes calldata message)
-        external
-    {
-        // Only the Interchain Messaging receiver can deliver a message.
-        require(msg.sender == address(messenger), "ReceiverOnSubnet: unauthorized TeleporterMessenger");
-
-        // Send Roundtrip message back to sender
-        string memory response = string.concat(abi.decode(message, (string)), " World!");
-
-        messenger.sendCrossChainMessage( // [!code highlight:9]
-            TeleporterMessageInput({
-                // Blockchain ID of C-Chain
-                destinationBlockchainID: sourceBlockchainID,
-                destinationAddress: originSenderAddress,
-                feeInfo: TeleporterFeeInfo({feeTokenAddress: address(0), amount: 0}),
-                requiredGasLimit: 100000,
-                allowedRelayerAddresses: new address[](0),
-                message: abi.encode(response)
-            })
-        );
-    }
-}
-```
-
diff --git a/content/course/interchain-messaging/05-two-way-communication/05-create-the-receiver-contract.mdx b/content/course/interchain-messaging/05-two-way-communication/05-create-the-receiver-contract.mdx
deleted file mode 100644
index 1968b30c..00000000
--- a/content/course/interchain-messaging/05-two-way-communication/05-create-the-receiver-contract.mdx
+++ /dev/null
@@ -1,42 +0,0 @@
----
-title: Create the Receiver Contract
-description: Deploy roundtrip receiver contract
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-Go ahead and deploy the receiver contract:
-
-<Steps>
-<Step>
-
-### Deploy the Receiver Contract
-
-```bash
-forge create --rpc-url myblockchain --private-key $PK contracts/interchain-messaging/send-roundtrip/receiverOnSubnet.sol:ReceiverOnSubnet
-```
-```
-[⠊] Compiling...
-[⠢] Compiling 1 files with Solc 0.8.18
-[⠆] Solc 0.8.18 finished in 101.71ms
-Compiler run successful!
-Deployer: 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-Deployed to: 0x17aB05351fC94a1a67Bf3f56DdbB941aE6c63E25 // [!code highlight]
-Transaction hash: 0x11df9e14bdae4af60a618a900faa955d75e0ce7dd0f2ccc1ea6a764c149ef805
-```
-
-</Step>
-<Step>
-
-### Update the Receiver Address
-
-Update the `RECEIVER_ADDRESS` environment variable with the new address:
-```bash
-export RECEIVER_ADDRESS=0x17aB05351fC94a1a67Bf3f56DdbB941aE6c63E25
-```
-
-</Step>
-</Steps> 
diff --git a/content/course/interchain-messaging/05-two-way-communication/06-send-a-roundtrip-message.mdx b/content/course/interchain-messaging/05-two-way-communication/06-send-a-roundtrip-message.mdx
deleted file mode 100644
index 729c982f..00000000
--- a/content/course/interchain-messaging/05-two-way-communication/06-send-a-roundtrip-message.mdx
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: Send a Roundtrip Message
-description: Send roundtrip message
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-Alright, now let's send the message:
-
-<Steps>
-<Step>
-### Send the Message:
-
-```bash 
-cast send --rpc-url local-c --private-key $PK $SENDER_ADDRESS "sendMessage(address)" $RECEIVER_ADDRESS
-```
-
-</Step>
-<Step>
-
-### Verify Message Receipt
-
-To check whether the message has been received, we can call the `roundtripMessage()` function on the sender contract. 
-
-```bash
-cast call --rpc-url local-c $SENDER_ADDRESS "roundtripMessage()(string)"
-```
-If successful, you should see the following output:
-```bash
-"Hello World!"
-```
-
-</Step>
-<Step>
-
-### Check the Relayer Logs
-
-To understand in more detail what happened, check out the relayer logs:
-
-```bash
-avalanche teleporter relayer logs
-```
-
-
-</Step>
-</Steps>
diff --git a/content/course/interchain-messaging/05-two-way-communication/07-adapt-the-contracts.mdx b/content/course/interchain-messaging/05-two-way-communication/07-adapt-the-contracts.mdx
deleted file mode 100644
index 841ed763..00000000
--- a/content/course/interchain-messaging/05-two-way-communication/07-adapt-the-contracts.mdx
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: Adapt the Contracts
-description: Assignment - Modify the roundtrip messenger dApp
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-Taking what you've learned in the previous chapter, adapt the sender to send a number instead of a string. The receiver should now multiply the number by 2 and send it back to the sender. The sender saves the result in a public variable.
\ No newline at end of file
diff --git a/content/course/interchain-messaging/06-invoking-functions/01-invoking-functions.mdx b/content/course/interchain-messaging/06-invoking-functions/01-invoking-functions.mdx
deleted file mode 100644
index dd681ef6..00000000
--- a/content/course/interchain-messaging/06-invoking-functions/01-invoking-functions.mdx
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Invoking Functions
-description: Learn how to invoke functions on destination.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
-
-<YouTube id="fl9bF7xzHXc" />
-
-Well done, you successfully learned how to send simple data back and forth between blockchains. In this section we will look further and invoke a smart contract function on the destination chain. 
-
-![](/common-images/teleporter/invoking-functions.png)
-
-## What You Will Learn
-
-In this section, you will go through the following topics:
-
-- **Encoding:** Most smart contract functions have multiple parameters. So the first thing we will learn is how to encode multiple values in the message
-- **Specify which function to call:** Most smart contracts have multiple functions. We will learn how to specify which function to call and encode different parameters depending on which function is been called
-
-## Exercise
-
-In this section you will apply the learned knowledge by building a cross-chain dApp where multiple functions are called on the destination chain.
-
-- Build a Calculator that takes two parameters and adds them up
-- Modify the Calculator to support more functions that can be called from the source Avalanche L1
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
deleted file mode 100644
index dd35e793..00000000
--- a/content/course/interchain-messaging/06-invoking-functions/02-encoding-multiple-values.mdx
+++ /dev/null
@@ -1,93 +0,0 @@
----
-title: Encoding of multiple Values
-description: Learn how to encode multiple function parameters
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-In this section, we will learn how to pack multiple values into a single message.
-
-![](/common-images/teleporter/message-multiple-parameters.png)
-
-We can use `abi.encode()` to encode multiple values into a single byte array:
-
-```solidity
-bytes message = abi.encode(
-      someString,
-      someNumber,
-      someAddress
-  );
-```
-
-Here we can see how the function `abi.encode()` is used to turn multiple values `(someString, someNumber & someAddress)` of various types `(string, uint & address)` into a single value of the type bytes called `message`. This bytearray can then be sent to the destination chain using the Teleporter. 
-
-```solidity
-function sendMessage(address destinationAddress) external returns (uint256 messageID) {
-  string someString = "test";
-  uint someNumber = 43;
-  address someAddress = address(0);
-
-  bytes message = abi.encode( // [!code highlight:4]
-      someString,
-      someNumber,
-      someAddress
-  );
-
-  return teleporterMessenger.sendCrossChainMessage(
-      TeleporterMessageInput({
-        destinationChainID: destinationChainID,
-        destinationAddress: destinationAddress,
-        feeInfo: TeleporterFeeInfo({
-          feeTokenAddress: feeContractAddress,
-          amount: adjustedFeeAmount
-        }),
-        requiredGasLimit: requiredGasLimit,
-        allowedRelayerAddresses: new address[](0),
-        message: message // [!code highlight]
-      })
-  );
-}
-```
-
-The receiving contract can then decode the byte array back into its original values:
-
-```solidity
-function receiveTeleporterMessage(
-  bytes32 originChainID,
-  address originSenderAddress,
-  bytes calldata message
-) external {
-  // Only the Interchain Messaging receiver can deliver a message.
-  if (msg.sender != address(teleporterMessenger)) {
-    revert Unauthorized();
-  }
-
-  // Decoding the function parameters // [!code highlight:6]
-  (
-    string someString,
-    uint256 someNumber,
-    address someAddress
-  ) = abi.decode(message, (string, uint256, address));
-  
-  // Calling the internal function
-  _someFunction(someString, someNumber, someAddress) // [!code highlight]
-  
-}
-
-function _someFunction(string someString, uint256 someNumber, address someAddress) private {
-  // Do something
-}
-```
-
-
-Here we are using `abi.decode()` to unpack the three values `(someString, someNumber & someAddress)` from the parameter `message` of the type `bytes`. As you can see, we need to provide the message as well as the types of values encoded in the message. It is important to note the types must be the same order as parameters to `abi.decode()`. 
-
-```solidity
-(
-  string memory someString,
-  uint someNumber,
-  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/03-create-simple-calculator-sender.mdx b/content/course/interchain-messaging/06-invoking-functions/03-create-simple-calculator-sender.mdx
deleted file mode 100644
index a366ef12..00000000
--- a/content/course/interchain-messaging/06-invoking-functions/03-create-simple-calculator-sender.mdx
+++ /dev/null
@@ -1,91 +0,0 @@
----
-title: Create Simple Calculator Sender
-description: Create a contract that sends multiple parameters of a function
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-Now, our goal is to create a dApp that works as a cross-Avalanche L1 Calculator, receiving multiple parameters and using those for a calculation. For now our calculator will only have the `Sum` function.
-
-<Steps>
-<Step>
-
-### Create Sender Contract
-
-On the local C-Chain, we need to create the sender part of our cross-chain calculator. This will send two numbers (uint) to the receiver contract on your Avalanche L1. 
-
-```solidity title="src/02a-encoding-multiple-paramters/SimpleCalculatorSenderOnCChain.sol"
-pragma solidity ^0.8.18;
-
-import "@teleporter/ITeleporterMessenger.sol";
-
-contract SimpleCalculatorSenderOnCChain {
-    ITeleporterMessenger public immutable teleporterMessenger =
-        ITeleporterMessenger(0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf);
-
-    function sendAddMessage(address destinationAddress, uint256 num1, uint256 num2) external {
-        teleporterMessenger.sendCrossChainMessage(
-            TeleporterMessageInput({
-                // Replace with chain id of your Avalanche L1 (see instructions in Readme) // [!code highlight]
-                destinationBlockchainID: 0xd7ed7b978d4d6c478123bf9b326d47e69f959206d34e42ea4de2d1d2acbc93ea, // [!code highlight]
-                destinationAddress: destinationAddress,
-                feeInfo: TeleporterFeeInfo({feeTokenAddress: address(0), amount: 0}),
-                requiredGasLimit: 100000,
-                allowedRelayerAddresses: new address[](0),
-                message: encodeAddData(num1, num2)
-            })
-        );
-    }
-
-    //Encode helpers
-    function encodeAddData(uint256 a, uint256 b) public pure returns (bytes memory) {
-        bytes memory paramsData = abi.encode(a, b); // [!code highlight]
-        return paramsData;
-    }
-}
-
-```
-
-To increase the readability of the code, we have created a helper function `encodeAddData` that encodes the two numbers into a single byte array.
-
-</Step>
-<Step>
-
-### Replace `destinationBlockchainID`
-<Callout type="warn" title="Don't forget to replace the destinationBlockchainID with the Blockchain ID (HEX) from your Avalanche L1!" />
-
-</Step>
-<Step>
-
-### Deploy the Sender Contract
-
-Deploy the sender contract on the Local C-Chain:
-
-```bash
-forge create --rpc-url local-c --private-key $PK contracts/interchain-messaging/invoking-functions/SimpleCalculatorSenderOnCChain.sol:SimpleCalculatorSenderOnCChain
-```
-```
-[⠊] Compiling...
-[⠒] Compiling 1 files with Solc 0.8.18
-[⠢] Solc 0.8.18 finished in 84.20ms
-Compiler run successful!
-Deployer: 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-Deployed to: 0x789a5FDac2b37FCD290fb2924382297A6AE65860 // [!code highlight]
-Transaction hash: 0xd6cb47dd4ff38e4447711ebbec8b646b93f492f48e80b51719f860984cc25413
-```
-</Step>
-<Step>
-
-### Save the Sender Contract Address
-
-Overwrite the `SENDER_ADDRESS` environment variable with the new address:
-
-```bash
-export SENDER_ADDRESS=0x789a5FDac2b37FCD290fb2924382297A6AE65860
-```
-
-</Step>
-</Steps>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/06-invoking-functions/04-create-simple-calulcator-receiver.mdx b/content/course/interchain-messaging/06-invoking-functions/04-create-simple-calulcator-receiver.mdx
deleted file mode 100644
index 7121037d..00000000
--- a/content/course/interchain-messaging/06-invoking-functions/04-create-simple-calulcator-receiver.mdx
+++ /dev/null
@@ -1,79 +0,0 @@
----
-title: Create Simple Calculator Receiver
-description: Create a contract that receives multiple parameters and execute a function
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-On our Avalanche L1, we need to create the receiver part of our cross-chain calculator. It will receive two numbers and store the result. 
-
-<Steps>
-<Step>
-
-### Create Receiver Contract
-
-```solidity title="src/02a-encoding-multiple-paramters/SimpleCalculatorReceiverOnSubnet.sol"
-pragma solidity ^0.8.18;
-
-import "@teleporter/ITeleporterMessenger.sol";
-import "@teleporter/ITeleporterReceiver.sol";
-
-contract SimpleCalculatorReceiverOnSubnet is ITeleporterReceiver {
-    ITeleporterMessenger public immutable teleporterMessenger =
-        ITeleporterMessenger(0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf);
-
-    uint256 public result_num;
-
-    function receiveTeleporterMessage(bytes32, address, bytes calldata message) external {
-        // Only the Interchain Messaging receiver can deliver a message.
-        require(
-            msg.sender == address(teleporterMessenger), "CalculatorReceiverOnSubnet: unauthorized TeleporterMessenger"
-        );
-
-        (uint256 a, uint256 b) = abi.decode(message, (uint256, uint256)); // [!code highlight:2]
-        _calculatorAdd(a, b);
-    }
-
-    function _calculatorAdd(uint256 _num1, uint256 _num2) internal {
-        result_num = _num1 + _num2;
-    }
-}
-
-```
-
-</Step>
-<Step>
-
-### Deploy the Receiver Contract
-
-Deploy the receiver contract on your Avalanche L1:
-
-```bash
-forge create --rpc-url myblockchain --private-key $PK contracts/interchain-messaging/invoking-functions/SimpleCalculatorReceiverOnSubnet.sol:SimpleCalculatorReceiverOnSubnet
-```
-
-```
-[⠊] Compiling...
-[⠒] Compiling 1 files with Solc 0.8.18
-[⠢] Solc 0.8.18 finished in 44.12ms
-Compiler run successful!
-Deployer: 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-Deployed to: 0x5aa01B3b5877255cE50cc55e8986a7a5fe29C70e // [!code highlight]
-Transaction hash: 0x2d40c53b493556463a28c458e40bc455a248df69a10679bef84145974b7424f3
-```
-
-</Step>
-<Step>
-
-### Save the Receiver Contract Address
-
-Overwrite the `RECEIVER_ADDRESS` environment variable with the new address:
-
-```bash
-export RECEIVER_ADDRESS=0x5aa01B3b5877255cE50cc55e8986a7a5fe29C70e
-```
-</Step>
-</Steps>
diff --git a/content/course/interchain-messaging/06-invoking-functions/05-call-simple-calculator.mdx b/content/course/interchain-messaging/06-invoking-functions/05-call-simple-calculator.mdx
deleted file mode 100644
index b5ac360f..00000000
--- a/content/course/interchain-messaging/06-invoking-functions/05-call-simple-calculator.mdx
+++ /dev/null
@@ -1,42 +0,0 @@
----
-title: Call simple Calculator
-description: Execute a function in one chain from another chain
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-Alright, now let's call our Calculators:
-
-<Steps>
-<Step>
-
-### Call the Sender Contract
-
-```bash 
-cast send --rpc-url local-c --private-key $PK $SENDER_ADDRESS "sendAddMessage(address, uint256, uint256)" $RECEIVER_ADDRESS 2 3
-```
-
-We need to call the `sendAddMessage` function on the sender contract with the address of the receiver contract and the two numbers we want to add. 
-
-For this example we will add 2 + 3.
-
-</Step>
-<Step>
-
-### Verify Message Receipt
-
-To check wether the message has been received, we can call the `result_num()` function on the `Receiver` contract. 
-
-```bash
-cast call --rpc-url myblockchain $RECEIVER_ADDRESS "result_num()(uint)"
-```
-
-```bash
-5
-```
-2 + 3 = 5. Our cross-chain calculation was successful!
-</Step>
-</Steps>
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
deleted file mode 100644
index 37f666fb..00000000
--- a/content/course/interchain-messaging/06-invoking-functions/06-encoding-function-name.mdx
+++ /dev/null
@@ -1,252 +0,0 @@
----
-title: Encoding the Function Name
-description: Work with multiple functions in a single Cross-Chain dApp
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-Great work. We can now pack multiple values into a message. In this section, we will learn how to encode the function name and depending on that its parameters in the message. Let's imagine a more advanced calculator that not only has a single `add` function but also a `concatenate` function, that lets you concatenate two strings. 
-
-For the add function we need to encode two numbers. For the concatenate function we need to encode two strings. How can we go about this? The concept is easy: It's like packing an envelope into another envelope:
-
-![](/common-images/teleporter/message-function-call.png)
-
-## Ecoding the Function Name and Parameters
-
-The first step is to create a `CalculatorAction` enum that specifies the different functions that can be called on the calculator. 
-
-```solidity title="contracts/interchain-messaging/invoking-functions/CalculatorActions.sol"
-pragma solidity ^0.8.18;
-
-enum CalculatorAction {
-    add,
-    concatenate
-}
-```
-
-In the next step we can add this to our `encode helpers` in the sender contract:
-
-```solidity title="contracts/interchain-messaging/invoking-functions/CalculatorSenderOnCChain.sol"
-pragma solidity ^0.8.18;
-
-import "@teleporter/ITeleporterMessenger.sol";
-import "./CalculatorActions.sol"; // [!code highlight]
-
-contract CalculatorSenderOnCChain {
-    ITeleporterMessenger public immutable teleporterMessenger =
-        ITeleporterMessenger(0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf);
-
-    function sendAddMessage(address destinationAddress, uint256 num1, uint256 num2) external {
-        teleporterMessenger.sendCrossChainMessage(
-            TeleporterMessageInput({
-                // Replace with chain id of your Avalanche L1 (see instructions in Readme)
-                destinationBlockchainID: 0x92756d698399805f0088fc07fc42af47c67e1d38c576667ac6c7031b8df05293,
-                destinationAddress: destinationAddress,
-                feeInfo: TeleporterFeeInfo({feeTokenAddress: address(0), amount: 0}),
-                requiredGasLimit: 100000,
-                allowedRelayerAddresses: new address[](0),
-                message: encodeAddData(num1, num2) // [!code highlight]
-            })
-        );
-    }
-
-    function sendConcatenateMessage(address destinationAddress, string memory text1, string memory text2) external {
-        teleporterMessenger.sendCrossChainMessage(
-            TeleporterMessageInput({
-                // Replace with chain id of your Avalanche L1 (see instructions in Readme)
-                destinationBlockchainID: 0x382d2a20c299b03b638dd4d42b96e7401f6c3e88209b764abce83cf71c0c30cd,
-                destinationAddress: destinationAddress,
-                feeInfo: TeleporterFeeInfo({feeTokenAddress: address(0), amount: 0}),
-                requiredGasLimit: 100000,
-                allowedRelayerAddresses: new address[](0),
-                message: encodeConcatenateData(text1, text2) // [!code highlight]
-            })
-        );
-    }
-
-    // Encode helpers
-    function encodeAddData(uint256 a, uint256 b) public pure returns (bytes memory) {
-        bytes memory paramsData = abi.encode(a, b); // [!code highlight:2]
-        return abi.encode(CalculatorAction.add, paramsData);
-    }
-
-    function encodeConcatenateData(string memory a, string memory b) public pure returns (bytes memory) {
-        bytes memory paramsData = abi.encode(a, b); // [!code highlight:2]
-        return abi.encode(CalculatorAction.concatenate, paramsData);
-    }
-}
-```
-
-As you can see here we are calling `abi.encode` twice in the encode helpers. The first time we encode the function paramters and the second time we encode the function name with the byte array containing paramters.
-
-## Decode the Function Name and Parameters
-
-Let's now look at the receiver:
-
-```solidity title="contracts/interchain-messaging/invoking-functions/CalculatorReceiverOnSubnet.sol"
-pragma solidity ^0.8.18;
-
-import "@teleporter/ITeleporterMessenger.sol";
-import "@teleporter/ITeleporterReceiver.sol";
-import "./CalculatorActions.sol";
-
-contract CalculatorReceiverOnSubnet is ITeleporterReceiver {
-    ITeleporterMessenger public immutable teleporterMessenger =
-        ITeleporterMessenger(0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf);
-    uint256 public result_num;
-    string public result_string;
-
-    function receiveTeleporterMessage(bytes32, address, bytes calldata message) external {
-        // Only the Interchain Messaging receiver can deliver a message.
-        require(
-            msg.sender == address(teleporterMessenger), "CalculatorReceiverOnSubnet: unauthorized TeleporterMessenger"
-        );
-
-        // Decoding the Action type: // [!code highlight:2]
-        (CalculatorAction actionType, bytes memory paramsData) = abi.decode(message, (CalculatorAction, bytes)); 
-
-        // Route to the appropriate function. // [!code highlight:10]
-        if (actionType == CalculatorAction.add) {
-            (uint256 a, uint256 b) = abi.decode(paramsData, (uint256, uint256));
-            _calculatorAdd(a, b);
-        } else if (actionType == ...) {
-            (string memory text1, string memory text2) = abi.decode(paramsData, (string, string));
-            _calculatorConcatenateStrings(text1, text2);
-        } else {
-            revert("CalculatorReceiverOnSubnet: invalid action");
-        }
-    }
-
-    function _calculatorAdd(uint256 _num1, uint256 _num2) internal {
-        result_num = _num1 + _num2;
-
-    }
-
-    function _calculatorConcatenateStrings(string memory str1, string memory str2) internal {
-        bytes memory str1Bytes = bytes(str1);
-        bytes memory str2Bytes = bytes(str2);
-
-        bytes memory combined = new bytes(str1Bytes.length + str2Bytes.length + 1);
-
-        for (uint256 i = 0; i < str1Bytes.length; i++) {
-            combined[i] = str1Bytes[i];
-        }
-        combined[str1Bytes.length] = " ";
-        for (uint256 i = 0; i < str2Bytes.length; i++) {
-            combined[str1Bytes.length + i + 1] = str2Bytes[i];
-        }
-
-        result_string = string(combined);
-    }
-}
-```
-
-You can see that we first decode the `CalculatorAction` enum:
-
-```solidity
-// Decoding the Action type: 
-(CalculatorAction actionType, bytes memory paramsData) = abi.decode(message, (CalculatorAction, bytes)); 
-```
-
-Then based on the function name we decide how to unpack the paramters
-
-```solidity
-// Route to the appropriate function. 
-if (actionType == CalculatorAction.add) {
-    (uint256 a, uint256 b) = abi.decode(paramsData, (uint256, uint256)); // [!code highlight]
-    _calculatorAdd(a, b);
-} else if (actionType == ...) {
-    (string memory text1, string memory text2) = abi.decode(paramsData, (string, string)); // [!code highlight]
-    _calculatorConcatenateStrings(text1, text2);
-} else {
-    revert("CalculatorReceiverOnSubnet: invalid action");
-}
-```
-
-For the `add` function we decode two numbers and for the `concatenate` function we decode two strings. After the decoding we call the appropriate internal function.
-
-## Try it Out
-
-Deploy the sender and receiver contracts and try out the `add` and `concatenate` functions. 
-
-<Steps>
-<Step>
-
-### Deploy the Sender Contract
-
-<Callout type="warn" title="Don't forget to replace BOTH destinationBlockchainIDs in CalculatorSenderOnCChain with the Blockchain ID (HEX) from your Avalanche L1!" />
-
-```bash
-forge create --rpc-url local-c --private-key $PK contracts/interchain-messaging/invoking-functions/CalculatorSenderOnCChain.sol:CalculatorSenderOnCChain
-```
-```
-[⠃] Compiling...
-[⠆] Compiling 2 files with Solc 0.8.18
-[⠰] Solc 0.8.18 finished in 240.23ms
-Compiler run successful!
-Deployer: 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-Deployed to: 0x8B3BC4270BE2abbB25BC04717830bd1Cc493a461 // [!code highlight]
-Transaction hash: 0xf9cce28a714764bb265bba7522bfd10d620fa0cb0f5dae26de2ac773b0a878ee
-```
-
-</Step>
-<Step>
-
-### Save the Sender Address:
-
-```bash
-export SENDER_ADDRESS=0x8B3BC4270BE2abbB25BC04717830bd1Cc493a461
-```
-
-</Step>
-<Step>
-
-### Deploy the Receiver Contract:
-
-```bash
-forge create --rpc-url myblockchain --private-key $PK contracts/interchain-messaging/invoking-functions/CalculatorReceiverOnSubnet.sol:CalculatorReceiverOnSubnet
-```
-```
-[⠊] Compiling...
-[⠢] Compiling 1 files with Solc 0.8.18
-[⠆] Solc 0.8.18 finished in 148.40ms
-Compiler run successful!
-Deployer: 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-Deployed to: 0x5DB9A7629912EBF95876228C24A848de0bfB43A9 // [!code highlight]
-Transaction hash: 0xa8efb88abfef486d2caba30cb4146b1dc56a0ee88c7fb4c46adccdf1414ae39e
-```
-</Step>
-<Step>
-
-### Save the Receiver address:
-
-```bash
-export RECEIVER_ADDRESS=0x5DB9A7629912EBF95876228C24A848de0bfB43A9
-```
-
-</Step>
-<Step>
-
-### Call the Functions
-
-Now you can call the `sendAddMessage` and `sendConcatenateMessage` functions on the sender contract and see the results on the receiver contract. 
-
-```bash
-cast send --rpc-url local-c --private-key $PK $SENDER_ADDRESS "sendAddMessage(address, uint, uint)" $RECEIVER_ADDRESS 1 2
-```
-
-</Step>
-<Step>
-
-### Verify the Result:
-
-```bash
-cast call --rpc-url myblockchain $RECEIVER_ADDRESS "result_num()(uint)"
-```
-
-</Step>
-</Steps>
-
-<Quiz quizId="307"/>
diff --git a/content/course/interchain-messaging/06-invoking-functions/07-extend-calculator.mdx b/content/course/interchain-messaging/06-invoking-functions/07-extend-calculator.mdx
deleted file mode 100644
index 1df7cf76..00000000
--- a/content/course/interchain-messaging/06-invoking-functions/07-extend-calculator.mdx
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: Extend the Calculator
-description: Assignment- Extend calculator functionality
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-Now let's add a third feature to the calculator: adding three numbers. We want you to practice handling different amounts of parameters depending on the action to perform, so your task will be to add a `tripleSum` function that sums up three values of the type uint. 
-
-You will need to:
-
-- Add the `trippleSum` action to the enum file
-- Add a new encode helper and send function to the sender contract
-- Add a new route to the receiver and implement the `tripleSum` function
-
-Check out the solution under `/contracts/interchain-messaging/2c-invoking-functions` on the Avalanche-Starter-Kit
diff --git a/content/course/interchain-messaging/07-icm-registry/01-icm-registry.mdx b/content/course/interchain-messaging/07-icm-registry/01-icm-registry.mdx
deleted file mode 100644
index 3f8dd848..00000000
--- a/content/course/interchain-messaging/07-icm-registry/01-icm-registry.mdx
+++ /dev/null
@@ -1,40 +0,0 @@
----
-title: Interchain Messaging Registry
-description: Learn about the Interchain Messaging Registry to manage multiple Interchain Messaging versions.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
-
-When sending a message from the source chain we are calling the Interchain Messaging contract:
-
-<img src="/common-images/teleporter/teleporter-source.png" width="400" class="mx-auto"/>
-
-The TeleporterMessenger contract is non-upgradable. Once a version of the contract is deployed it cannot be changed. This is with the intention of preventing any changes to the deployed contract that could potentially introduce bugs or vulnerabilities. However, there could still be new versions of TeleporterMessenger contracts needed to be deployed in the future.
-
-So far we used a fixed address for the TeleporterMessenger in all of our contracts. It is hardcoded in our contract. This is not a good practice, as it makes the contract less flexible and harder to upgrade.
-
-```solidity
-contract SenderOnCChain {
-
-    ITeleporterMessenger public immutable teleporterMessenger = ITeleporterMessenger(0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf); // [!code highlight]
-
-    function sendMessage(
-        address destinationAddress,
-        string calldata message
-    ) external {
-        teleporterMessenger.sendCrossChainMessage(
-            // ...
-        );
-    }
-}
-```
-
-While we could manually update the address of the used TeleporterMessenger in our contract, TeleporterRegistry provides us an easy way to use the latest version of TeleporterMessenger.
-
-## What you will learn
-
-In this section, you will explore the following topics:
-
-- How the Interchain Messaging Registry works
-- How to retrieve the latest version of the TeleporterMessenger on a blockchain
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
deleted file mode 100644
index d669d7a3..00000000
--- a/content/course/interchain-messaging/07-icm-registry/02-how-the-icm-registry-works.mdx
+++ /dev/null
@@ -1,83 +0,0 @@
----
-title: How the ICM Registry works
-description: Learn about the different functionality available in the Interchain Messaging Registry.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-TeleporterRegistry keeps track of TeleporterMessenger contract versions. Cross-Avalanche L1 dApps can request the latest or a specific version of the TeleporterMessenger:
-
-<img src="/common-images/teleporter/teleporter-registry.png" width="600" class="mx-auto"/>
-
-Internally the TeleporterRegistry maintains a mapping of TeleporterMessenger contract versions to their addresses.
-
-<img src="/common-images/teleporter/teleporter-registry-class-diagram.png" width="400" class="mx-auto"/>
-
-Each registry's mapping of version to contract address is independent of registries on other blockchains, and chains can decide on their own registry mapping entries. So the contract of version 4 on one chain does not have to be equal to that version on another chain.
-
-```solidity title="/lib/teleporter/contracts/src/Teleporter/upgrades/TeleporterRegistry.sol"
-
-contract TeleporterRegistry {
-    // .... 
-  
-    // The latest protocol version. 0 means no protocol version has been added, and isn't a valid version.
-    uint256 public latestVersion;
-
-    // Mappings that keep track of the protocol version and corresponding contract address.
-    mapping(uint256 version => address protocolAddress) private _versionToAddress;
-    mapping(address protocolAddress => uint256 version) private _addressToVersion;
-  
-   // ...
-}
-```
-In the `TeleporterRegistry` contract, the `latestVersion` state variable returns the highest version number that has been registered in the registry. The `getLatestTeleporter` function returns the `ITeleporterMessenger` that is registered with the corresponding version. Version zero is an invalid version, and is used to indicate that a `TeleporterMessenger` contract has not been registered yet.
-
-```solidity title="/lib/teleporter/contracts/src/Teleporter/upgrades/TeleporterRegistry.sol"
-contract TeleporterRegistry {
-    // .... 
-  
-  	// Mappings that keep track of the protocol version and corresponding contract address.
-    mapping(uint256 version => address protocolAddress) private _versionToAddress;
-  
-    // The latest protocol version. 0 means no protocol version has been added, and isn't a valid version.
-    uint256 public latestVersion;
-
-    function getLatestTeleporter() external view returns (ITeleporterMessenger) {
-        return ITeleporterMessenger(getAddressFromVersion(latestVersion));
-    }
-
-    function getAddressFromVersion(uint256 version) public view returns (address) {
-        require(version != 0, "TeleporterRegistry: zero version");
-        address protocolAddress = _versionToAddress[version];
-        require(protocolAddress != address(0), "TeleporterRegistry: version not found");
-        return protocolAddress;
-    }
-  
-    // ...
-}
-```
-
-If a cross-Avalanche L1 dApps prefers a specific version, it can also call directly the `getAddressFromVersion` function:
-
-```solidity title="/lib/teleporter/contracts/src/Teleporter/upgrades/TeleporterRegistry.sol"
-contract TeleporterRegistry {
-  	// Mappings that keep track of the protocol version and corresponding contract address.
-    mapping(uint256 version => address protocolAddress) private _versionToAddress;
-  
-    // .... 
-  
-    function getAddressFromVersion(uint256 version) public view returns (address) {
-        require(version != 0, "TeleporterRegistry: zero version");
-        address protocolAddress = _versionToAddress[version];
-        require(protocolAddress != address(0), "TeleporterRegistry: version not found");
-        return protocolAddress;
-    }
-  
-    // ...
-}
-```
-
-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/07-icm-registry/03-interact-with-the-registry.mdx b/content/course/interchain-messaging/07-icm-registry/03-interact-with-the-registry.mdx
deleted file mode 100644
index 86f425f4..00000000
--- a/content/course/interchain-messaging/07-icm-registry/03-interact-with-the-registry.mdx
+++ /dev/null
@@ -1,105 +0,0 @@
----
-title: Interact with the ICM Registry
-description: Retrieve latest Interchain Messaging version using the Registry.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-
-Let's start by interacting with the registry. Registry is deployed on specific addresses depending the chain you're operating and the status of the network at the deployment time. For your local network you can find it out with the following command:
-
-<Steps>
-<Step>
-
-### Get C-Chain Registry Address
-
-```bash
-avalanche primary describe
-``` 
-
-```
-   _____       _____ _           _         _____
-  / ____|     / ____| |         (_)       |  __ \
- | |   ______| |    | |__   __ _ _ _ __   | |__) |_ _ _ __ __ _ _ __ ___  ___ 
- | |  |______| |    | '_ \ / _  | | '_ \  |  ___/ _  | '__/ _  | '_   _ \/ __|
- | |____     | |____| | | | (_| | | | | | | |  | (_| | | | (_| | | | | | \__ \
-  \_____|     \_____|_| |_|\__,_|_|_| |_| |_|   \__,_|_|  \__,_|_| |_| |_|___/
-+------------------------------+--------------------------------------------------------------------------+
-|          PARAMETER           |                                  VALUE                                   |
-+------------------------------+--------------------------------------------------------------------------+
-| RPC URL                      | http://127.0.0.1:9650/ext/bc/C/rpc                                       |
-+------------------------------+--------------------------------------------------------------------------+
-| Codespace RPC URL            | https://opulent-giggle-rxwwq774w553wq7p-9650.app.github.dev/ext/bc/C/rpc |
-+------------------------------+--------------------------------------------------------------------------+
-| EVM Chain ID                 | 43112                                                                    |
-+------------------------------+--------------------------------------------------------------------------+
-| TOKEN SYMBOL                 | AVAX                                                                     |
-+------------------------------+--------------------------------------------------------------------------+
-| Address                      | 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC                               |
-+------------------------------+--------------------------------------------------------------------------+
-| Balance                      | 49999478.838561118                                                       |
-+------------------------------+--------------------------------------------------------------------------+
-| Private Key                  | 56289e99c94b6912bfc12adc093c9b51124f0dc54ac7a766b2bc5ccf558d8027         |
-+------------------------------+--------------------------------------------------------------------------+
-| BlockchainID (CB58)          | NeA134STyTVwife7gYeNQ6Hwi5GPGC2X7aUFvWsnusnpM2do6                        |
-+------------------------------+--------------------------------------------------------------------------+
-| BlockchainID (HEX)           | 0x31233cae135e3974afa396e90f465aa28027de5f97f729238c310d2ed2f71902       |
-+------------------------------+--------------------------------------------------------------------------+
-| Teleporter Messenger Address | 0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf                               |
-+------------------------------+--------------------------------------------------------------------------+
-| Teleporter Registry Address  | 0x17aB05351fC94a1a67Bf3f56DdbB941aE6c63E25                               | // [!code highlight]
-+------------------------------+--------------------------------------------------------------------------+
-```
-
-</Step>
-<Step>
-
-### Save C-Chain Registry Address
-
-Let's put the address of the registry in an environment variable:
-
-```bash
-export C_CHAIN_REGISTRY_ADDRESS=0x17aB05351fC94a1a67Bf3f56DdbB941aE6c63E25
-```
-
-</Step>
-<Step>
-
-### Get L1 Registry Address
-
-```bash
-avalanche blockchain describe myblockchain
-```
-```
-+-------------------------------------------------------------------------------------------+
-|                                         TELEPORTER                                        |
-+---------------+------------------------------+--------------------------------------------+
-| Local Network | Teleporter Messenger Address | 0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf |
-|               +------------------------------+--------------------------------------------+
-|               | Teleporter Registry Address  | 0x98F9971D3832B94241A2FbBC39712d6e13D8Df99 | // [!code highlight]
-+---------------+------------------------------+--------------------------------------------+
-```
-</Step>
-<Step>
-
-### Save L1 Registry Address
-
-```bash
-export MYBLOCKCHAIN_REGISTRY_ADDRESS=0x98F9971D3832B94241A2FbBC39712d6e13D8Df99
-```
-
-</Step>
-<Step>
-
-### Retrieve Latest ICM Messenger Version:
-
-Let's interact with the Registry by getting the latest version of the Interchain Messaging Messenger deployed on C-Chain:
-
-```bash
-cast call --rpc-url local-c $C_CHAIN_REGISTRY_ADDRESS "latestVersion()(uint256)" 
-```
-
-</Step>
-</Steps>
diff --git a/content/course/interchain-messaging/07-icm-registry/04-retrieving-icm-from-registry.mdx b/content/course/interchain-messaging/07-icm-registry/04-retrieving-icm-from-registry.mdx
deleted file mode 100644
index fef69e69..00000000
--- a/content/course/interchain-messaging/07-icm-registry/04-retrieving-icm-from-registry.mdx
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: Retrieving Interchain Messenger from the Registry
-description: Use Registry in a Cross-Chain dApp.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-Let's now integrate the registry into a smart contract. Let's go back to the very simple string sending contract from the beginning:
-
-```solidity title="contracts/interchain-messaging/registry/SenderOnCChainWithRegistry.sol"
-pragma solidity ^0.8.18;
-
-import "@teleporter/upgrades/TeleporterRegistry.sol"; // [!code highlight]
-import "@teleporter/ITeleporterMessenger.sol";
-
-contract SenderOnCChain {
-    // The Interchain Messaging registry contract manages different Interchain Messaging contract versions. // [!code highlight:3]
-    TeleporterRegistry public immutable teleporterRegistry = TeleporterRegistry(0x827364Da64e8f8466c23520d81731e94c8DDe510);
-
-    /**
-     * @dev Sends a message to another chain.
-     */
-    function sendMessage(address destinationAddress, string calldata message) external {
-        ITeleporterMessenger messenger = teleporterRegistry.getLatestTeleporter();  // [!code highlight]
-
-        messenger.sendCrossChainMessage(
-            TeleporterMessageInput({
-                // Replace with blockchainID of your Avalanche L1 (see instructions in Readme)
-                destinationBlockchainID: 0x92756d698399805f0088fc07fc42af47c67e1d38c576667ac6c7031b8df05293,
-                destinationAddress: destinationAddress,
-                feeInfo: TeleporterFeeInfo({feeTokenAddress: address(0), amount: 0}),
-                requiredGasLimit: 100000,
-                allowedRelayerAddresses: new address[](0),
-                message: abi.encode(message)
-            })
-        );
-    }
-}
-```
-
-<Callout type="warn" title="Don't forget to replace the destinationBlockchainID with Blockchain ID (HEX) from your Avalanche L1!" />
-
-The key things to understand:
-
-- We are importing the `ITeleporterRegistry.sol` interface
-- We have a variable for the registry address instead of the messenger address
-- Before sending the message we get the latest version from the registry
diff --git a/content/course/interchain-messaging/07-icm-registry/05-verify-sender-is-icm.mdx b/content/course/interchain-messaging/07-icm-registry/05-verify-sender-is-icm.mdx
deleted file mode 100644
index 839f00e1..00000000
--- a/content/course/interchain-messaging/07-icm-registry/05-verify-sender-is-icm.mdx
+++ /dev/null
@@ -1,57 +0,0 @@
----
-title: Verify if Sender is Interchain Messaging
-description: Safety verification of the message sender
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-We can also leverage the registry to check if `msg.sender` is a registered Interchain Messaging contract. Previously, we hardcoded this check in the contract:
-
-```solidity
-import "@teleporter/ITeleporterMessenger.sol";
-import "@teleporter/ITeleporterReceiver.sol";
-
-contract ReceiverOnSubnet is ITeleporterReceiver {
-    ITeleporterMessenger public immutable messenger = ITeleporterMessenger(0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf);
-
-    string public lastMessage;
-
-    function receiveTeleporterMessage(bytes32, address, bytes calldata message) external {
-        // Only the Interchain Messaging receiver can deliver a message. // [!code highlight:2]
-        require(msg.sender == address(messenger), "ReceiverOnSubnet: unauthorized TeleporterMessenger");
-
-        // Store the message.
-        lastMessage = abi.decode(message, (string));
-    }
-}
-```
-
-If there was now a new Interchain Messaging contract version that would be used for sending messages, we would have to update the contract.
-
-Instead, we can use the registry to check if the sender is a registered Interchain Messaging contract. 
-
-```solidity
-pragma solidity ^0.8.18;
-
-import "@teleporter/upgrades/TeleporterRegistry.sol";
-import "@teleporter/ITeleporterMessenger.sol";
-import "@teleporter/ITeleporterReceiver.sol";
-
-contract ReceiverOnDispatchWithRegistry is ITeleporterReceiver {
-    // The Interchain Messaging registry contract manages different Interchain Messaging contract versions.
-    TeleporterRegistry public immutable teleporterRegistry =
-        TeleporterRegistry(0x827364Da64e8f8466c23520d81731e94c8DDe510);
-
-    string public lastMessage;
-
-    function receiveTeleporterMessage(bytes32, address, bytes calldata message) external {
-        // Only a Interchain Messaging Messenger registered in the registry can deliver a message. // [!code highlight:3]
-        // Function throws an error if msg.sender is not registered.
-        teleporterRegistry.getVersionFromAddress(msg.sender);
-
-        // Store the message.
-        lastMessage = abi.decode(message, (string));
-    }
-}
-```
\ No newline at end of file
diff --git a/content/course/interchain-messaging/08-securing-cross-chain-communication/01-securing-cross-chain-communication.mdx b/content/course/interchain-messaging/08-securing-cross-chain-communication/01-securing-cross-chain-communication.mdx
deleted file mode 100644
index 3290e1d7..00000000
--- a/content/course/interchain-messaging/08-securing-cross-chain-communication/01-securing-cross-chain-communication.mdx
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: Securing Cross-Chain Communication
-description: Learn about Avalanche Warp Messaging and how it ensures secure communication between blockchains.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
-
-<YouTube id="rJ-G5ri65rs" />
-
-We can achieve interoperability through sending messages across blockchains. In blockchain systems there are often vast amounts of money involved, which can render attacking the systems very profitable. For instance, we've seen bridge hacks where criminals stole billions of dollars in digital assets.
-
-Ensuring the security of the communication between blockchain is critical when building cross-chain dApps. But how can we do that? How can we ensure that a received message is actually from the claimed sender and that no one changed the contents on the way?
-
-This is where Avalanche Warp Messaging comes into play. It is not EVM specific, but rather a general cross-Avalanche L1 communication protocol. In this section you will learn about the underlying cryptographic primitives that make Avalanche Warp Messaging secure.
-
-## What you will learn
-
-In this section, you will go through the following topics:
-
-- **Signature Schemes:** What can be achieved using signature schemes and how do they work?
-- **Multi-Signature Schemes:** How can a group of participants sign a message
-- **Signature Aggregation:** How can we increase the efficiency of multi-signature schemes
\ 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
deleted file mode 100644
index 5b7c6747..00000000
--- a/content/course/interchain-messaging/08-securing-cross-chain-communication/02-signature-schemes.mdx
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Signature Schemes
-description: Learn how BLS Signature Schemes work and how they can be used to secure cross-chain communication.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-import SignatureSchemes from "@/content/common/cryptography/signature-schemes.mdx"
-
-<SignatureSchemes />
-
-<Quiz quizId="309"/>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/08-securing-cross-chain-communication/03-use-a-signature-scheme.mdx b/content/course/interchain-messaging/08-securing-cross-chain-communication/03-use-a-signature-scheme.mdx
deleted file mode 100644
index 612c6231..00000000
--- a/content/course/interchain-messaging/08-securing-cross-chain-communication/03-use-a-signature-scheme.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Use a Signature Scheme
-description: Learn how to use a signature scheme to secure cross-chain communication.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-import SignatureSchemesDemo from "@/content/common/cryptography/signature-schemes-demo.mdx"
-
-<SignatureSchemesDemo />
\ 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
deleted file mode 100644
index fbdf9922..00000000
--- a/content/course/interchain-messaging/08-securing-cross-chain-communication/04-multi-signature-schemes.mdx
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Multi-Signature Schemes
-description: Learn how multiple signatures can help secure cross-chain communication.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-import MultiSignatureSchemes from "@/content/common/cryptography/multi-signature-schemes.mdx"
-
-<MultiSignatureSchemes />
-
-<Quiz quizId="310"/>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/08-securing-cross-chain-communication/05-signature-aggregation.mdx b/content/course/interchain-messaging/08-securing-cross-chain-communication/05-signature-aggregation.mdx
deleted file mode 100644
index 9e057ff1..00000000
--- a/content/course/interchain-messaging/08-securing-cross-chain-communication/05-signature-aggregation.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Signature & Key Aggregation
-description: Learn about signature and key aggregation and how it can be used to secure cross-chain communication.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-import SignatureKeyAggregation from "@/content/common/cryptography/signature-key-aggregation.mdx"
-
-<SignatureKeyAggregation />
\ No newline at end of file
diff --git a/content/course/interchain-messaging/08-securing-cross-chain-communication/06-use-a-multi-signature-scheme.mdx b/content/course/interchain-messaging/08-securing-cross-chain-communication/06-use-a-multi-signature-scheme.mdx
deleted file mode 100644
index 44eeacf0..00000000
--- a/content/course/interchain-messaging/08-securing-cross-chain-communication/06-use-a-multi-signature-scheme.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Use a Multi-Signature Scheme
-description: Learn how to use multi-signature schemes to secure cross-chain communication.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-import SignatureSchemesDemo from "@/content/common/cryptography/multi-signature-schemes-demo.mdx"
-
-<SignatureSchemesDemo />
\ No newline at end of file
diff --git a/content/course/interchain-messaging/08-securing-cross-chain-communication/07-trusted-third-parties.mdx b/content/course/interchain-messaging/08-securing-cross-chain-communication/07-trusted-third-parties.mdx
deleted file mode 100644
index a8772cd8..00000000
--- a/content/course/interchain-messaging/08-securing-cross-chain-communication/07-trusted-third-parties.mdx
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Trusted Third Parties
-description: Learn about the challenges of cross-chain communication.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-# "Cross-chain communication is impossible without a trusted third party, contrary to common beliefs in the blockchain community"
-- A. Zamyatin et al. in [SoK: Communication Across Distributed Ledgers](https://eprint.iacr.org/2019/1128.pdf)
-
-Signature Schemes give us the tool to ensure the authenticity of message, but who will send these messages? Can we build a cross-chain communication protocol that does not introduce additional trust assumption?
-
-The paper [SoK: Communication Across Distributed Ledgers](https://eprint.iacr.org/2019/1128.pdf) looks into this question and states that a CCC protocol must have the following attributes:
-
-- **Effectiveness:** all relevant transactions are posted on their respective chains at the desired time
-- **Atomicity:** either all transactions were posted on their respective chains at the desired time, or no transactions were posted at all 
-- **Timeliness:** all transactions will eventually be posted on their respective chains
-
-It is possible to create a cross-chain communication protocol that adheres to the three attributes mentioned above? Can a correct CCC protocol that is trustless exist?
-
-In SoK, the researchers come to the conclusion that such a trustless, correct CCC protocol is impossible. Using computational complexity theory, the trustless, correct CCC protocol problem can be reduced into the Fair Exchange problem, a problem that has been proven to have no solution.
-
-We see this also in practice. Many bridges and cross-chain communications often rely on some centralized infrastructure that observes the source chain and then delivers the message to the destination chain. Their users need to trust this setup, often involving a set of third-party bridge validators.
-
-However, there might be a smart trick we can use. We'll explore this in the next section about Avalanche Warp Messaging.
\ No newline at end of file
diff --git a/content/course/interchain-messaging/09-avalanche-warp-messaging/01-avalanche-warp-messaging.mdx b/content/course/interchain-messaging/09-avalanche-warp-messaging/01-avalanche-warp-messaging.mdx
deleted file mode 100644
index 02bd778d..00000000
--- a/content/course/interchain-messaging/09-avalanche-warp-messaging/01-avalanche-warp-messaging.mdx
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Avalanche Warp Messaging
-description: Learn about Avalanche Warp Messaging, the Cross-Chain communication primitives on Avalanche.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
-
-<YouTube id="95KB-JhQS2Y" />
-
-Avalanche Warp Messaging (AWM) was developed to make all Avalanche blockchains natively interoperable. Ideally, this solution would introduce as few trust assumptions as possible, meaning the blockchains would not depend on a third-party or intermediary that could risk centralization or single-point failures. 
-
-AWM allows Avalanche L1s to communicate with one another via authenticated messages by providing signing and verification primitives in AvalancheGo. These are used by the blockchain VMs to sign outgoing messages and verify incoming messages. Any Virtual Machine (VM) on Avalanche can integrate AWM to send and receive messages across Avalanche Avalanche L1s. 
-
-Therefore, AWM is not EVM specific, but rather a general cross-Avalanche L1 communication protocol.
-
-## What you will learn
-
-In this section, you will go through the following topics:
-
-- **P-Chain:** What is the role of the P-Chain in Avalanche Warp Messaging?
-- **Warp Message Format:** What does a Warp message consist of?
-- **Warp Message Signing:** How does AWM utilize the mutli-signature scheme BLS to create aggregated signatures?
-- **Warp Message Signature Verification:** How are the signatures of warp messages verified?
-- **Trust Assumptions:** What trust assumptions does AWM introduce?
\ 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
deleted file mode 100644
index 08045813..00000000
--- a/content/course/interchain-messaging/09-avalanche-warp-messaging/02-p-chain.mdx
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Recap P-Chain
-description: Recap about the P-Chain main functionality of handling validator operations.
-updated: 2024-05-31
-authors: [martineckardt]
-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/03-warp-message-format.mdx b/content/course/interchain-messaging/09-avalanche-warp-messaging/03-warp-message-format.mdx
deleted file mode 100644
index 019b6c98..00000000
--- a/content/course/interchain-messaging/09-avalanche-warp-messaging/03-warp-message-format.mdx
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Warp Message Format
-description: Learn about the structure of a Warp Message.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-Warp Messages have a minimal message format that only contains the absolute necessary data for the transportation:
-
-- **NetworkID:** The ID of the Network (Mainnet, Fuji Test Network, Local Test Network). This is included as a security mechanisms, so messages from the Fuji Test Network cannot be replayed on the Mainnet.
-- **SourceChainID:** The chainID where the message originates from. This is not the EVM chain ID you may know from adding a network to a wallet, but the blockchain ID on the P-Chain. The P-Chain uses the transaction ID of the transaction that created those blockchain on the P-Chain for the chain ID, e.g.: 0xd7cdc6f08b167595d1577e24838113a88b1005b471a6c430d79c48b4c89cfc53
-- **SourceAddress:** The address of the message sender
-- **Payload:** The payload of the message
-
-Every Warp message can be uniquely identified by its ID: the SHA256 hash of the serialized message (NetworkID, SourceChainID, SourceAddress & Payload).
-
-The fields above are actually an UnsignedMessage. Hence, it has not been attached an aggregated signature yet. We will examine this in the following sections. 
diff --git a/content/course/interchain-messaging/09-avalanche-warp-messaging/04-awm-relayer.mdx b/content/course/interchain-messaging/09-avalanche-warp-messaging/04-awm-relayer.mdx
deleted file mode 100644
index 3c5c602b..00000000
--- a/content/course/interchain-messaging/09-avalanche-warp-messaging/04-awm-relayer.mdx
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: AWM Relayer
-description: Learn the basic AWM role and configuration.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-The AWM Relayer is an application run independently of the blockchain clients. Anyone can run their own AWM Relayer to create a communication channel between two Avalanche L1s, and there can be multiple relayers for the same communication channel. There is an open source implementation anyone can use [here](https://github.com/ava-labs/awm-relayer). 
-
-[AvaCloud](https://www.avacloud.io) also offers their own hosted relayers.
-
-![AWM Relayer data flow](/course-images/teleporter/teleporter-source-destination-with-relayer.png)
-
-The AWM Relayers are responsible for picking up the messages at the source Avalanche L1, aggregating the BLS signatures from a sufficiently large share of the source Avalanche L1's validators and submitting a transaction on the destination Avalanche L1.
-
-It is up to the cross-chain application to decide if they allow any relayer to be part of the delivery process, or whether to restrict participation to certain Relayers.
-
-## AWM Relayer Config
-
-The AWM Relayer can be configured so that it is reusable for different networks (Mainnet, Fuji Testnet, Local) and communication channels between Avalanche L1s. The following configurations are available:
-
-```json title="https://github.com/ava-labs/awm-relayer/blob/main/sample-relayer-config.json"
-{
-  "info-api": {
-    "base-url": "https://api.avax-test.network"
-  },
-  "p-chain-api": {
-    "base-url": "https://api.avax-test.network"
-  },
-  "source-blockchains": [
-    {
-      "subnet-id": "11111111111111111111111111111111LpoYY",
-      "blockchain-id": "yH8D7ThNJkxmtkuv2jgBa4P1Rn3Qpr4pPr7QYNfcdoS6k6HWp",
-      "vm": "evm",
-      "rpc-endpoint": {
-        "base-url": "https://api.avax-test.network/ext/bc/C/rpc"
-      },
-      "ws-endpoint": {
-        "base-url": "wss://api.avax-test.network/ext/bc/C/ws"
-      },
-      "message-contracts": {
-        "0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf": {
-          "message-format": "teleporter",
-          "settings": {
-            "reward-address": "0x5072..."
-          }
-        }
-      }
-    }
-  ],
-  "destination-blockchains": [
-    {
-      "subnet-id": "7WtoAMPhrmh5KosDUsFL9yTcvw7YSxiKHPpdfs4JsgW47oZT5",
-      "blockchain-id": "2D8RG4UpSXbPbvPCAWppNJyqTG2i2CAXSkTgmTBBvs7GKNZjsY",
-      "vm": "evm",
-      "rpc-endpoint": {
-        "base-url": "https://subnets.avax.network/dispatch/testnet/rpc"
-      },
-      "account-private-key": "0x7493..."
-    }
-  ]
-}
-```
-
-- **Info API URL:** An RPC endpoint where the AWM Relayer can access the Info API to retrieve the information about the network
-- **P-Chain API URL:** An RPC endpoint where the AWM Relayer can access the P-Chain to retrieve the validators of the source Avalanche L1
-- **Source Avalanche L1 Configs:** An array of configurations for the source Avalanche L1s where the messages are picked up from
-- **Destination Avalanche L1 Configs:** An array of configurations for the destination Avalanche L1s where the messages are delivered to
\ No newline at end of file
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
deleted file mode 100644
index 26798003..00000000
--- a/content/course/interchain-messaging/09-avalanche-warp-messaging/05-dataflow.mdx
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: Dataflow
-description: Learn the complete flow of a Cross-Chain message.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-Looking at the bigger picture, the data flow of an interchain message can be described as follows:
-
- 
-<Steps>
-<Step>
- 
-### Message Initialization
-Cross-Chain dApp initiating the message calls the Interchain Messaging Contract on the source Avalanche L1
- 
-</Step>
- 
-<Step>
- 
-### Warp Precompile
-The Interchain Messaging contracts interacts with the AWM precompile of the EVM
- 
-</Step>
-
-<Step>
- 
-### Message Relaying
-An AWM Relayer relays the message 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.
- 
-</Step>
-
-<Step>
- 
-### Signature Verification
-The Interchain Messaging contract on the destination chain interacts with AWM to verify the signature of the message and whether it has been signed by a sufficiently large stake share of the source Avalanche L1's validator set.
- 
-</Step>
-
-<Step>
- 
-### Destination Contract Call
-The Interchain Messaging contract then calls the destination dApp contract 
-
-</Step>
-
-<Step>
- 
-### Message Processing
-The dApp decodes the message payload and processes it accordingly.
-
-</Step>
-</Steps>
-
-As you noticed in the `Teleporter Basics` chapter most of the cross-chain communication has been abstracted away from the dApp developer. The only interfaces for them are:
-
-- **Sending a message:** Simply calling the Interchain Messaging contract on the source chain
-- **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
deleted file mode 100644
index df1625ad..00000000
--- a/content/course/interchain-messaging/09-avalanche-warp-messaging/06-message-pickup.mdx
+++ /dev/null
@@ -1,60 +0,0 @@
----
-title: Message Pickup
-description: Learn about the role of the Relayer when picking up the message.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-When the AWM Relayer detects a new message, it collects the signatures of that message from the validators of the source Avalanche L1. The validator uses the BLS private key corresponding to their  BLS public key (registered on the P-Chain) to create a signature for the unsigned warp message we've learned about earlier (in the Warp Message Format).
-
-![](/common-images/awm/relayer-pickup.png)
-
-The AWM Relayer does not necessarily need to collect the signature of all validators. It only needs to ensure that the validators of the collected signatures represent a sufficiently large share of the total stake of the Avalanche L1. It is up to the receiving Avalanche L1 to determine what the threshold is.
-
-## New Outgoing Messages
-
-How does a AWM Relayer learn about new messages? The AWM Relayer has two options to check for outgoing warp message on the source Avalanche L1:
-
-- **Polling:** The AWM Relayer periodically checks the source chain for new outgoing messages. 
-- **Notification:** The AWM Relayer is triggered whenever a new outgoing message is detected by a node. 
-
-## AWM Relayer Source Avalanche L1 Configuration
-
-For the source Avalanche L1s, the AWM Relayer offers the following configuration:
-
-```json
-"source-blockchains": [
-    {
-      "subnet-id": "11111111111111111111111111111111LpoYY",
-      "blockchain-id": "yH8D7ThNJkxmtkuv2jgBa4P1Rn3Qpr4pPr7QYNfcdoS6k6HWp",
-      "vm": "evm",
-      "rpc-endpoint": {
-        "base-url": "https://api.avax-test.network/ext/bc/C/rpc"
-      },
-      "ws-endpoint": {
-        "base-url": "wss://api.avax-test.network/ext/bc/C/ws"
-      },
-      "message-contracts": {
-        "0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf": {
-          "message-format": "teleporter",
-          "settings": {
-            "reward-address": "0x5072..."
-          }
-        }
-      }
-    }
-  ],
-```
-
-- **subnet-id:** The id of the source Avalanche L1
-- **blockchain-id:** The chainId of the source Avalanche L1's blockchain that should be checked for outgoing messages
-- **vm:** A string specifying the virtual machine of the source Avalanche L1's blockchain. Currently, only the evm is supported, but this field has been added in anticipation of communication between blockchains powered by different virtual machines in the future.
-- **rpc-endpoint:** The host of a node that can be queried for outgoing messages 
-- **rpc-endpoint:** The websocket endpoint of a node that can be queried for outgoing messages 
-- **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
-
-<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
deleted file mode 100644
index d59dad42..00000000
--- a/content/course/interchain-messaging/09-avalanche-warp-messaging/07-message-delivery.mdx
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: Message Delivery
-description: Learn about the role of the Relayer for delivering the message.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-Next, the AWM Relayer delivers the message with the aggregated signature by simply submitting a transaction to the destination Avalanche L1. The transaction is propagated through the validator set of the destination blockchain just as any other regular transaction would.
-
-In order to submit the transaction, the AWM Relayer needs access to the private key of a wallet holding the gas token of the destination blockchain to sign the transaction.
-
-![](/common-images/awm/relayer-delivery.png)
-
-When the validators verify the transaction, they perform the following steps:
-
-<Steps>
-<Step>
- 
-### Query the P-Chain:
-The verifying validators of the destination L1 each query the validator set of the source Avalanche L1 with its stake weights and BLS Public Keys.
-
-</Step>
- 
-<Step>
- 
-### Verify Sufficient Stake Weight:
-First, the verifying validators are checking if the combined stake weight of the validators that have signed the Warp message is large enough to accept the message (e.g. validators representing 50% of the total stake have signed the message). The required stake weight required to accept a message from a source chain can be set arbitrarily by the destination chain. An Avalanche L1 may require 50% for chain A and 90% for chain B. If the stake weight of the validators of the aggregate signature is insufficient the message is rejected.
-
-</Step>
-
-<Step>
- 
-### Aggregate BLS Public Keys:
-The verifying validators of the destination L1 aggregate the BLS Public Keys of the source L1 validators that signed the message. 
-
-</Step>
- 
-<Step>
- 
-### Verify BLS Multi-Signature:
-The aggregated signature (created by the AWM Relayer) is now being verified using the aggregated BLS Public Key (aggregated by the destination L1 validators). If the verification fails (e.g. the AWM Relayer modified the message), the message is rejected.
-
-</Step>
-
-<Step>
- 
-### Message Execution:
-If the verification is successful, the message is executed. 
-
-</Step>
-
-</Steps>
-
-
-## Why doesn't the AWM Relayer also aggregate the BLS Public Keys?
-
-The BLS public key aggregation has to be done by every validator of the destination subnet. Some may ask why we don't perform this action off-chain through the AWM Relayer and attach it to the message (similar to the BLS signature aggregation).
-
-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.
-
-<Quiz quizId="314"/>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/09-avalanche-warp-messaging/08-load-considerations.mdx b/content/course/interchain-messaging/09-avalanche-warp-messaging/08-load-considerations.mdx
deleted file mode 100644
index a59b7e7d..00000000
--- a/content/course/interchain-messaging/09-avalanche-warp-messaging/08-load-considerations.mdx
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: Load Considerations
-description: Learn which chains experience a load increase when sending a Cross-Chain message.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-Let's take a moment and determine where AWM takes up load:
-
-- **Source Avalanche L1**: Validators sign the message
-- **Relayer**: Signature aggregation
-- **Destination Avalanche L1**: Validators verify the message using the BLS Public Key registry on the P-Chain
-
-There is no record of the network communication, the signatures, or the message itself on the P-Chain. It solely functions as a registry of the BLS public keys where the destination Avalanche L1 validators read from. Since they each already validate the primary network, they are already tracking the P-Chain.
-
-Thus, sending messages from one Avalanche L1 to another does not put any load on the P-Chain or another part of the Primary Network. This is a crucial feature, as there is no bottleneck or dependencies between Avalanche L1s for cross-chain communication. 
diff --git a/content/course/interchain-messaging/09-avalanche-warp-messaging/09-trust-assumption-of-awm.mdx b/content/course/interchain-messaging/09-avalanche-warp-messaging/09-trust-assumption-of-awm.mdx
deleted file mode 100644
index 9a1ff1b5..00000000
--- a/content/course/interchain-messaging/09-avalanche-warp-messaging/09-trust-assumption-of-awm.mdx
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Trust Assumptions
-description: Learn where the trust relays when using AWM.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-Avalanche Warp Messaging uses a trick: The trusted third party is the validator set of the source L1. We are already trusting them, or else we wouldn't communicate with that L1. 
-
-The only thing that needs to be ensured is that there is always an AWM Relayer doing the signature aggregation and delivery of the warp message. Since it will have to pay gas on the destination chain, the sender needs to make sure it has enough incentives to do so. Either those incentives come from the sender itself, or from the receiving L1 if it has an inherent interest to onboard users to its chain. You will learn how users can incentivize AWM Relayers with ERC20 tokens with Interchain Messaging in following chapters. 
-
-Generally, if there were no relayer available, anyone could run a AWM Relayer and deliver their own messages.
\ No newline at end of file
diff --git a/content/course/interchain-messaging/10-running-a-relayer/01-running-a-relayer.mdx b/content/course/interchain-messaging/10-running-a-relayer/01-running-a-relayer.mdx
deleted file mode 100644
index 09ab3370..00000000
--- a/content/course/interchain-messaging/10-running-a-relayer/01-running-a-relayer.mdx
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Running a Relayer
-description: Learn how to run and manage a AWM Relayer.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
-
-As you now know Interchain Messaging requires a running relayer to deliver the warp messages underlying it. So far we just assumed a relayer is running and in fact Avalanche CLI automatically configures and runs a relayer for you if you deploy your L1 on a local network. However, in a production environment, you will either need to run a relayer yourself or have someone else run it for you.
-
-![AWM Relayer data flow](/course-images/teleporter/teleporter-source-destination-with-relayer.png)
-
-In this section you will learn how to run a relayer for Avalanche Warp Messaging. As discussed in the section on AWM, the relayer is responsible for checking for outgoing warp messages on the source L1, aggregate the signatures and deliver it with a transaction on the destination L1.
-
-This chapter utilizes the reference relayer implementation created by Ava Labs. In this case the relayer is a standalone application written in Go. There may be different implementations in the future that are adapted to special use cases. Anyone can build and run a relayer.
-
-## What you will learn
-
-In this section, you will go through the following topics:
-
-- **Run a Relayer:** You will understand the basic commands to run a local relayer.
-- **Relayer Config:** Here, you will understand how to configure the relayer by creating a relayer config file. This file serves as a blueprint for the relayer's functionality and behavior.
-- **Wallet:** Create a wallet for the relayer, fund it with testnet tokens and add the wallet parameter to the relayer config.
-- **Run the Relayer:** Now you will execute the AWM Relayer with your configuration 
-- **Send Message:** Next you will issue a transaction triggering a cross-Avalanche L1 message, so we can observe how the message is delivered by the relayer.
-- **Verify Message Delivery:** You will learn how you can track the message delivery 
\ No newline at end of file
diff --git a/content/course/interchain-messaging/10-running-a-relayer/02-control-the-avalanche-cli-relayer.mdx b/content/course/interchain-messaging/10-running-a-relayer/02-control-the-avalanche-cli-relayer.mdx
deleted file mode 100644
index 17edf789..00000000
--- a/content/course/interchain-messaging/10-running-a-relayer/02-control-the-avalanche-cli-relayer.mdx
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Control the Avalanche CLI Relayer
-description: Stop and start an AWM relayer
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-When you deploy your own chain using Avalanche CLI in the Avalanche Starter-kit it offers you to run a relayer on launch. This will automatically run a relayer that delivers any message between the local Avalanche L1s. We will cover configuration in the next section, but for now you will need to learn some basic commands.
-
-## Stopping the Relayer
-
-If you want to stop the relayer, you can use the following command:
-
-```bash
-avalanche teleporter relayer stop
-```
-
-## Starting the Relayer
-
-If you want to start the relayer, you can use the following command:
-
-```bash
-avalanche teleporter relayer start
-```
\ No newline at end of file
diff --git a/content/course/interchain-messaging/10-running-a-relayer/03-install-relayer.mdx b/content/course/interchain-messaging/10-running-a-relayer/03-install-relayer.mdx
deleted file mode 100644
index 478815e3..00000000
--- a/content/course/interchain-messaging/10-running-a-relayer/03-install-relayer.mdx
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Install the AWM Relayer
-description: Learn about the different ways to run a relayer
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-The binary for the Avalanche Warp Messaging (AWM) relayer can be acquired in multiple ways:
-
-- **Download from GitHub Release:** For every release the binary is uploaded to the [GitHub releases page](https://github.com/ava-labs/awm-relayer/releases)
-- **Use Docker:** The Docker image is available under the tag `avaplatform/awm-relayer:latest` on the [Docker Hub](https://hub.docker.com/r/avaplatform/awm-relayer)
-- **Build from Source:** You can also build it from source directly if you want to make modifications or run it on a different platform. The source code is available on the [GitHub repository](https://github.com/ava-labs/awm-relayer?tab=readme-ov-file#building)
-
-When using the [Avalanche Starter Kit](https://github.com/ava-labs/avalanche-starter-kit) the relayer is already included in the Dev Container. You can start the relayer by running the following command:
-
-```bash
-avalanche teleporter relayer start
-```
\ No newline at end of file
diff --git a/content/course/interchain-messaging/10-running-a-relayer/04-relayer-configuration.mdx b/content/course/interchain-messaging/10-running-a-relayer/04-relayer-configuration.mdx
deleted file mode 100644
index c4103750..00000000
--- a/content/course/interchain-messaging/10-running-a-relayer/04-relayer-configuration.mdx
+++ /dev/null
@@ -1,146 +0,0 @@
----
-title: Configuration
-description: Learn how to configure a Relayer 
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-A relayer is configured to relayer messages between certain source and destination L1s. Therefore, the configuration consists of three parts:
-- **General Config:** Configuration independent of the source and destination L1s concerning the network as a whole
-- **Source Blockchain Configs:** All parameters necessary for the relayer to pick up the messages 
-- **Destination Blockchain Configs:** All parameters necessary to deliver the messages
-
-The configuration is supplied to the relayer as a JSON file. Let's open the one automatically created for the Avalanche-CLI relayer:
-
-```bash
-code ~/.avalanche-cli/runs/network_xxxx_xxxx/awm-relayer-config.json 
-```
-Where the xxxx_xxxx will be a name automatically assigned to your local deployment.
-
-Let's go through the different values:
-
-## General Config
-
-The general config contains among others the following parameters:
-
-```json
-{
-  "p-chain-api": {
-    "base-url": "http://127.0.0.1:9650",
-    "query-parameters": {},
-    "http-headers": null
-  },
-  "info-api": {
-    "base-url": "http://127.0.0.1:9650",
-    "query-parameters": {},
-    "http-headers": null
-  	},  
-   	// ...
-}
-```
-
-- **info-api-url:** The URL of the [Info API](https://docs.avax.network/api-reference/info-api) node to which the relayer will connect to to receive information like the NetworkID.
-- **p-chain-api-url:** The URL of the Avalanche [P-Chain API](https://docs.avax.network/api-reference/p-chain/api) node to which the relayer will connect to query the validator sets. 
-
-## Source Blockchain Configs
-
-Next is the configuration for our source blockchain. This is the configuration of the blockchain where messages will be initiated and picked up. The relayer will aggregate the signatures of the validators of that Subnet. 
-
-```json
-{
-  // General Config ...
-
-  "source-blockchains": [
-	{
-      "subnet-id": "11111111111111111111111111111111LpoYY",
-      "blockchain-id": "epm5fG6Pn1Y5rBHdTe36aZYeLqpXugreyHLZB5dV81rVTs7Ku",
-      "vm": "evm",
-      "rpc-endpoint": {
-        "base-url": "http://127.0.0.1:9650/ext/bc/epm5fG6Pn1Y5rBHdTe36aZYeLqpXugreyHLZB5dV81rVTs7Ku/rpc",
-        "query-parameters": null,
-        "http-headers": null
-      },
-      "ws-endpoint": {
-        "base-url": "ws://127.0.0.1:9650/ext/bc/epm5fG6Pn1Y5rBHdTe36aZYeLqpXugreyHLZB5dV81rVTs7Ku/ws",
-        "query-parameters": null,
-        "http-headers": null
-      },
-      "message-contracts": {
-        "0x0000000000000000000000000000000000000000": {
-          "message-format": "off-chain-registry",
-          "settings": {
-            "teleporter-registry-address": "0x17aB05351fC94a1a67Bf3f56DdbB941aE6c63E25"
-          }
-        },
-        "0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf": {
-          "message-format": "teleporter",
-          "settings": {
-            "reward-address": "0xbAE6Ff34d6Da45128C1ddFEDA008e55A328f5665"
-          }
-        }
-      }
-    }
-  ]
-
-  // Destination Blockchains
-}
-```
-
-- **subnet-id:** The Blockchain ID of the L1 that the source blockchain is part of. In this example this is the Blockchain ID of the Primary Network.
-- **blockchain-id:** The blockchain ID of the source. In this example this is the blockchain ID of Fuji's C-Chain.
-- **vm:** A string specifying the virtual machine of the destination L1's blockchain. Currently, only the EVM is supported, but this field has been added in anticipation of communication between blockchains powered by different virtual machines in the future.
-- **rpc-endpoint:** An API Config containing:
-<div class="pl-6">
-- **base-url:** RPC endpoint of the source L1's API node.
-- **query-parameters:** Additional query parameters to include in the API requests
-- **http-headers:** Additional HTTP headers to include in the API requests
-</div>
-- **wss-endpoint:** An API Config containing:
-<div class="pl-6">
-- **base-url**: The WebSocket endpoint of the source L1's API node
-- **query-parameters:** Additional query parameters to include in the API requests
-- **http-headers:** Additional HTTP headers to include in the API requests
-</div>
-- **message-contracts:** A map of contract addresses to the config options of the protocol (e.g. Teleporter) at that address. Each MessageProtocolConfig consists of a unique message-format name, and the raw JSON settings. "0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf" is the address of the TeleporterMessenger on the Fuji C-Chain.
-<div class="pl-6">
-- **message-format:** should be set to Teleporter. Additional message formats next to Interchain Messaging may be developed in the future 
-- **settings > reward-address:** The address that will be rewarded if a L1 is incentivizing relayers to send messages on it's behalf. This is the address of the wallet you will create for this relayer. 
-</div>
-
-## Destination Blockchains
-
-Next is the configuration for our destination blockchain. This is the configuration of the blockchain where messages will be sent to. The relayer will aggregate the signatures of the validators of that L1. 
-```json
-{
-  "destination-blockchains": [
-    {
-      "subnet-id": "11111111111111111111111111111111LpoYY",
-      "blockchain-id": "epm5fG6Pn1Y5rBHdTe36aZYeLqpXugreyHLZB5dV81rVTs7Ku",
-      "vm": "evm",
-      "rpc-endpoint": {
-        "base-url": "http://127.0.0.1:9650/ext/bc/epm5fG6Pn1Y5rBHdTe36aZYeLqpXugreyHLZB5dV81rVTs7Ku/rpc",
-        "query-parameters": null,
-        "http-headers": null
-      },
-      "kms-key-id": "",
-      "kms-aws-region": "",
-      "account-private-key": "6dc6ba26b9b17f82b7b44fc316857a35ff201613072d500231ce3f2ee235bc16"
-    },
-  ],
-}
-```
-
-For each destination L1, the relayer has the following config parameter:
-
-- **subnet-id:** The ID of the L1 that the destination blockchain is part of. 
-- **blockchain-id:** The blockchain ID of the destination blockchain. This is the Blockchain ID of Fuji's Dispatch L1.
-- **vm:** A string specifying the virtual machine of the destination L1's blockchain. Currently, only the EVM is supported, but this field has been added in anticipation of communication between blockchains powered by different virtual machines in the future.
-- **rpc-endpoint:** The RPC endpoint of the destination L1's API node. Used in favor of api-node-host, api-node-port, and encrypt-connection when constructing the endpoint.
-- **kms-key-id:** The ID of the KMS key to use for signing transactions on the destination blockchain. Only one of account-private-key or kms-key-id should be provided. If kms-key-id is provided, then kms-aws-region is required. Please note that the private key in KMS should be exclusive to the relayer. 
-- **kms-aws-region:** The AWS region in which the KMS key is located. Required if kms-key-id is provided. 
-- **account-private-key:** A private key for a wallet that holds gas tokens on the destination L1. This is required so the relayer can sign the transaction that delivers the warp message.
-
-If you have been following all the course up to this point with the Avalanche-starter-kit and Avalanche-CLI will provide you with a relayer already funded to perform transactions between the local C-chain and your own chain
-
-Some configuration fields have been omitted for the purpose of this exercise. If you are interested to read the extensive list of relayer configurations, you can visit the awm-relayer GitHub repository [here](https://github.com/ava-labs/awm-relayer/tree/main?tab=readme-ov-file#configuration).
diff --git a/content/course/interchain-messaging/10-running-a-relayer/05-multichain-relayer-config.mdx b/content/course/interchain-messaging/10-running-a-relayer/05-multichain-relayer-config.mdx
deleted file mode 100644
index e3d9bc09..00000000
--- a/content/course/interchain-messaging/10-running-a-relayer/05-multichain-relayer-config.mdx
+++ /dev/null
@@ -1,217 +0,0 @@
----
-title: Two-Way Messaging Configuration
-description: Learn how to configure a relayer for multiple L1s
-updated: 2024-10-09
-authors: [owenwahlgren]
-icon: BookOpen
----
-
-<Callout>Important: The relayer needs funds on both L1s to deliver messages. </Callout>
-
-### Two-Way Messaging Configuration
-
-In this section, you’ll learn how to configure a relayer to support two-way messaging between multiple Layer 1 blockchains (L1s). By extending your existing configuration, you can enable the relayer to handle communication in both directions, eliminating the need to run multiple relayers.
-
-### Accessing the Relayer Configuration File
-
-The relayer configuration is supplied as a JSON file. To open the configuration file automatically created by the Avalanche-CLI, run the following command:
-```bash
-code ~/.avalanche-cli/runs/network_xxxx_xxxx/awm-relayer-config.json 
-```
-
-<Callout>Replace xxxx_xxxx with the name automatically assigned to your local deployment.</Callout>
-
-Alternatively, navigate to the directory `~/.avalanche-cli/runs/` and locate the relayer configuration file for your network.
-
-### Understanding the Existing Configuration
-
-Assuming you have a configuration as described in the [Relayer Configuration section](/course/interchain-messaging/10-running-a-relayer/04-relayer-configuration), your current configuration should look similar to the following:
-```json
-{
-  "p-chain-api": {
-    "base-url": "http://127.0.0.1:9650",
-    "query-parameters": {},
-    "http-headers": null
-  },
-  "info-api": {
-    "base-url": "http://127.0.0.1:9650",
-    "query-parameters": {},
-    "http-headers": null
-  },  
-  "source-blockchains": [
-    {
-      "subnet-id": "11111111111111111111111111111111LpoYY",
-      "blockchain-id": "epm5fG6Pn1Y5rBHdTe36aZYeLqpXugreyHLZB5dV81rVTs7Ku",
-      "vm": "evm",
-      "rpc-endpoint": {
-        "base-url": "http://127.0.0.1:9650/ext/bc/<blockchain-id>/rpc",
-        "query-parameters": null,
-        "http-headers": null
-      },
-      "ws-endpoint": {
-        "base-url": "ws://127.0.0.1:9650/ext/bc/<blockchain-id>/ws",
-        "query-parameters": null,
-        "http-headers": null
-      },
-      "message-contracts": {
-        "0x0000000000000000000000000000000000000000": {
-          "message-format": "off-chain-registry",
-          "settings": {
-            "teleporter-registry-address": "0x<registry-address>"
-          }
-        },
-        "0x<contract-address>": {
-          "message-format": "teleporter",
-          "settings": {
-            "reward-address": "0x<reward-address>"
-          }
-        }
-      }
-    }
-  ],
-  "destination-blockchains": [
-    {
-      "subnet-id": "11111111111111111111111111111111LpoYY",
-      "blockchain-id": "epm5fG6Pn1Y5rBHdTe36aZYeLqpXugreyHLZB5dV81rVTs7Ku",
-      "vm": "evm",
-      "rpc-endpoint": {
-        "base-url": "http://127.0.0.1:9650/ext/bc/<blockchain-id>/rpc",
-        "query-parameters": null,
-        "http-headers": null
-      },
-      "kms-key-id": "",
-      "kms-aws-region": "",
-      "account-private-key": "<your-private-key>"
-    }
-  ]
-}
-```
-
-### Updating the Configuration for Two-Way Communication
-
-To enable two-way communication between L1s, you need to extend the configuration to include both blockchains in the source-blockchains and destination-blockchains arrays.
-
-Updated Configuration:
-
-```json
-{
-  "p-chain-api": {
-    "base-url": "http://127.0.0.1:9650",
-    "query-parameters": {},
-    "http-headers": null
-  },
-  "info-api": {
-    "base-url": "http://127.0.0.1:9650",
-    "query-parameters": {},
-    "http-headers": null
-  },
-  "source-blockchains": [
-    {
-      "subnet-id": "<blockchain-id-A>",
-      "blockchain-id": "<blockchain-id-A>",
-      "vm": "evm",
-      "rpc-endpoint": {
-        "base-url": "http://127.0.0.1:9650/ext/bc/<blockchain-id-A>/rpc",
-        "query-parameters": null,
-        "http-headers": null
-      },
-      "ws-endpoint": {
-        "base-url": "ws://127.0.0.1:9650/ext/bc/<blockchain-id-A>/ws",
-        "query-parameters": null,
-        "http-headers": null
-      },
-      "message-contracts": {
-        "0x0000000000000000000000000000000000000000": {
-          "message-format": "off-chain-registry",
-          "settings": {
-            "teleporter-registry-address": "0x<registry-address-A>"
-          }
-        },
-        "0x<contract-address-A>": {
-          "message-format": "teleporter",
-          "settings": {
-            "reward-address": "0x<reward-address-A>"
-          }
-        }
-      }
-    },
-    {
-      "subnet-id": "<blockchain-id-B>",
-      "blockchain-id": "<blockchain-id-B>",
-      "vm": "evm",
-      "rpc-endpoint": {
-        "base-url": "http://127.0.0.1:9650/ext/bc/<blockchain-id-B>/rpc",
-        "query-parameters": null,
-        "http-headers": null
-      },
-      "ws-endpoint": {
-        "base-url": "ws://127.0.0.1:9650/ext/bc/<blockchain-id-B>/ws",
-        "query-parameters": null,
-        "http-headers": null
-      },
-      "message-contracts": {
-        "0x0000000000000000000000000000000000000000": {
-          "message-format": "off-chain-registry",
-          "settings": {
-            "teleporter-registry-address": "0x<registry-address-B>"
-          }
-        },
-        "0x<contract-address-B>": {
-          "message-format": "teleporter",
-          "settings": {
-            "reward-address": "0x<reward-address-B>"
-          }
-        }
-      }
-    }
-  ],
-  "destination-blockchains": [
-    {
-      "subnet-id": "<blockchain-id-A>",
-      "blockchain-id": "<blockchain-id-A>",
-      "vm": "evm",
-      "rpc-endpoint": {
-        "base-url": "http://127.0.0.1:9650/ext/bc/<blockchain-id-A>/rpc",
-        "query-parameters": null,
-        "http-headers": null
-      },
-      "kms-key-id": "",
-      "kms-aws-region": "",
-      "account-private-key": "<your-private-key-A>"
-    },
-    {
-      "subnet-id": "<blockchain-id-B>",
-      "blockchain-id": "<blockchain-id-B>",
-      "vm": "evm",
-      "rpc-endpoint": {
-        "base-url": "http://127.0.0.1:9650/ext/bc/<blockchain-id-B>/rpc",
-        "query-parameters": null,
-        "http-headers": null
-      },
-      "kms-key-id": "",
-      "kms-aws-region": "",
-      "account-private-key": "<your-private-key-B>"
-    }
-  ]
-}
-```
-### Explanation of Changes
-
-By adding both blockchains to the source-blockchains and destination-blockchains arrays, the relayer is configured to:
-
-- Listen for messages on both blockchains.
-- Relay messages to the opposite blockchain.
-
-This setup enables two-way communication between the blockchains using a single relayer instance.
-
-### Important Considerations
-
-- **Private Keys**: Ensure that the account-private-key field contains the private key for the respective blockchain. This key is used to sign transactions when relaying messages.
-- **Funding**: The relaxyer account must have sufficient funds on both L1s to cover transaction fees.
-
-### Next Steps
-
-After updating the configuration file:
-- Save the changes.
-- Restart the relayer to apply the new configuration.
-- Test the two-way communication by sending messages between the blockchains.
\ No newline at end of file
diff --git a/content/course/interchain-messaging/10-running-a-relayer/06-analyze-relayer-logs.mdx b/content/course/interchain-messaging/10-running-a-relayer/06-analyze-relayer-logs.mdx
deleted file mode 100644
index ac25f479..00000000
--- a/content/course/interchain-messaging/10-running-a-relayer/06-analyze-relayer-logs.mdx
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: Relayer Logs
-description: Get the logs and activity of the relayer
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-To analyze the relayer activity you can check the relayer logs. If you're using the Avalanche CLI, you can access them with the following command:
-
-```bash
-avalanche teleporter relayer logs
-```
-
-Alternatively the JSON logs can be located under "~/.avalanche-cli/runs/awm-relayer.log". Let's take a look at them:
-
-```bash
-code ~/.avalanche-cli/runs/awm-relayer.log 
-```
-
-```bash
-{"level":"info","timestamp":"2024-07-11T01:38:40.093Z","logger":"awm-relayer","caller":"main/main.go:94","msg":"Initializing awm-relayer"}
-{"level":"info","timestamp":"2024-07-11T01:38:40.093Z","logger":"awm-relayer","caller":"main/main.go:99","msg":"Set config options."}
-{"level":"info","timestamp":"2024-07-11T01:38:40.093Z","logger":"awm-relayer","caller":"main/main.go:102","msg":"Initializing destination clients"}
-{"level":"info","timestamp":"2024-07-11T01:38:40.094Z","logger":"awm-relayer","caller":"evm/destination_client.go:105","msg":"Initialized destination client","blockchainID":"epm5fG6Pn1Y5rBHdTe36aZYeLqpXugreyHLZB5dV81rVTs7Ku","evmChainID":"43112","nonce":0}
-{"level":"info","timestamp":"2024-07-11T01:38:40.096Z","logger":"awm-relayer","caller":"evm/destination_client.go:105","msg":"Initialized destination client","blockchainID":"dXobeMTZB89Fy6E987aaRBDz2j8mVparqRRfvvmQDsH8haNJJ","evmChainID":"123","nonce":0}
-{"level":"info","timestamp":"2024-07-11T01:38:40.096Z","logger":"awm-relayer","caller":"main/main.go:121","msg":"Initializing app request network"}
-{"level":"info","timestamp":"2024-07-11T01:38:41.757Z","logger":"awm-relayer","caller":"main/main.go:440","msg":"starting metrics server...","port":9091}
-{"level":"info","timestamp":"2024-07-11T01:38:41.757Z","logger":"awm-relayer","caller":"main/main.go:373","msg":"Creating application relayers","originBlockchainID":"epm5fG6Pn1Y5rBHdTe36aZYeLqpXugreyHLZB5dV81rVTs7Ku"}
-{"level":"info","timestamp":"2024-07-11T01:38:41.758Z","logger":"awm-relayer","caller":"main/main.go:373","msg":"Creating application relayers","originBlockchainID":"dXobeMTZB89Fy6E987aaRBDz2j8mVparqRRfvvmQDsH8haNJJ"}
-{"level":"info","timestamp":"2024-07-11T01:38:41.758Z","logger":"awm-relayer","caller":"checkpoint/checkpoint.go:40","msg":"Creating checkpoint manager","relayerID":"0x96ba68805e937e7695ffb1c956dab0aff39ec5529fd037d8168eb6d5587866fe","startingHeight":4}
-{"level":"info","timestamp":"2024-07-11T01:38:41.758Z","logger":"awm-relayer","caller":"checkpoint/checkpoint.go:40","msg":"Creating checkpoint manager","relayerID":"0xf8b2da5b262b41a2ee2d2b46e61e68c95ec7fb8f6b0abbe4101f75f8281b85aa","startingHeight":4}
-{"level":"info","timestamp":"2024-07-11T01:38:41.758Z","logger":"awm-relayer","caller":"main/main.go:283","msg":"Created application relayers","blockchainID":"epm5fG6Pn1Y5rBHdTe36aZYeLqpXugreyHLZB5dV81rVTs7Ku"}
-{"level":"info","timestamp":"2024-07-11T01:38:41.759Z","logger":"awm-relayer","caller":"relayer/listener.go:127","msg":"Creating relayer","subnetID":"11111111111111111111111111111111LpoYY","subnetIDHex":"0000000000000000000000000000000000000000000000000000000000000000","blockchainID":"epm5fG6Pn1Y5rBHdTe36aZYeLqpXugreyHLZB5dV81rVTs7Ku","blockchainIDHex":"55e1fcfdde01f9f6d4c16fa2ed89ce65a8669120a86f321eef121891cab61241"}
-{"level":"info","timestamp":"2024-07-11T01:38:41.760Z","logger":"awm-relayer","caller":"checkpoint/checkpoint.go:40","msg":"Creating checkpoint manager","relayerID":"0xe73a74b50d44b1b216bf806bc7e230d5305e544d35d41c2313cda26766ccd8ec","startingHeight":4}
-{"level":"info","timestamp":"2024-07-11T01:38:41.760Z","logger":"awm-relayer","caller":"checkpoint/checkpoint.go:40","msg":"Creating checkpoint manager","relayerID":"0x66f44659b15f9d819caf71978931df3d5d7925b5d800cc4ef8153f12151401f6","startingHeight":4}
-{"level":"info","timestamp":"2024-07-11T01:38:41.760Z","logger":"awm-relayer","caller":"main/main.go:283","msg":"Created application relayers","blockchainID":"dXobeMTZB89Fy6E987aaRBDz2j8mVparqRRfvvmQDsH8haNJJ"}
-{"level":"info","timestamp":"2024-07-11T01:38:41.772Z","logger":"awm-relayer","caller":"relayer/listener.go:127","msg":"Creating relayer","subnetID":"26eqgD4Kt1MvTKXC9BDjEwBAfhcBcHCKj2EXjR2UuFpSWoAHhw","subnetIDHex":"9087d2f383171f73819baa49c3be63a5a6e2b492114dfc3556e42eedd182050a","blockchainID":"dXobeMTZB89Fy6E987aaRBDz2j8mVparqRRfvvmQDsH8haNJJ","blockchainIDHex":"52f2c4d51ef13a5781babe42c1b916e98fc88fc72919b20527782c939c8be71d"}
-{"level":"info","timestamp":"2024-07-11T01:38:41.782Z","logger":"awm-relayer","caller":"evm/subscriber.go:131","msg":"Successfully subscribed","blockchainID":"dXobeMTZB89Fy6E987aaRBDz2j8mVparqRRfvvmQDsH8haNJJ"}
-{"level":"info","timestamp":"2024-07-11T01:38:41.782Z","logger":"awm-relayer","caller":"evm/subscriber.go:131","msg":"Successfully subscribed","blockchainID":"epm5fG6Pn1Y5rBHdTe36aZYeLqpXugreyHLZB5dV81rVTs7Ku"}
-{"level":"info","timestamp":"2024-07-11T01:38:41.782Z","logger":"awm-relayer","caller":"relayer/listener.go:166","msg":"processed-missed-blocks set to false, starting processing from chain head","blockchainID":"dXobeMTZB89Fy6E987aaRBDz2j8mVparqRRfvvmQDsH8haNJJ"}
-{"level":"info","timestamp":"2024-07-11T01:38:41.783Z","logger":"awm-relayer","caller":"main/main.go:335","msg":"Created listener","blockchainID":"dXobeMTZB89Fy6E987aaRBDz2j8mVparqRRfvvmQDsH8haNJJ"}
-{"level":"info","timestamp":"2024-07-11T01:38:41.783Z","logger":"awm-relayer","caller":"main/main.go:348","msg":"Listener initialized. Listening for messages to relay.","originBlockchainID":"dXobeMTZB89Fy6E987aaRBDz2j8mVparqRRfvvmQDsH8haNJJ"}
-{"level":"info","timestamp":"2024-07-11T01:38:41.782Z","logger":"awm-relayer","caller":"relayer/listener.go:166","msg":"processed-missed-blocks set to false, starting processing from chain head","blockchainID":"epm5fG6Pn1Y5rBHdTe36aZYeLqpXugreyHLZB5dV81rVTs7Ku"}
-{"level":"info","timestamp":"2024-07-11T01:38:41.783Z","logger":"awm-relayer","caller":"main/main.go:335","msg":"Created listener","blockchainID":"epm5fG6Pn1Y5rBHdTe36aZYeLqpXugreyHLZB5dV81rVTs7Ku"}
-{"level":"info","timestamp":"2024-07-11T01:38:41.783Z","logger":"awm-relayer","caller":"main/main.go:348","msg":"Listener initialized. Listening for messages to relay.","originBlockchainID":"epm5fG6Pn1Y5rBHdTe36aZYeLqpXugreyHLZB5dV81rVTs7Ku"}
-{"level":"info","timestamp":"2024-07-11T01:43:59.040Z","logger":"awm-relayer","caller":"relayer/listener.go:406","msg":"Unpacked warp message","sourceBlockchainID":"epm5fG6Pn1Y5rBHdTe36aZYeLqpXugreyHLZB5dV81rVTs7Ku","originSenderAddress":"0x5DB9A7629912EBF95876228C24A848de0bfB43A9","destinationBlockchainID":"dXobeMTZB89Fy6E987aaRBDz2j8mVparqRRfvvmQDsH8haNJJ","destinationAddress":"0x52C84043CD9c865236f11d9Fc9F56aa003c1f922","warpMessageID":"2ZV5u7WPVozo386A3d8T5B81vAKvcSDdNsggpmHFvihy5Yut1S"}
-{"level":"info","timestamp":"2024-07-11T01:43:59.052Z","logger":"awm-relayer","caller":"relayer/application_relayer.go:320","msg":"Fetching aggregate signature from the source chain validators via AppRequest"}
-{"level":"info","timestamp":"2024-07-11T01:43:59.060Z","logger":"awm-relayer","caller":"relayer/application_relayer.go:461","msg":"Created signed message.","destinationBlockchainID":"dXobeMTZB89Fy6E987aaRBDz2j8mVparqRRfvvmQDsH8haNJJ"}
-{"level":"info","timestamp":"2024-07-11T01:43:59.060Z","logger":"awm-relayer","caller":"teleporter/message_handler.go:187","msg":"Sending message to destination chain","destinationBlockchainID":"dXobeMTZB89Fy6E987aaRBDz2j8mVparqRRfvvmQDsH8haNJJ","warpMessageID":"2ZV5u7WPVozo386A3d8T5B81vAKvcSDdNsggpmHFvihy5Yut1S","teleporterMessageID":"Hqr8jHV4NjTf4sbCoGqNJEuntm8QoWnDXdivFNLizAzFxRxm3"}
-{"level":"info","timestamp":"2024-07-11T01:43:59.063Z","logger":"awm-relayer","caller":"evm/destination_client.go:192","msg":"Sent transaction","txID":"0x291bc3a3784dd79871cf4f95ba8f3fb3519e25c73848ee27bc5ebd7e3fe178d5","nonce":0}
-{"level":"info","timestamp":"2024-07-11T01:43:59.266Z","logger":"awm-relayer","caller":"teleporter/message_handler.go:250","msg":"Delivered message to destination chain","destinationBlockchainID":"dXobeMTZB89Fy6E987aaRBDz2j8mVparqRRfvvmQDsH8haNJJ","warpMessageID":"2ZV5u7WPVozo386A3d8T5B81vAKvcSDdNsggpmHFvihy5Yut1S","teleporterMessageID":"Hqr8jHV4NjTf4sbCoGqNJEuntm8QoWnDXdivFNLizAzFxRxm3","txHash":"0x291bc3a3784dd79871cf4f95ba8f3fb3519e25c73848ee27bc5ebd7e3fe178d5"}
-{"level":"info","timestamp":"2024-07-11T01:43:59.266Z","logger":"awm-relayer","caller":"relayer/application_relayer.go:246","msg":"Finished relaying message to destination chain","destinationBlockchainID":"dXobeMTZB89Fy6E987aaRBDz2j8mVparqRRfvvmQDsH8haNJJ"}
-```
\ No newline at end of file
diff --git a/content/course/interchain-messaging/11-restricting-the-relayer/01-restricting-the-relayer.mdx b/content/course/interchain-messaging/11-restricting-the-relayer/01-restricting-the-relayer.mdx
deleted file mode 100644
index d8410098..00000000
--- a/content/course/interchain-messaging/11-restricting-the-relayer/01-restricting-the-relayer.mdx
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Restricting a Relayer
-description: Learn about the basics of Avalanche.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
-
-In this segment, we'll delve into the mechanisms of restricting relayers for transmitting messages across Avalanche L1s. While the security in AWM and Interchain Messaging doesn't rely at all on the Relayer, there might be some reasons why you would want to restrict the delivery of the message to certain Relayers. 
-
-The more obvious one is when you run your own Relayer, and don't want to incentivize any other to ensure your message gets to the destination. On following sections you will learn how to run your own Relayer so you can restrict the messages to your own.
-
-## What You Will Learn
-
-In this section, you will go through the following topics:
-
-- **Allowed Relayers:** Learn how to restrict the relayer for transmitting messages across Avalanche L1s
-- **Dynamically update the allowed Relayers:** Understand how to update the allowed relayers dynamically
\ No newline at end of file
diff --git a/content/course/interchain-messaging/11-restricting-the-relayer/02-allowed-relayers.mdx b/content/course/interchain-messaging/11-restricting-the-relayer/02-allowed-relayers.mdx
deleted file mode 100644
index cee333c3..00000000
--- a/content/course/interchain-messaging/11-restricting-the-relayer/02-allowed-relayers.mdx
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: Allowed Relayer
-description: Learn about the basics of Avalanche.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-In this segment, we'll delve into the mechanisms of restricting relayers for transmitting messages across Avalanche L1s. While the security in AWM and Interchain Messaging doesn't rely at all on the Relayer, there might be some reasons why you would want to restrict the delivery of the message to certain Relayers. 
-
-The more obvious one is when you run your own Relayer, and don't want to incentivize any other to ensure your message gets to the destination. On following sections you will learn how to run your own Relayer so you can restrict the messages to your own.
-
-Let's look at the `TeleporterMessageInput` structure included when we call the `sendCrossChainMessage` one more time.
-
-```solidity
-struct TeleporterMessageInput {
-    bytes32 destinationBlockchainID;
-    address destinationAddress;
-    TeleporterFeeInfo feeInfo;
-    uint256 requiredGasLimit;
-    address[] allowedRelayerAddresses;
-    bytes message;
-}
-
-interface ITeleporterMessenger {
-    function sendCrossChainMessage(TeleporterMessageInput calldata messageInput)
-        external
-        returns (bytes32);
-}
-```
-
-As you can see the `TeleporterMessageInput` allows you to specify an array of addresses for the allowed relayers. Previously we have set that to an empty array, which means that any relayer can pick up the message.
-
-```solidity
-messenger.sendCrossChainMessage( 
-    TeleporterMessageInput({
-        // Replace with blockchainID of your Subnet (see instructions in Readme)
-        destinationBlockchainID: 0x3861e061737eaeb8d00f0514d210ad1062bfacdb4bd22d1d1f5ef876ae3a8921,
-        destinationAddress: destinationAddress, 
-        feeInfo: TeleporterFeeInfo({feeTokenAddress: address(0), amount: 0}),
-        requiredGasLimit: 100000,
-        allowedRelayerAddresses: new address[](0), // [!code highlight]
-        message: abi.encode(message)
-    })
-);
-```
-
-If you want to restrict the message to a certain relayer, you can simply add the address of the relayer to the array. A Relayer will be identified by the reward address it is associating each time it delivers a message.
-
-```solidity
-messenger.sendCrossChainMessage( 
-    TeleporterMessageInput({
-        // Replace with blockchainID of your Subnet (see instructions in Readme)
-        destinationBlockchainID: 0x3861e061737eaeb8d00f0514d210ad1062bfacdb4bd22d1d1f5ef876ae3a8921,
-        destinationAddress: destinationAddress, 
-        feeInfo: TeleporterFeeInfo({feeTokenAddress: address(0), amount: 0}),
-        requiredGasLimit: 100000,
-        allowedRelayerAddresses: [0x321f6B73b6dFdE5C73731C39Fd9C89c7788D5EBc], // [!code highlight]
-        message: abi.encode(message)
-    })
-);
-```
\ No newline at end of file
diff --git a/content/course/interchain-messaging/12-incentivizing-a-relayer/01-incentivizing-a-relayer.mdx b/content/course/interchain-messaging/12-incentivizing-a-relayer/01-incentivizing-a-relayer.mdx
deleted file mode 100644
index 90258111..00000000
--- a/content/course/interchain-messaging/12-incentivizing-a-relayer/01-incentivizing-a-relayer.mdx
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Incentivizing a Relayer
-description: Learn how to add Relayer Incentives.
-updated: 2024-06-09
-authors: [andyvargtz]
-icon: Book
----
-
-You already mastered how to send messages from one chain to another, but we have been working under the assumption that all messages will be picked by the Relayers. That is not always true, and external Relayers might want to have something in exchange for their services.
-
-Relayer fees are an optional way to incentivize relayers to deliver a Interchain Messaging message to its destination chain. They are not strictly necessary, and may be omitted if a relayer is willing to relay messages with no fee, such as with a self-hosted relayer. If the relayer is not self hosted though, user will need to incentivize them, since they need to pay the transaction fees on the destination chain
-
-## What you will learn
-
-- What is the data flow for fees
-- How to calculate an adecuate incentive amount
-- How to implement those incentives
-
-## Excersises
-
-In this section you will apply the learned knowledge by calculating and adding fees to our basic send-receive contracts used in the [Interchain Messaging Basics chapter](/course/interchain-messaging/04-icm-basics/01-icm-basics).
\ 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
deleted file mode 100644
index c68e95b8..00000000
--- a/content/course/interchain-messaging/12-incentivizing-a-relayer/02-fee-data-flow.mdx
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: Fee Data Flow
-description: Learn the logic behind the fee incentivization.
-updated: 2024-06-09
-authors: [andyvargtz]
-icon: BookOpen
----
-
-The basic idea of incentivizing an external AWM Relayer to relay our message is to deposit an amount of an ERC-20 token into the Interchain Messaging contract as a reward for whichever relayer delivers our message.
-
-Let's see how the fees are transferred from the user at the very beginning of sending a Cross Chain message, up to the point where the relayer is able to claim the fee.
-![AWM Relayer with fees data flow](/common-images/teleporter/teleporter-fees-receipt.png)
-
-
-We are using the following emoji guide to show the actors of each action:
-
-
-**👩 User**
-
-**📜 Cross-Chain dApp**
-
-**👾 TeleporterMessenger**
-
-**🛸 Relayer**
-
-### Previous to Sending the Message:
-
-- 👩 The message sender (user) requires to approve the Cross-Avalanche L1 dApp as a spender on the ERC20 contract to be used as fee.
-
-### Sending the Message:
-
-- 👩 User sends a message.
-- 📜 Fee funds (previously approved) are transferred from the user's wallet to the Cross-Chain dApp.
-- 📜 Cross-Chain dApp approves the Interchain Messaging Contract to spend the ERC20 fee tokens.
-- 👾 Fee tokens are transferred into the Interchain Messaging Contract.
-- 👾 Interchain Messaging assigns a unique ID to the Message and keeps track of the fee Info.
-- 🛸 Relayer can now pick and deliver the Message.
-
-### Message Delivered in the Destination Chain:
-
-- 👾 Interchain Messaging in the Destination Chain generates a receipt with the `messageID` and Relayer address who delivered the message.
-- Receipt is sent back to the Source Chain.
-- 🛸 Relayers can send the receipts back to the Source Chain themselves or wait until a new (unrelated) message is sent now from the once Destination Chain to the former Source chain. Messages include up to 5 pending receipts in a message.
-
-### Once Message is Received in the Source Chain:
-
-- 👾 The Interchain Messaging marks the `messageID` as received and increases the Relayer redeemable reward.
-- 🛸 The relayer can now claim its unlocked rewards.
-
-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.
-
-<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
deleted file mode 100644
index 9cc34044..00000000
--- a/content/course/interchain-messaging/12-incentivizing-a-relayer/03-determining-the-fee-amount.mdx
+++ /dev/null
@@ -1,63 +0,0 @@
----
-title: Determining the Fee
-description: Calculate a fair incentive amount.
-updated: 2024-06-09
-authors: [andyvargtz]
-icon: BookOpen
----
-
-## Economic Considerations for Relayers
-
-### Determining Relayer Incentives
-
-The first question to address is: How much should you pay a Relayer to ensure they are incentivized to deliver the message? The answer is straightforward but requires some analysis. The incentive should at least cover the expenses the Relayer will incur by delivering your message.
-
-As mentioned in previous lessons, a message will be considered delivered in the destination Chain if the Relayer sends at least the `requiredGasLimit` stated in the message, regardless of whether the execution succeeds or fails. Thus, the associated cost in $USD (or another asset like AVAX) that the Relayer will face to deliver your message is:  
-
-*Cost = requiredGasLimit * gas_price_in_native_token * native_token_price*
-
-While the income the Relayer will be paid for delivering your message is:  
-
-*Income = Fee_Amount * ERC20_Price*
-
-Excluding the Relayer's hosting costs, any Fee amount where *Costs < Income* will be profitable for the Relayer. Different types of messages or actions available in a cross-chain dApp may require different amounts of gas to deliver successfully. For instance, in a cross-chain ERC20 minter, creating the token contract is more expensive than minting new tokens, simply because creation requires deploying a new contract. Thus, it makes sense to reward the Relayer with a higher amount for delivering a creation message compared to a minting message (assuming both `requiredGasLimit` are set accordingly).
-
-### Example Calculation
-
-Let's calculate the minimum fee that could incentivize a Relayer to pick and deliver a message.
-
-To simplify, consider the following assumptions:
-- We are sending a message from C-Chain to Dispatch.
-- ERC20 incentives will be paid in TLP.
-- DIS is the fee token in Bulletin.
-- Assume *DIS_price = TLP_price*.
-- Relayer will only take your message if it can make at least 10% profit.
-- The `requiredGasLimit` for sending our message is 10,000 gas units.
-- Gas price in Dispatch = 50 nDIS (DIS * 10^-9).
-
-### Calculating the Fee
-
-The cost of relaying this message will be:  
-
-*Cost = 10,000 * 50 * DIS_price*
-
-The Relayer will take your message only if it can make a 10% profit:  
-
-*Income = 1.1 * Cost*
-
-Therefore:  
-
-*TLP_price * Amount = 1.1 * 10,000 * 50 * DIS_price*
-
-Knowing that *TLP_price = DIS_price*:  
-
-*Amount = 1.1 * 10,000 * 50*
-
-Then:  
-
-*Amount = 550,000 nTLP*  
-*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/12-incentivizing-a-relayer/04-setting-incentives.mdx b/content/course/interchain-messaging/12-incentivizing-a-relayer/04-setting-incentives.mdx
deleted file mode 100644
index 664b143b..00000000
--- a/content/course/interchain-messaging/12-incentivizing-a-relayer/04-setting-incentives.mdx
+++ /dev/null
@@ -1,43 +0,0 @@
----
-title: Setting Incentives
-description: Learn where incentives details need to be included
-updated: 2024-06-09
-authors: [andyvargtz]
-icon: BookOpen
----
-
-As we studied in previous lessons, the `sendCrossChainMessage` function takes `TeleporterMessageInput` struct as an input. The fields feeInfo in the `TeleporterMessageInput` will be a `TeleporterFeeInfo` struct formed by the ERC20 contract address in which the fee will be paid, as well as the amount of tokens to incentivize the relayer. This amount needs to be set in wei units. 
-
-Let's take a look at it:
-
-```solidity
-// (c) 2023, Ava Labs, Inc. All rights reserved.
-// See the file LICENSE for licensing terms.
-
-// SPDX-License-Identifier: Ecosystem
-
-pragma solidity 0.8.18;
-
-struct TeleporterMessageInput {
-    bytes32 destinationBlockchainID;
-    address destinationAddress;
-    TeleporterFeeInfo feeInfo; // [!code highlight]
-    uint256 requiredGasLimit; 
-    address[] allowedRelayerAddresses;
-    bytes message;
-}
-
-struct TeleporterFeeInfo {
-    address contractAddress; // [!code highlight]
-    uint256 amount; // [!code highlight]
-}
-
-interface ITeleporterMessenger {
-    function sendCrossChainMessage(TeleporterMessageInput calldata messageInput)
-        external
-    returns (bytes32);
-}
-```
-As you can see, the `TeleporterMessageInput` now needs to include the ERC20 address that will pay the incentives and the amount, all this as part of the `TeleporterFeeInfo`
-
-
diff --git a/content/course/interchain-messaging/12-incentivizing-a-relayer/05-deploy-fee-token-contract.mdx b/content/course/interchain-messaging/12-incentivizing-a-relayer/05-deploy-fee-token-contract.mdx
deleted file mode 100644
index 6331a702..00000000
--- a/content/course/interchain-messaging/12-incentivizing-a-relayer/05-deploy-fee-token-contract.mdx
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title: Deploy Fee Token Contract
-description: Deploy an ERC20 to work as the Fee Token for incentives.
-updated: 2024-06-09
-authors: [andyvargtz]
-icon: Terminal
----
-import { Steps, Step } from 'fumadocs-ui/components/steps';
-
-
-To add incentives for a relayer we need to specify the ERC20 contract we will be incentivizing with. Since we are working with an almost clean network deployed locally, we will need to first deploy this contract to later use it as the incentive token. 
-
-Incentives are set with ERC20 tokens deployed on the Source chain, in this case our local C-Chain. While this token can be a wrapped version of the native token, for this example we will be using just a simple ERC20 included as demo in the Avalanche-CLI. Let's deploy and mint some of these FEE tokens to later be used to incentivize the relayer.
-
-
-<Steps>
-<Step>
-
-### Deploy your Fee Token Contract
-
-```bash
-avalanche contract deploy erc20
-```
-This command will deploy a demo ERC20. Add the following configuration
-
-```bash
-✔ Local Network
-✔ C-Chain
-
-A private key is needed to pay for the contract deploy fees.
-It will also be considered the owner address of the contract, beign able to call
-the contract methods only available to owners.
-
-✔ Use the private key of the Genesis Allocated address 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-
-Which is the token symbol?
-Token symbol: FEE
-Which is the total token supply?
-Token supply: 100000
-Which address should receive the supply?
-
-✔ Use the Genesis Allocated address 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-
-Token Address: 0x768AF58E63775354938e9F3FEdB764F601c038b4
-
-ERC20 Contract Successfully Deployed!
-```
-
-</Step>
-<Step>
-
-### Save the ERC20 Address
-
-```bash
-export ERC20_fee_address=0x768AF58E63775354938e9F3FEdB764F601c038b4
-```
-
-</Step>
-</Steps>
diff --git a/content/course/interchain-messaging/12-incentivizing-a-relayer/06-incentivize-an-awm-relayer.mdx b/content/course/interchain-messaging/12-incentivizing-a-relayer/06-incentivize-an-awm-relayer.mdx
deleted file mode 100644
index 926dbcec..00000000
--- a/content/course/interchain-messaging/12-incentivizing-a-relayer/06-incentivize-an-awm-relayer.mdx
+++ /dev/null
@@ -1,58 +0,0 @@
----
-title: Incentivize an AWM relayer
-description: Add incentives to the basic send-receive contracts.
-updated: 2024-06-09
-authors: [andyvargtz]
-icon: Terminal
----
-
-## Add Incentives to our Sender Contract
-
-Now that we have an ERC20 token deployed and some of those tokens in our account to incentivize our relayer, let's include the incentive in our Sender contract.
-
-In the following contract, make sure to update `destinationBlockchainID` with your current deployment
-
-```solidity title="contracts/interchain-messaging/incentivize-relayer/senderWithFees.sol"
-// (c) 2023, Ava Labs, Inc. All rights reserved.
-// See the file LICENSE for licensing terms.
-
-// SPDX-License-Identifier: Ecosystem
-
-pragma solidity ^0.8.18;
-
-import "@teleporter/ITeleporterMessenger.sol";
-import {IERC20} from "@openzeppelin/contracts@4/token/ERC20/IERC20.sol"; // [!code highlight]
-
-contract SenderWithFeesOnCChain {
-    ITeleporterMessenger public immutable messenger = ITeleporterMessenger(0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf);
-    /**
-     * @dev Sends a message to another chain.
-     */
-    function sendMessage(address destinationAddress, string calldata message, address feeAddress) external {
-        IERC20 feeContract = IERC20(feeAddress); // [!code highlight]
-        uint256 feeAmount = 500000000000000; // [!code highlight]
-        feeContract.transferFrom(msg.sender, address(this), feeAmount);// [!code highlight]
-        feeContract.approve(address(teleporterMessenger),feeAmount); // [!code highlight]
-
-        messenger.sendCrossChainMessage(
-            TeleporterMessageInput({
-                // Replace with blockchainID of your L1 (see instructions in Readme)
-                destinationBlockchainID: 0x108ce15038973062d8628fd20c8c657effe993dd8324297353e350dfc05dacad,
-                destinationAddress: destinationAddress,
-                feeInfo: TeleporterFeeInfo({feeTokenAddress: feeAddress, amount: feeAmount}), // [!code highlight]
-                requiredGasLimit: 100000,
-                allowedRelayerAddresses: new address[](0),
-                message: abi.encode(message)
-            })
-        );
-    }
-}
-```
-
-Notice, our contract implementing Fees now needs to include the functionality we described in the fee flow section:
-
-- Import `IERC20` and create the fee contract interface instance 
-- 📜The Cross-Avalanche L1 dApp transfers the ERC20 fee amount to the control of the Cross-Chain dApp contract.
-- 📜Cross-Avalanche L1 dApp needs to implement the approval for the Interchain Messaging contract of these ERC20 tokens.
-- Include the `TeleporterFeeInfo` struct in the message. 
-
diff --git a/content/course/interchain-messaging/12-incentivizing-a-relayer/07-interaction-flow-with-fees.mdx b/content/course/interchain-messaging/12-incentivizing-a-relayer/07-interaction-flow-with-fees.mdx
deleted file mode 100644
index 17a63b2f..00000000
--- a/content/course/interchain-messaging/12-incentivizing-a-relayer/07-interaction-flow-with-fees.mdx
+++ /dev/null
@@ -1,109 +0,0 @@
----
-title: Interaction Flow With Fees
-description: Go trhough the complete deployment flow and send an incentivized message.
-updated: 2024-06-09
-authors: [andyvargtz]
-icon: Terminal
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-Now we have all the Smart Contract 📜 set we can start sending incentivized cross-chain messages. Now let complete the flow 
-
-- Deploy sender contract on C-Chain
-- Deploy receiver contract on `myblockchain`
-- Approve the sender contract to spend ERC20 funds from the message sender address
-- Send the message
-
-<Steps>
-<Step>
-
-### Deploy Sender Contract 
-
-To deploy the sender contract run:
-
-```bash
-forge create --rpc-url local-c --private-key $PK contracts/interchain-messaging/incentivize-relayer/senderWithFees.sol:SenderWithFeesOnCChain
-```
-```
-[⠊] Compiling...
-[⠒] Compiling 2 files with Solc 0.8.18
-[⠢] Solc 0.8.18 finished in 92.98ms
-Compiler run successful!
-Deployer: 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-Deployed to: 0xa4DfF80B4a1D748BF28BC4A271eD834689Ea3407 // [!code highlight]
-Transaction hash: 0xb0ff20527818fcc0836944a13ddb3b336b95047d434bb52f6c064ab407950166
-```
-
-</Step>
-<Step>
-### Save the Sender Contract Address
-
-```bash
-export SENDER_ADDRESS=0xa4DfF80B4a1D748BF28BC4A271eD834689Ea3407
-```
-
-</Step>
-<Step>
-
-### Deploy Receiver Contract
-
-Now, deploy the receiver contract.
-
-```bash
-forge create --rpc-url myblockchain --private-key $PK contracts/interchain-messaging/incentivize-relayer/receiverWithFees.sol:ReceiverOnSubnet
-```
-```
-[⠊] Compiling...
-[⠢] Compiling 1 files with Solc 0.8.18
-[⠆] Solc 0.8.18 finished in 105.36ms
-Compiler run successful!
-Deployer: 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-Deployed to: 0xe336d36FacA76840407e6836d26119E1EcE0A2b4 // [!code highlight]
-Transaction hash: 0x379f0a4b875effc9b80a33f039d9a49404514e7aabaef4490f57b56fb4818f65
-```
-
-</Step>
-<Step>
-
-### Save the Receiver Contract Address
-
-```bash
-export RECEIVER_ADDRESS=0xe336d36FacA76840407e6836d26119E1EcE0A2b4
-```
-
-</Step>
-<Step>
-
-### Approve ERC20 Token Expense
-
-👩 The Message Sender (User) requires to approve the Cross-Avalanche L1 dApp as a spender on the ERC20 contract to be used as fee. To do that lets use the function "approve" on our deployed FEE contract.
-
-```bash
-cast send --rpc-url local-c --private-key $PK $ERC20_fee_address "approve(address,uint256)" $SENDER_ADDRESS 500000000000000
-```
-
-</Step>
-<Step>
-
-### Send an incentivized message
-
-```bash
-cast send --rpc-url local-c --private-key $PK $SENDER_ADDRESS "sendMessage(address, string, address)" $RECEIVER_ADDRESS "Hello" $ERC20_fee_address
-```
-
-</Step>
-<Step>
-
-### Verify message was received on Avalanche L1 
-
-```bash
-cast call --rpc-url myblockchain $RECEIVER_ADDRESS "lastMessage()(string)"
-```
-```bash
-"Hello"
-```
-
-**Success!** The message was received on the destination chain while incentivizing the Relayer.
-
-</Step>
-</Steps>
\ No newline at end of file
diff --git a/content/course/interchain-messaging/13-registering-validator/registering-validator.mdx b/content/course/interchain-messaging/13-registering-validator/registering-validator.mdx
deleted file mode 100644
index 0fe172cc..00000000
--- a/content/course/interchain-messaging/13-registering-validator/registering-validator.mdx
+++ /dev/null
@@ -1,130 +0,0 @@
----
-title: Registering Validators
-description: Learn how validators are registered on the Avalanche network post-etna.
-updated: 2024-10-14
-authors: [owenwahlgren]
-icon: Terminal
----
-
-> How does it all work? I mean *actually* work.
-
-### Sending Warp Messages
-
-On the EVM, a warp message is simply an event log with `messageID = sha256(messagePayload)` Nothing is ever actually “sent” anywhere, which trips people up when first learning how Warp Messaging works.
-
-The log event emitted is from the Warp precompile address (`0x0200000000000000000000000000000000000005`) The topic of the message will be `0x56600c567728a800c0aa927500f831cb451df66a7af570eb4df4dfbf4674887d` which is the output of 
-```bash
-cast keccak "SendWarpMessage(address,bytes32,bytes)"
-```
-
-To find a specific warp messageID, one must know the block number or block hash to retrieve the logs, or be monitoring all events, looking for and indexing messages. 
-
-When a block is [accepted](https://github.com/ava-labs/coreth/blob/7242ae2d235593d2bb14e2496b6ed102aab14c3d/precompile/contracts/warp/config.go#L130) by the network, a precompile hook is called, and the EVM saves the warp message to a local database. The validator node will then be willing to sign any messages in that database upon request, typically via an `AppRequest` message over the p2p network.
-
-### Receiving Warp Messages
-
-On the EVM, any smart contract can call the precompile
-
-which returns the warp message and verifies the attached signature. But what is `index`? Where does it get the warp message from?  The answer is, you!  When you send a tx to any contract that eventually calls `getVerifiedWarpMessage`, you **must** pass in the signed warp message as a “predicate”.  It’s called an AccessList, and typically this is an optional field that can be used by the EVM to pre-fetch storage slots that will be accessed, for efficiency and reducing gas costs. But Warp cleverly (ab)uses this feature of the EVM to verify the signature of the warp message, and then make the warp message available during the transactions lifetime, by calling `getVerifiedWarpMessage`. You can pass multiple warp messages which is where the `index` comes in.  (All of this is abstracted away by Teleporter for EVM to EVM comms)
-
-Details: [Warp README](https://github.com/ava-labs/coreth/blob/7242ae2d235593d2bb14e2496b6ed102aab14c3d/precompile/contracts/warp/README.md)
-
-### Teleporter
-
-[Teleporter](https://github.com/ava-labs/teleporter) is a set of smart contracts that implements a rich messaging protocol on top of the Warp Messaging primitive, allowing for verified message passing between EVM chains. 
-
-<Callout>
-**Only (currently) supports EVM→EVM comms. Not used for EVM→P-Chain**
-</Callout>
-
-### Relayer
-
-[Relayer](https://github.com/ava-labs/awm-relayer/blob/main/relayer/README.md) is an off-chain program that listens for warp messages on a source chain, and delivers them to a destination chain.  Messages can choose to be relayed by anyone, or by only privileged relayers. Messages can also pay fees to incentivize relayers and cover gas costs.
-
-## Registering ValidatorManager
-
-ACP-77 introduces L1-only Validators, that stake no AVAX, and do not validate the X/C chains. They must connect to the Primary Network and track the P-Chain, and also validate their own chain, and pay a small continuous fee in AVAX to the network.
-
-User submits EVM tx to smart contract [NativeTokenStakingManager.sol](https://github.com/ava-labs/teleporter/blob/acp-77-updates/contracts/validator-manager/NativeTokenStakingManager.sol)
-
-```solidity
-function initializeValidatorRegistration(
-        ValidatorRegistrationInput calldata registrationInput,
-        uint16 delegationFeeBips,
-        uint64 minStakeDuration) payable returns (bytes32 validationID)
-```
-Notably, this function will:
-
-- Lock the native tokens in the contract
-- `validationID`: bytes32 hash of an encoded `RegisterSubnetValidatorMessage`
-- `messageID`: bytes32 hash of the warp message
-- Store some data in the contract:
-
-
-```solidity
-$._pendingRegisterValidationMessages[validationID] = registerSubnetValidatorMessage;
-$._registeredValidators[input.nodeID] = validationID;
-bytes32 messageID = WARP_MESSENGER.sendWarpMessage(registerSubnetValidatorMessage);
-$._validationPeriods[validationID] = Validator({
-  status: ValidatorStatus.PendingAdded,
-  nodeID: input.nodeID,
-  startingWeight: weight,
-  messageNonce: 0,
-  weight: weight,
-  startedAt: 0, // The validation period only starts once the registration is acknowledged.
-  endedAt: 0
-});
-```
-
-- Emit `ValidationPeriodCreated(validationID, nodeID, messageID, weight, registrationExpiry)`
-- The `sendWarpMessage` precompile will emit a log with `sender`, `messageID`, `message`
-
-At this point, we have submitted a transaction on the blockchain (C-Chain or L1, wherever the staking contract is deployed). All that has happened is we have stored some state in our contract and emitted some events. No changes to validators has occurred.
-
-<Callout>
-Nothing else will happen UNLESS an off-chain actor continues the process.
-</Callout>
-
-
-In our case, someone must be running a relayer that is configured with our staking contract as the source and the P-Chain as the destination.
-
-<Callout>
-At the moment, the relayer does not support the P-Chain, so messages must be signed and sent manually. The relayer will be updated soon to support the P-Chain.
-</Callout>
-
-
-So, to sign and send the message ourselves, we can use the Signature Aggregator server in the relayer project. This will use the p2p layer of the Avalanche network to connect to validators and send `AppRequest` messages to request each validator to sign a message.
-```bash
-curl --location 'http://localhost:8080/aggregate-signatures' \
---json '{"message": "<hex encoded unsigned message bytes retrieved from the logs>"}'
-```
-This will give us an aggregated BLS signature from at least 67% of the stake weighted validator set. Now we need to `POST` this to the P-Chain via the `RegisterSubnetValidatorTx` tx.
-
-The P-Chain, if it accepts the tx, will “send” a Warp Message `SubnetValidatorRegistration` which acknowledges the change. Note that nothing is actually “sent”, instead the validator node will be willing to sign the unsigned message upon request.
-
-So the next step is to use the Signature Aggregator service again, and provide the unsigned `SubnetValidatorRegistration` warp message, which the service will then ask validators to sign.
-
-<Callout>
-If your Validator Manager contract is on your L1 (instead of C-Chain), as an optimization, you only need to ask 67% of the stake weighted validators of your L1, not the entire P-Chain validator set.
-</Callout>
-
-
-Once an aggregate BLS signature is created, we need to submit the signed message to the C-Chain (or L1) by calling a function on the `ValidatorManager` contract.
-
-```solidity
-function completeValidatorRegistration(uint32 messageIndex)
-```
-
-Remember, this involves calling the function via `eth_sendTransaction` and encoding the signed warp message into the `AccessList`. (If you encode an array of 1 warp message, then `messageIndex` would be 0)
-
-The function will adjust the state in the contract, including these bits:
-```solidity
-delete $._pendingRegisterValidationMessages[validationID];
-$._validationPeriods[validationID].status = ValidatorStatus.Active;
-$._validationPeriods[validationID].startedAt = uint64(block.timestamp);
-```
-And that’s it!
-
-<Callout>
-This doc is a WIP and we will eventually cover all the flows and add some diagrams.
-</Callout>
diff --git a/content/course/interchain-messaging/certificate.mdx b/content/course/interchain-messaging/certificate.mdx
deleted file mode 100644
index c2c1726d..00000000
--- a/content/course/interchain-messaging/certificate.mdx
+++ /dev/null
@@ -1,14 +0,0 @@
----
-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/index.mdx b/content/course/interchain-messaging/index.mdx
deleted file mode 100644
index 9dd58727..00000000
--- a/content/course/interchain-messaging/index.mdx
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: Welcome to the course
-description: Learn about Interchain Messaging, the interoperability protocol of Avalanche.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Smile
----
-
-In this course, you will learn how to build cross-L1 Solidity dApps with Interchain Messaging and Avalanche Warp Messaging.
-
-## Why Take This Course?
-
-A significant innovation in blockchain is the development of multi-chain systems, like Avalanche, which provide a significant improvement in scalability, interoperability, and flexibility. At the core of these multi-chain systems is the ability to run multiple blockchains that communicate. Each chain's VM is optimized for specialized use cases, thereby boosting the network's overall performance.
-
-Cross-chain communication is a crucial building block of multi-chain systems. Utilizing Interchain Messaging and Avalanche Warp Messaging is an incredible easy way to build cross-L1 dApps, since developers can build on top an extensive and audited development framework. 
-
-## Course Content
-
-Below you can find a 30 minute recording of a presentation about Avalanche Warp Messaging and Teleporter. This summarizes the content of the first chapters:
-
-<YouTube id="N6F7D4Hb87c"/>
-
-### Interoperability 
-
-In the first section, we cover some basic concepts of interoperability in multi-chain systems. You will learn about examples of interoperability between blockchains and the terms "source," "destination," and "message."
-
-### Avalanche Interchain Messaging
-
-In this section, we learn what Avalanche Interchain Messaging is and what is abstracted away from the general dApp developer. You will also build your first cross-L1 dApps.
-
-### Securing Cross-Chain Communication
-
-In this section, we look at techniques to secure cross-chain communication. We dive into signature schemes, multi-signature schemes, and the BLS multi-signature scheme.
-
-### Avalanche Interchain Messaging Protocol
-
-Avalanche blockchains can natively interoperate between one another using AWM. You will learn about the AWM message format and how the message flow works.
-
-## Prerequisites
-
-### Avalanche
-
-This course is meant for people with a solid understanding of the basic concepts of Avalanche. You should be familiar with these concepts:
-
-- **Virtual Machines:** What they are and what VM customization means
-- **Avalanche L1s & Blockchains:** What the difference between a VM, Blockchain, and an Avalanche L1 is
-
-If any of this is unclear, we strongly recommend taking the Avalanche Fundamentals and Multi-Chain Architecture courses first.
-
-### Software Development
-
-You will need a general understanding of Software Development. You won't have to write a lot of code, but you will have to understand some. Therefore, we recommend:
-
-- **Solidity:** Familiarity with most concepts of the language. All exercises will mainly consist of writing cross-subnet dApps in Solidity.
-- **Docker:** The advanced exercises in the latter part of the course will occur in contained environments for easy setup. It will help if you're generally familiar with the concept of containerization, docker, and docker compose.
-- **Testing:** Having some experience or familiarity with unit testing is ideal.
-
-## Learning Outcomes
-
-By the end of this course, students will:
-
-- Understand the challenges of cross-chain communication
-- Know what separates Avalanche Warp Messaging from other cross-chain communication protocols
-- Understand the differences between Avalanche Warp Messaging and Teleporter
-- Apply their knowledge by building cross-Avalanche L1 dApps, such as asset bridges
-
-Overall, this course aims to provide an advanced understanding of Teleporter. By completing this course, students will be better prepared to build advanced cross-Avalanche L1 blockchain applications.
\ No newline at end of file
diff --git a/content/course/interchain-messaging/meta.json b/content/course/interchain-messaging/meta.json
deleted file mode 100644
index f1be9146..00000000
--- a/content/course/interchain-messaging/meta.json
+++ /dev/null
@@ -1,33 +0,0 @@
-{
-  "title": "Interchain Messaging",
-  "root": true,
-  "pages": [
-    "index",
-    "---Interoperability between Blockchains---",
-    "...02-interoperability",
-    "---Avalanche Starter Kit---",
-    "...03-avalanche-starter-kit",
-    "---Interchain Messaging Basics---",
-    "...04-icm-basics",
-    "---Two-Way Communication---",
-    "...05-two-way-communication",
-    "---Invoking Functions---",
-    "...06-invoking-functions",
-    "---Interchain Messaging Registry---",
-    "...07-icm-registry",
-    "---Securing Cross-Chain Communication---",
-    "...08-securing-cross-chain-communication",
-    "---Avalanche Warp Messaging---",
-    "...09-avalanche-warp-messaging",
-    "---Running a Relayer---",
-    "...10-running-a-relayer",
-    "---Restricting-the-relayer---",
-    "...11-restricting-the-relayer",
-    "---Incentivizing a Relayer---",
-    "...12-incentivizing-a-relayer",
-    "---P-Chain Messaging---",
-    "...13-registering-validator",
-    "---Conclusion---",
-    "certificate"
-  ]
-}
diff --git a/content/course/interchain-token-transfer/02-avalanche-starter-kit/01-avalanche-starter-kit.mdx b/content/course/interchain-token-transfer/02-avalanche-starter-kit/01-avalanche-starter-kit.mdx
deleted file mode 100644
index 1be186b6..00000000
--- a/content/course/interchain-token-transfer/02-avalanche-starter-kit/01-avalanche-starter-kit.mdx
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Avalanche Starter Kit
-description: Environment Setup
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
-
-To make easier your journey through this course, we have prepared a Starter Kit repo consisting of everything you will need to start developing your own dApps on Avalanche. This repo will provide a self-contained environment with Avalanche-CLI, and Foundry so you can follow the course without the need of installing anything else other than launching the environment.
-
-## What You Will Learn
-
-In this section, you will go through the following topics:
-
-- How to launch your own Codespace
-- Create your own Interchain Messaging Enabled Custom Blockchain
-- Foundry configuration
-
-At the end of this section, you will have your environment ready to follow with the Cross-Chain dApp development with Interchain Messaging 
\ No newline at end of file
diff --git a/content/course/interchain-token-transfer/02-avalanche-starter-kit/02-set-up.mdx b/content/course/interchain-token-transfer/02-avalanche-starter-kit/02-set-up.mdx
deleted file mode 100644
index df333867..00000000
--- a/content/course/interchain-token-transfer/02-avalanche-starter-kit/02-set-up.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Set Up Avalanche Starter Kit
-description: Environment Setup
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-import SetUp from "@/content/common/avalanche-starter-kit/set-up.mdx";
-
-<SetUp />
\ No newline at end of file
diff --git a/content/course/interchain-token-transfer/02-avalanche-starter-kit/03-close-and-reopen-codespace.mdx b/content/course/interchain-token-transfer/02-avalanche-starter-kit/03-close-and-reopen-codespace.mdx
deleted file mode 100644
index ffee101e..00000000
--- a/content/course/interchain-token-transfer/02-avalanche-starter-kit/03-close-and-reopen-codespace.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Close and Reopen Codespace
-description: Environment Setup
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-import CloseAndReopen from "@/content/common/codespaces/close-and-reopen-codespace.mdx";
-
-<CloseAndReopen />
\ No newline at end of file
diff --git a/content/course/interchain-token-transfer/02-avalanche-starter-kit/03-create-blockchain.mdx b/content/course/interchain-token-transfer/02-avalanche-starter-kit/03-create-blockchain.mdx
deleted file mode 100644
index 6e251d21..00000000
--- a/content/course/interchain-token-transfer/02-avalanche-starter-kit/03-create-blockchain.mdx
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Create a Blockchain
-description: Environment Setup
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-import CreateDefaultBlockchain from "@/content/common/avalanche-starter-kit/create-default-blockchain.mdx";
-
-In order to send messages between two chains, we need to create a blockchain. In this guide, we will spin up a local Avalanche network that has it's own Primary Network (C-, P- and X-Chain) using the Avalanche CLI. Furthermore, we will create a blockchain in that Avalanche network, so we can send messages between the C-Chain and the newly created blockchain in the next chapters.
-
-<CreateDefaultBlockchain/>
\ No newline at end of file
diff --git a/content/course/interchain-token-transfer/02-avalanche-starter-kit/04-networks.mdx b/content/course/interchain-token-transfer/02-avalanche-starter-kit/04-networks.mdx
deleted file mode 100644
index b7f96423..00000000
--- a/content/course/interchain-token-transfer/02-avalanche-starter-kit/04-networks.mdx
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Networks
-description: Environment Setup
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-import Networks from "@/content/common/avalanche-starter-kit/networks.mdx";
-
-You just deployed and interacted with your first local network. But what does that mean? You can interact with your Avalanche L1, but you will notice that no one else can. Therefore, we have to understand what different Networks are in Avalanche.
-
-<Networks/>
\ No newline at end of file
diff --git a/content/course/interchain-token-transfer/02-avalanche-starter-kit/05-foundry-quickstart.mdx b/content/course/interchain-token-transfer/02-avalanche-starter-kit/05-foundry-quickstart.mdx
deleted file mode 100644
index 86f6fcfe..00000000
--- a/content/course/interchain-token-transfer/02-avalanche-starter-kit/05-foundry-quickstart.mdx
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Foundry Quickstart
-description: Environment Setup
-updated: 2024-05-31
-authors: [martineckardt]
-icon: BookOpen
----
-
-import FoundryQuickstart from "@/content/common/avalanche-starter-kit/foundry-quickstart.mdx";
-
-In this chapter, we will look into the Foundry that will be used to deploy and interact with smart contracts on the Avalanche network in our Avalanche Starter kit.
-
-<FoundryQuickstart/>
\ No newline at end of file
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
deleted file mode 100644
index c734a718..00000000
--- a/content/course/interchain-token-transfer/02-avalanche-starter-kit/06-pause-and-resume.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-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/03-tokens/01-tokens.mdx b/content/course/interchain-token-transfer/03-tokens/01-tokens.mdx
deleted file mode 100644
index 38002f14..00000000
--- a/content/course/interchain-token-transfer/03-tokens/01-tokens.mdx
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Tokens
-description: Learn about tokens
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
-
-## What You Will Learn
-
-In this section, you will go through the following topics:
-
-- **What is a token**: Learn how tokens serve to represent ownership.
-- **Types of tokens**: Learn about ERC20 tokens, Native tokens and Wrapped tokens.
-- **Transfers**: Learn differences on transfering the different types of tokens between accounts or with smart contracts.
diff --git a/content/course/interchain-token-transfer/03-tokens/02-native-tokens.mdx b/content/course/interchain-token-transfer/03-tokens/02-native-tokens.mdx
deleted file mode 100644
index 474e4e9c..00000000
--- a/content/course/interchain-token-transfer/03-tokens/02-native-tokens.mdx
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: Native Tokens
-description: Understand the native token role in a blockchain system
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-A native token in a blockchain running the Ethereum Virtual Machine (EVM) refers to the primary digital currency or cryptocurrency native to the EVM blockchain. Every EVM layer 1 chain has it's own native token:
-
-- Ethereum: ETH
-- Avalanche C-Chain: AVAX
-- Dexalot: ALOT
-- many more...
-
-The native token serves as both a means of value transfer within the EVM network and as the gas token for executing transfers or smart contracts. Therefore, native tokens play a crucial role in the EVM chain by enabling participants to interact with and utilize the platform's decentralized features, serving as the foundational unit of value.
-<Quiz quizId="118" />
\ No newline at end of file
diff --git a/content/course/interchain-token-transfer/03-tokens/03-transfer-native-tokens.mdx b/content/course/interchain-token-transfer/03-tokens/03-transfer-native-tokens.mdx
deleted file mode 100644
index 0943b718..00000000
--- a/content/course/interchain-token-transfer/03-tokens/03-transfer-native-tokens.mdx
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: Transfer Native Tokens
-description: Interact with native tokens 
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-In this exercise, you will learn how to transfer native tokens on your own L1 in the Avalanche network using Foundry, a powerful toolkit for EVM application development. We will use the blockchain you have create in the last chapter.
-
-<Steps>
-<Step>
-
-## Create account
-```bash
-avalanche key create myAddress
-```
-
-</Step>
-<Step>
-
-### Save the Key to an Environment Variable
-
-Retrieve the new address with and store it in an environment variable to match the following commands.
- 
-```bash
-avalanche key list -l --blockchains myblockchain --keys myAddress
-```
-
-```bash
-export MYADDRESS=0x...
-```
-
-</Step>
-<Step>
-
-### Check the Balance
-
-Now we are checking the balance of that key on your L1. Make sure to replace the `--rpc-url` flag with appropriate name of your L1.
-
-```bash
-cast balance $MYADDRESS --rpc-url myblockchain
-```
-
-</Step>
-<Step>
-
-### Transfer funds
-
-```bash
-cast send $MYADDRESS --value 200000  --private-key $PK --rpc-url myblockchain
-```
-
-</Step>
-<Step>
-
-### Check balances to confirm transfer
-
-```bash
-cast balance $MYADDRESS --rpc-url myblockchain
-```
-
-</Step>
-</Steps>
-
-As you saw, funds were transfered from one count to another within the same chain (myblockchain)
diff --git a/content/course/interchain-token-transfer/03-tokens/05-transfers-in-smart-contracts.mdx b/content/course/interchain-token-transfer/03-tokens/05-transfers-in-smart-contracts.mdx
deleted file mode 100644
index 3350419a..00000000
--- a/content/course/interchain-token-transfer/03-tokens/05-transfers-in-smart-contracts.mdx
+++ /dev/null
@@ -1,103 +0,0 @@
----
-title: Transfers and Smart Contract
-description: Transfer native tokens to smart contracts
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-
-Now that you know how to transfer native assets between accounts, let's see how to to transfer those funds to the control of an smart contract. Payable smart contract functions are essential for this process, as they allow the contract to receive Native Tokens. A function marked as payable in Solidity signifies that the function can accept and process incoming funds. This is particularly useful for contracts that need to handle funds for instance any financial dApps, such as decentralized applications (dApps), automated market makers (AMMs), or transfering funds from one chain to another, like we do with Avalanche Interchain Token Transfer. 
-
-## Payable functions
-
-The `payable` keyword in Solidity is used to designate functions that are capable of receiving native blockchain tokens. When a function is marked as payable, it allows the contract to accept incoming funds and execute specific logic based on the amount received. Without the payable modifier, any attempt to send native tokens to a contract would result in an error, preventing the transaction from being processed.
-
-A function defined as payable serves multiple purposes. First, it signals to users and other contracts that the function is intended to handle incoming payments. This adds a layer of transparency and ensures that the contract’s behavior is clear and predictable. Second, it allows the function to access special variables such as msg.value, which holds the amount of Ether sent with the call. This can be used within the function to implement various logic, such as recording payments, issuing tokens in return, or triggering other contract behaviors.
-
-Here's an example of a simple payable function in Solidity:
-
-```solidity 
-pragma solidity ^0.8.0;
-
-contract PayableExample {
-    uint public amountReceived = 0 ;
-
-    function receiveNative() public payable {
-        amountReceived += msg.value;
-    }
-}
-```
-In this example, the receiveNative function is marked as payable, enabling it to accept the Native Token. The msg.value variable is used to add the amount of native token sent to the amountReceived state variable. This is a basic illustration, but it underscores how the payable keyword facilitates the handling of native token transfers within smart contracts.
-
-<Steps>
-
-<Step>
-### Create the working directory to store new contracts
-
-```bash
-mkdir -p src/my-contracts
-```
-</Step>
-
-<Step>
-### Copy the above example contract into `/src/my-contracts/PayableExample.sol`
-</Step>
-
-<Step>
-
-### Deploy Contract with Payable Function
-
-```bash
-forge create --rpc-url myblockchain --private-key $PK src/my-contracts/PayableExample.sol:PayableExample
-```
-
-</Step>
-<Step>
-
-### Save the Contract Address
-
-```bash
-export PAYABLE_CONTRACT=0X..
-
-```
-
-</Step>
-<Step>
-
-### Check `amountReceived`
-
-```bash
-cast call --rpc-url myblockchain $PAYABLE_CONTRACT "amountReceived()(uint)"
-```
-
-</Step>
-<Step>
-
-### Transfer Native Token to the Contract
-
-Now let's use solidity to transfer funds to our PayableExample contract
-
-```bash
-cast send --rpc-url myblockchain --private-key $PK $PAYABLE_CONTRACT "receiveNative()" --value 100000
-```
-
-</Step>
-<Step>
-
-### Check `amountReceived`
-```bash
-cast call --rpc-url myblockchain $PAYABLE_CONTRACT "amountReceived()(uint)"
-```
-
-</Step>
-</Steps>
-
-Well done! You transferred native tokens to a Smart Contract.
-
-It's important to understand the distinction between Native Tokens and ERC-20 tokens. Native tokens, such as `AVAX` or `ETH`, are transferred directly to payable functions within the smart contract. This process is straightforward and involves sending the tokens to the contract's address, invoking the payable function. 
-
-On the other hand, ERC-20 tokens require a different approach due to their standardized interface. We will cover that in the following sections.
-
-<Quiz quizId="119" />
diff --git a/content/course/interchain-token-transfer/03-tokens/07-erc-20-tokens.mdx b/content/course/interchain-token-transfer/03-tokens/07-erc-20-tokens.mdx
deleted file mode 100644
index 5c8d9fa4..00000000
--- a/content/course/interchain-token-transfer/03-tokens/07-erc-20-tokens.mdx
+++ /dev/null
@@ -1,74 +0,0 @@
----
-title: ERC-20 Tokens
-description: Learn about ERC-20 Standard for tokens
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-There is only a single native token to a chain. However, to allow to represent a wide range of assets on EVM-chains, the ERC-20 token standard was developed. "ERC" stands for Ethereum Request for Comment, and "20" is the proposal identifier.
-
-ERC-20 tokens are fungible, meaning each token is identical and can be exchanged on a one-to-one basis. These tokens are typically created and managed through smart contracts that adhere to the ERC-20 standard, which defines a set of rules and functions that ensure interoperability between different tokens and decentralized applications (DApps). 
-
-At the base of an ERC-20 token smart contract, there is a simple mapping of addresses to numbers, which represent the amount of tokens an address holds (balance). 
-
-```solidity
-abstract contract ERC20 is Context, IERC20, IERC20Metadata, IERC20Errors {
-    
-  mapping(address account => uint256) private _balances;
-	
-  //...
-}
-```
-These addresses may belong to EOA or contract accounts. Both of these can hold and transfer ERC-20 tokens. 
-
-ERC-20 tokens can represent various assets, from digital currencies to tokenized assets, and they play a crucial role in the crypto ecosystem by enabling the creation of decentralized applications with diverse functionalities, such as token sales, decentralized finance (DeFi) protocols, and more.
-
-## Interface
-
-To maintain compatibility with dApps designed to work with the ERC20 standard, all ERC20 tokens implement the following interface:
-
-```solidity
-interface IERC20 {
-
-    function name() external view returns (string memory);
-
-    function symbol() external view returns (string memory);
-
-    function decimals() external view returns (uint8);
-
-    function totalSupply() external view returns (uint256);
-
-    function balanceOf(address _owner) external view returns (uint256 balance);
-
-    function transfer(address _to, uint256 _value) external returns (bool success);
-
-    function transferFrom(address _from, address _to, uint256 _value) external returns (bool success);
-
-    function approve(address _spender, uint256 _value) external returns (bool success);
-
-    function allowance(address _owner, address _spender) external view returns (uint256 remaining);
-}
-```
-Click [here](https://eips.ethereum.org/EIPS/eip-20) to review the ERC20 standard in full detail.
-
-## Transfer Tokens
-
-Transferring ERC-20 tokens between accounts involves calling the 'transfer' function, specifying the recipient’s address and the amount to transfer. 
-
-To facilitate more complex interactions, such as those involving smart contracts, the ERC-20 standard includes the `approve()` and `transferFrom()` functions. We will check how to implement those so smart contracts can use funds according to its code.
-
-### `approve()`
-
-Since all balances are just a mapping of amount values to addresses, the owner of each address can 'approve' some other account as a _spender of their funds up to some limit determined by the approved _amount. The spender then will be able to withdraw from your account multiple times, up to the value set in amount.
-
-### `allowance()`
-
-Returns the amount which _spender is still allowed to withdraw from _owner.
-
-### `transferFrom()`
-
-Transfers _value amount of tokens from address _from to address _to
-
-
-<Quiz quizId="120" />
diff --git a/content/course/interchain-token-transfer/03-tokens/08-transfer-an-erc-20-token.mdx b/content/course/interchain-token-transfer/03-tokens/08-transfer-an-erc-20-token.mdx
deleted file mode 100644
index e53f65fe..00000000
--- a/content/course/interchain-token-transfer/03-tokens/08-transfer-an-erc-20-token.mdx
+++ /dev/null
@@ -1,109 +0,0 @@
----
-title: Deploy and Transfer an ERC-20 Token
-description: Transfer an ERC-20 token between accounts
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-<Steps>
-<Step>
-
-### Deploy ERC-20
-
-Let's deploy a basic demo ERC20 contract that comes integrated with the CLI on our Avalanche L1.
-
-```bash 
-avalanche contract deploy erc20
-```
-and follow this configuration:
-```bash 
-✔ Local Network
-✔ Avalanche L1 myblockchain
-A private key is needed to pay for the contract deploy fees.
-It will also be considered the owner address of the contract, beign able to call
-the contract methods only available to owners.
-Use the arrow keys to navigate: ↓ ↑ → ← 
-? Which private key do you want to use to deploy the contract?: 
-✔ Use the private key of the Genesis Allocated address 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-Which is the token symbol?
-Token symbol: TOK
-Which is the total token supply?
-Token supply: 1000000
-Which address should receive the supply?
-✔ Use the Genesis Allocated address 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-
-Token Address: 0x52C84043CD9c865236f11d9Fc9F56aa003c1f922
-
-ERC20 Contract Successfully Deployed!
-```
-
-</Step>
-<Step>
-
-### Save the Token Address
-
-```bash
-export ERC20_CONTRACT_L1=0x...
-```
-
-</Step>
-<Step>
-
-### Get Recepient Address
-
-Before transfering the assets you need to make sure you have at least one extra account created so you can transfer funds to it:
-
-```bash
-avalanche key list -l --blockchains myblockchain --tokens $ERC20_CONTRACT_L1,native  --keys myAddress,ewoq
-```
-
-You will get an output like this:
-
-```
-+--------+-------+----------+--------------------------------------------+---------------+-------------------+---------------+
-|  KIND  | NAME  |  SUBNET  |                  ADDRESS                   |     TOKEN     |      BALANCE      |    NETWORK    |
-+--------+-------+----------+--------------------------------------------+---------------+-------------------+---------------+
-| stored | myAddress | myblockchain | 0x302Ce9b6346E477ecb774aF73E908a4971B7ce2E | NAT (Native)  |         0 | Local Network |
-+        +       +          +--------------------------------------------+---------------+-------------------+---------------+
-|        |       |          | 0x302Ce9b6346E477ecb774aF73E908a4971B7ce2E | TOK (0x52C8.) |                 0 | Local Network |
-+        +-------+          +--------------------------------------------+---------------+-------------------+---------------+
-|        | ewoq  |          | 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC | NAT (Native)  |  999999.984293650 | Local Network |
-+        +       +          +--------------------------------------------+---------------+-------------------+---------------+
-|        |       |          | 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC | TOK (0x52C8.) | 1000000.000000000 | Local Network |
-+--------+-------+----------+--------------------------------------------+---------------+-------------------+---------------+
-```
-
-Export the address of the EWOQ account in the table above to an environment variable:
-
-```bash
-export EWOQ=0x...
-```
-
-</Step>
-<Step>
-
-### Transfer ERC-20 Token
-
-Now, lets transfer some TOK from the ewoq address to the myAddress address.
-
-```bash
-cast send $ERC20_CONTRACT_L1 --value 0 --private-key $PK "transfer(address,uint256)" $MYADDRESS 200ether --rpc-url myblockchain
-```
-
-Notice how we are setting the value to 0 since the --value command works for sending the native token, and in this case we are really interacting with a function of the ERC20 standard called `transfer` and will be the one in charge of modifying the balances mapping in the TOK state. Notice the amount that transfer receives needs to be set in wei, except if you use the word ether to convert units automatically.
-
-</Step>
-<Step>
-
-### Verify transfer
-
-Again, you can verify the transfer was performed correctly by retrieving the balances of each token in the Avalanche L1.
-
-```bash
-avalanche key list -l --blockchains myblockchain --tokens $ERC20_CONTRACT_L1,native  --keys myAddress,ewoq
-```
-
-</Step>
-</Steps>
\ No newline at end of file
diff --git a/content/course/interchain-token-transfer/03-tokens/09-transfer-erc20-to-sc.mdx b/content/course/interchain-token-transfer/03-tokens/09-transfer-erc20-to-sc.mdx
deleted file mode 100644
index d6b87b72..00000000
--- a/content/course/interchain-token-transfer/03-tokens/09-transfer-erc20-to-sc.mdx
+++ /dev/null
@@ -1,97 +0,0 @@
----
-title: ERC-20 and Smart Contracts
-description: Transfer an ERC-20 Token to a smart contracts
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-
-Transferring ERC-20 tokens to a smart contract involves a few steps, including setting an allowance and then using the transferFrom function to move the tokens. This process ensures that the smart contract can only withdraw the amount of tokens you've explicitly approved.
-
-First, let's look at the necessary code to achieve this. We'll use the same basic ERC-20 token contract that we used previously. 
-
-<Steps>
-<Step>
-
-## Create Smart Contract Receiving an ERC20
-
-We need a smart contract that will receive the tokens:
-
-```solidity 
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.0;
-import "@openzeppelin/contracts@4.8.1/token/ERC20/IERC20.sol";
-
-contract TokenReceiver {
-    IERC20 public token;
-
-    constructor(address tokenAddress) {
-        token = IERC20(tokenAddress);
-    }
-
-    function receiveTokens(address from, uint256 amount) public {
-        require(token.transferFrom(from, address(this), amount), "Transfer failed");
-    }
-}
-```
-
-In this contract, the `receiveTokens` function allows the contract to receive tokens from a specified address. It uses the transferFrom function of the ERC-20 token standard.
-
-Copy this code into a new file `src/my-contracts/TokenReceiver.sol`
-
-</Step>
-<Step>
-
-### Deploy ERC20 Receiver
-Let's deploy this ERC20receiver contract
-
-```bash
-forge create --rpc-url myblockchain --private-key $PK src/my-contracts/TokenReceiver.sol:TokenReceiver --constructor-args $ERC20_CONTRACT_L1
-```
-
-</Step>
-<Step>
-
-### Save Receiver Address
-
-```
-export ERC20_RECEIVER_L1=0x...
-```
-
-</Step>
-<Step>
-
-### Approve Token Expense
-
-Now to send Tokens to that contract, the Receiver contracts needs to be allowed to take funds on behalf of the user. Therefore, we need to allow our receiver contract as spender on the TOK interface.
-
-```bash
-cast send $ERC20_CONTRACT_L1 --private-key $PK "approve(address,uint256)" $ERC20_RECEIVER_L1 20ether --rpc-url myblockchain
-```
-
-</Step>
-<Step>
-
-### Transfer Tokens to Smart Contract
-
-Finally let's transfer tokens to this contract
-
-```bash
-cast send $ERC20_RECEIVER_L1 --private-key $PK "receiveTokens(address,uint256)" $EWOQ 2ether --rpc-url myblockchain
-```
-
-</Step>
-<Step>
-
-### Confirm transfer
-
-```bash
-cast call $ERC20_CONTRACT_L1 "balanceOf(address)(uint256)" $ERC20_RECEIVER_L1 --rpc-url myblockchain
-```
-
-</Step>
-</Steps>
-
-<Quiz quizId="121" />
diff --git a/content/course/interchain-token-transfer/03-tokens/10-wrapped-native-tokens.mdx b/content/course/interchain-token-transfer/03-tokens/10-wrapped-native-tokens.mdx
deleted file mode 100644
index 25d687d3..00000000
--- a/content/course/interchain-token-transfer/03-tokens/10-wrapped-native-tokens.mdx
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Wrapped Native Tokens
-description: Represent native assets as ERC-20 tokens
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-Native Wrapped Tokens are blockchain assets that represent a native cryptocurrency (AVAX, ALOT, ETH, etc) in a tokenized form that conforms to a specific token standard, typically ERC-20. This wrapping process involves locking the native cryptocurrency in a smart contract and minting an equivalent amount of the wrapped token.
-
-Wrapped tokens retain the value of the underlying native asset by backing those ERC20 representations 1:1 with the native token while gaining compatibility with the ERC-20 token standard. This compatibility is crucial for interoperability within the EVM ecosystem, enabling the use of wrapped tokens in decentralized applications (dApps), decentralized exchanges (DEXs), and smart contracts that require ERC-20 tokens including the **Avalanche Interchain Token Transfer dApp**.
-
-The process of wrapping and unwrapping tokens ensures that users can seamlessly switch between the native asset and its wrapped counterpart, facilitating smooth integration across various DeFi protocols and enhancing liquidity and usability within the blockchain ecosystem.
-
-Examples of Wrapped Tokens: 
-
-- wAVAX
-- wETH
-- BTC.b (this is not only wrapped, but also bridged to the Avalanche Ecosystem but represented as ERC20 to gain compatibility with the Avalanche C-chain ecosystem.)
-
-<Quiz quizId="122" />
diff --git a/content/course/interchain-token-transfer/03-tokens/11-create-a-wrapped-native-token.mdx b/content/course/interchain-token-transfer/03-tokens/11-create-a-wrapped-native-token.mdx
deleted file mode 100644
index 6ddac3ab..00000000
--- a/content/course/interchain-token-transfer/03-tokens/11-create-a-wrapped-native-token.mdx
+++ /dev/null
@@ -1,72 +0,0 @@
----
-title: Create a Wrapped Native Token
-description: Wrap the native asset of your blockchain
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-Creating a wrapped token contract for NAT (myblockchain's native token) involves writing a smart contract that adheres to the ERC-20 standard. This allows NAT to be used in dApps without the need of creating certain behavior for native assets. Here’s a simple example of such a contract written in Solidity:
-
-```solidity
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.0;
-
-contract WrappedNAT {
-    string public name = "Wrapped NAT";
-    string public symbol = "WNAT";
-    uint8 public decimals = 18;
-    uint256 public totalSupply;
-    
-    mapping(address => uint256) private balances;
-    mapping(address => mapping(address => uint256)) private allowances;
-    
-
-    receive() external payable {
-        deposit();
-    }
-
-    function deposit() public payable {
-        balances[msg.sender] += msg.value;
-        totalSupply += msg.value;
-    }
-
-    function withdraw(uint256 amount) public {
-        require(balances[msg.sender] >= amount, "Insufficient balance");
-        balances[msg.sender] -= amount;
-        totalSupply -= amount;
-        payable(msg.sender).transfer(amount);
-    }
-
-    function balanceOf(address account) public view returns (uint256) {
-        return balances[account];
-    }
-
-    function transfer(address to, uint256 amount) public returns (bool) {
-        require(balances[msg.sender] >= amount, "Insufficient balance");
-        balances[msg.sender] -= amount;
-        balances[to] += amount;
-        return true;
-    }
-
-    function approve(address spender, uint256 amount) public returns (bool) {
-        allowances[msg.sender][spender] = amount;
-        return true;
-    }
-
-    function allowance(address owner, address spender) public view returns (uint256) {
-        return allowances[owner][spender];
-    }
-
-    function transferFrom(address from, address to, uint256 amount) public returns (bool) {
-        require(balances[from] >= amount, "Insufficient balance");
-        require(allowances[from][msg.sender] >= amount, "Allowance exceeded");
-        balances[from] -= amount;
-        allowances[from][msg.sender] -= amount;
-        balances[to] += amount;
-        return true;
-    }
-}
-
-```
-
diff --git a/content/course/interchain-token-transfer/04-token-bridging/01-token-bridging.mdx b/content/course/interchain-token-transfer/04-token-bridging/01-token-bridging.mdx
deleted file mode 100644
index 7b93ae6c..00000000
--- a/content/course/interchain-token-transfer/04-token-bridging/01-token-bridging.mdx
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title: Token Bridging
-description: Learn about asset transfer between chains
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Book
----
-
-Asset bridging is a crucial concept in blockchain interoperability, enabling assets to be transferred across different blockchain networks. This process is essential for creating seamless experiences in multi-chain ecosystems.
-
-## What You Will Learn
-
-In this section, you will go through the following topics:
-
-- **Bridging assets:** you will understand why bridging assets is important.
-- **Bridge safety:** learn about the most common hacks in bridges and how to prevent them.
diff --git a/content/course/interchain-token-transfer/04-token-bridging/02-bridge-architecture.mdx b/content/course/interchain-token-transfer/04-token-bridging/02-bridge-architecture.mdx
deleted file mode 100644
index 1d4fa416..00000000
--- a/content/course/interchain-token-transfer/04-token-bridging/02-bridge-architecture.mdx
+++ /dev/null
@@ -1,37 +0,0 @@
----
-title: Bridge Architecture
-description: Get familiar with different bridge mechanisms
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-Asset bridging refers to the mechanism that allows assets, such as cryptocurrencies or tokens, to move from one blockchain to another. This is particularly important in ecosystems where multiple blockchains are used for different purposes, and users want to leverage assets across these chains. Bridging effectively extends the usability of assets beyond their native blockchain, facilitating greater liquidity and integration across various platforms.
-
-## Bridge Mechanisms
-
-### Lock & Mint
-
-Locking: The asset is locked in a smart contract on the source blockchain. For example, if you want to bridge AVAX from Avalanche's C-chain to Ethereum, you would lock your AVAX in a smart contract on Avalanche.
-Minting: Simultaneously, some event notifies Ethereum that an equivalent amount of a wrapped token (e.g., Wrapped AVAX) must be minted on the target blockchain and sent to the user’s address.
-
-### Burn & Mint
-
-Burning: When transferring assets back to the source blockchain, the wrapped tokens are burned or destroyed on the target blockchain.
-Releasing: The original assets are then released from the smart contract on the source blockchain back to the user's address.
-
-### Custodians
-
-Some bridges use a custodian or a centralized party to manage the assets. This party locks the asset on one blockchain and releases it on another, relying on trust and security measures.
-
-### Cross-Chain Communication
-
-Advanced bridges such as Avalanche Interchain Token Transfer utilize native cross-chain communication protocols to facilitate transactions between blockchains without requiring intermediaries. These protocols ensure that the asset's state and ownership are synchronized across different chains.
-
-## Why Bridging
-
-- Enhanced Liquidity: Bridging increases the liquidity of assets by allowing them to be used across different DeFi platforms and blockchain networks. This enhances trading opportunities and financial activities.
-- Interoperability: It fosters interoperability between different blockchains, enabling users to access a broader range of services and applications.
-- Flexibility: Users can move assets to chains with lower fees, faster transaction times, or better functionalities, optimizing their experience and strategies.
-
-<Quiz quizId="123" />
diff --git a/content/course/interchain-token-transfer/04-token-bridging/03-use-a-demo-bridge.mdx b/content/course/interchain-token-transfer/04-token-bridging/03-use-a-demo-bridge.mdx
deleted file mode 100644
index 905ff96e..00000000
--- a/content/course/interchain-token-transfer/04-token-bridging/03-use-a-demo-bridge.mdx
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: Use a Demo Bridge
-description: Interact with the ohmywarp bridge
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-This guide will walk you through the process of using a bridge between 2 Avalanche blockchains, providing a step-by-step approach to ensure a smooth and secure experience.
-
-Go to [ohmywarp.com](https://ohmywarp.com) and connect any web3 [wallet](https://core.app). Make sure your wallet has at least some AVAX on the Fuji Testnet. If you need funds you can go to the [faucet](https://faucet.avax.network). Use the coupon code `avalanche-academy` to get AVAX in C-chain
-
-Mint some `TLP` token on `C-Chain` in the Mint tab. This is an ERC20 deployed on Fuji's C-chain.
-Finally bridge some `TLP` to `Dispatch`. You can confirm the transfer in the Mint tab.
diff --git a/content/course/interchain-token-transfer/04-token-bridging/04-bridge-hacks.mdx b/content/course/interchain-token-transfer/04-token-bridging/04-bridge-hacks.mdx
deleted file mode 100644
index 3c2e58e0..00000000
--- a/content/course/interchain-token-transfer/04-token-bridging/04-bridge-hacks.mdx
+++ /dev/null
@@ -1,71 +0,0 @@
----
-title: Bridge Hacks
-description: Learn about the most common bridge hacks.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-## What are Bridge Hacks?
-
-Asset bridges are vital for blockchain interoperability but have been the target of significant security breaches. The complexities of bridging assets between different blockchains can create vulnerabilities that malicious actors exploit. Here’s an overview of some of the most common types of bridge hacks and security issues:
-
-### Smart Contract Exploits
-
-Smart contract exploits involve vulnerabilities in the bridge's code that can be exploited by attackers to steal assets. Common issues include:
-
-**Reentrancy Attacks**: Exploiting a contract’s ability to call itself, allowing attackers to repeatedly withdraw funds before the contract’s state is updated. Example: The DAO hack in 2016 utilized reentrancy to drain millions of dollars of ETH from a smart contract.
-  
-**Arithmetic Errors**: Bugs related to integer overflows or underflows that can lead to unintended behavior. Example: In 2020, the **Value DeFi** exploit used an arithmetic bug to drain $6 million from the protocol.
-
-**Logic Flaws**: Errors in the contract's logic that can be exploited to bypass security controls. Example: In the case of bZx exploit, an attacker exploited a logic flaw to manipulate the price of assets and steal funds.
-
-### Centralized Bridge Attacks
-
-Centralized bridges rely on a single custodian or entity to manage the assets. If the custodian is compromised, it can lead to:
-
-1. **Theft of Assets**: Direct theft from the custodian's reserves if their security is breached. Example: The Poly Network hack in 2021 involved a vulnerability that allowed attackers to exploit the bridge's central control mechanisms and steal over $600 million. Although much of the stolen funds were later returned, it highlighted significant risks in centralized bridges.
-
-2. **Mismanagement or Fraud**: The custodian could mismanage funds or engage in fraudulent activities. Example: Various cases of mismanagement or fraud in smaller, less established bridges where the custodian's integrity is in question.
-
-### Governance Attacks
-
-Governance attacks target the mechanisms by which decisions are made in decentralized bridges:
-
-**Vote Manipulation**: Attacking the governance process to make changes that benefit the attacker. Example: In some DeFi protocols, attackers have manipulated governance votes to gain control or access to assets.
-
-**51% Attacks**: Gaining control over a majority of the governance or network nodes to disrupt or exploit the bridge. Example: While more common in blockchains, similar attacks can occur in decentralized bridges with weak governance structures.
-
-### Cross-Chain Communication Vulnerabilities
-
-Cross-chain communication vulnerabilities involve weaknesses in the protocols or mechanisms that facilitate communication between different blockchains:
-
-**Data Manipulation**: Exploiting the data transmitted between chains to falsify transactions or asset states. Example: In 2022, the Wormhole bridge was exploited due to a vulnerability in its data verification process, leading to a loss of over $320 million.
-
-**Consensus Issues**: Problems with how different chains agree on the state of assets or transactions can lead to discrepancies and exploitation. Example: Misalignment between chains can lead to double-spending or other issues if not properly managed.
-
-### Phishing and Social Engineering
-
-Phishing and social engineering attacks target users or administrators rather than the bridge’s technical infrastructure:
-
-**Phishing**: Attacking users to steal their private keys or credentials to access funds. Example: Users may be tricked into entering their private keys on fraudulent websites pretending to be bridge interfaces.
-
-**Social Engineering**: Manipulating individuals involved in the bridge’s operations to gain unauthorized access or influence. Example: Administrators may be tricked into giving away critical access or credentials.
-
-## Mitigation Strategies
-
-1. **Audits and Code Reviews**: Regularly audit smart contracts and bridge code to identify and fix vulnerabilities before they can be exploited.
-
-2. **Security Best Practices**: Implement security best practices, including proper error handling, using well-tested libraries, and following coding standards.
-
-3. **Decentralization**: Where possible, use decentralized bridging solutions to reduce the risk associated with centralized custodians.
-
-4. **Governance Safeguards**: Strengthen governance mechanisms and ensure a robust process for decision-making and voting.
-
-5. **User Education**: Educate users about phishing and social engineering threats to reduce the risk of these types of attacks.
-
-6. **Insurance and Compensation**: Use insurance mechanisms or compensation funds to mitigate the impact of potential losses from breaches.
-
-By understanding and addressing these common bridge hacks, developers and users can better protect their assets and improve the overall security of cross-chain bridging solutions.
-
-<Quiz quizId="124" />
diff --git a/content/course/interchain-token-transfer/05-avalanche-interchain-token-transfer/01-avalanche-interchain-token-transfer.mdx b/content/course/interchain-token-transfer/05-avalanche-interchain-token-transfer/01-avalanche-interchain-token-transfer.mdx
deleted file mode 100644
index 30672960..00000000
--- a/content/course/interchain-token-transfer/05-avalanche-interchain-token-transfer/01-avalanche-interchain-token-transfer.mdx
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Avalanche Interchain Token Transfer
-description: Learn how to transfer assets between Avalanche L1s
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Book
----
-
-The Avalanche Interchain Token Transfer is an application that allows users to transfer tokens between Avalanche L1s. The bridge is a set of smart contracts that are deployed across multiple Avalanche L1s, and leverages [Interchain Messaging](https://github.com/ava-labs/teleporter) for cross-chain communication.
-
-# What you will learn
-
-In this chapter you will learn:
-
-- **Bridge Design:** How the bridge is designed on a high level.
-- **File Structure:** The structure of the bridge contracts and their dependencies.
-- **Token Home:** What the token home is and how it works.
-- **Token Remote:** What the token remote is and how it works.
diff --git a/content/course/interchain-token-transfer/05-avalanche-interchain-token-transfer/02-bridge-design.mdx b/content/course/interchain-token-transfer/05-avalanche-interchain-token-transfer/02-bridge-design.mdx
deleted file mode 100644
index bf280d0d..00000000
--- a/content/course/interchain-token-transfer/05-avalanche-interchain-token-transfer/02-bridge-design.mdx
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: Interchain Token Transfer Design
-description: Get familiar with the ICTT design
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-Each token transferrer instance consists of one "home" contract and at least one but possibly many "remote" contracts. Each home contract instance manages one asset to be transferred out to `TokenRemote` instances. The home contract lives on the Avalanche L1 where the asset to be transferred exists.
-
-A transfer involves locking the asset as collateral on the home Avalanche L1 and minting a representation of the asset on the remote Avalanche L1. The remote contracts, each with a single specified home contract, live on other Avalanche L1s that want to import the asset transferred by their specified home.
-
-The token transferrers are designed to be permissionless: anyone can register compatible `TokenRemote` instances to transfer tokens from the `TokenHome` instance to that new `TokenRemote` instance.
-
-The home contract keeps track of token balances transferred to each `TokenRemote` instance and handles returning the original tokens to the user when assets are transferred back to the `TokenHome` instance.
-
-`TokenRemote` instances are registered with their home contract via a Interchain Messaging message upon creation.
-
-Home contract instances specify the asset to be transferred as either an ERC20 token or the native token, and they allow for transferring the token to any registered `TokenRemote` instances. The token representation on the remote chain can also either be an ERC20 or native token, allowing users to have any combination of ERC20 and native tokens between home and remote chains:
-
-- `ERC20` -> `ERC20`
-- `ERC20` -> `Native`
-- `Native` -> `ERC20`
-- `Native` -> `Native`
-
-The remote tokens are designed to have compatibility with the token transferrer on the home chain by default, and they allow custom logic to be implemented in addition. For example, developers can inherit and extend the `ERC20TokenRemote` contract to add additional functionality, such as a custom minting, burning, or transfer logic.
-
-<Quiz quizId="125" />
diff --git a/content/course/interchain-token-transfer/05-avalanche-interchain-token-transfer/03-file-structure.mdx b/content/course/interchain-token-transfer/05-avalanche-interchain-token-transfer/03-file-structure.mdx
deleted file mode 100644
index d958a806..00000000
--- a/content/course/interchain-token-transfer/05-avalanche-interchain-token-transfer/03-file-structure.mdx
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: File Structure
-description: Understand the components of the ICTT structure
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-## Contract Structure
-
-The ERC20 and native token transferrers built on top of Interchain Messaging are composed of interfaces and abstract contracts that make them extendable to new implementations in the future.
-
-### `ITokenTransferrer`
-
-Interface that defines the events token transfer contract implementations must emit. Also defines the message types and formats of messages between all implementations.
-
-### `IERC20TokenTransferrer` and `INativeTokenTransferrer`
-
-Interfaces that define the external functions for interacting with token transfer contract implementations of each type. ERC20 and native token transferrer interfaces vary from each other in that the native token transferrer functions are `payable` and do not take an explicit amount parameter (it is implied by `msg.value`), while the ERC20 token transferrer functions are not `payable` and require the explicit amount parameter. Otherwise, they include the same functions.
diff --git a/content/course/interchain-token-transfer/05-avalanche-interchain-token-transfer/04-token-home.mdx b/content/course/interchain-token-transfer/05-avalanche-interchain-token-transfer/04-token-home.mdx
deleted file mode 100644
index a2473330..00000000
--- a/content/course/interchain-token-transfer/05-avalanche-interchain-token-transfer/04-token-home.mdx
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Token Home
-description: Learn about the Token Home, the asset origin component of the ICTT
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-## `TokenHome`
-
-An abstract implementation of `ITokenTransferrer` for a token transfer contract on the "home" chain with the asset to be transferred. Each `TokenHome` instance supports transferring exactly one token type (ERC20 or native) on its chain to arbitrarily many "remote" instances on other chains.
-
-It handles locking tokens to be sent to `TokenRemote` instances, as well as receiving token transfer messages to either redeem tokens it holds as collateral (i.e. unlock) or route them to other `TokenRemote` instances (i.e. "multi-hop").
-
-In the case of a multi-hop transfer, the `TokenHome` already has the collateral locked from when the tokens were originally transferred to the first `TokenRemote` instance, so it simply updates the accounting of the transferred balances to each respective `TokenRemote` instance.
-
-Remote contracts must first be registered with a `TokenHome` instance before the home contract will allow for sending tokens to them. This is to prevent tokens from being transferred to invalid remote addresses.
-
-Anyone is able to deploy and register remote contracts, which may have been modified from this repository. It is the responsibility of the users of the home contract to independently evaluate each remote for its security and correctness.
-
-### `ERC20TokenHome`
-
-A concrete implementation of `TokenHome` and `IERC20TokenTransferrer` that handles the locking and releasing of an ERC20 token.
-
-### `NativeTokenHome`
-
-A concrete implementation of `TokenHome` and `INativeTokenTransferrer` that handles the locking and release of the native EVM asset.
diff --git a/content/course/interchain-token-transfer/05-avalanche-interchain-token-transfer/05-token-remote.mdx b/content/course/interchain-token-transfer/05-avalanche-interchain-token-transfer/05-token-remote.mdx
deleted file mode 100644
index 00d26150..00000000
--- a/content/course/interchain-token-transfer/05-avalanche-interchain-token-transfer/05-token-remote.mdx
+++ /dev/null
@@ -1,33 +0,0 @@
----
-title: Token Remote
-description: Learn about the Token Remote, the asset destination component of the ICTT
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-## `TokenRemote`
-
-An abstract implementation of `ITokenTransferrer` for a token transfer contract on a "remote" chain that receives transferred assets from a specific `TokenHome` instance. Each `TokenRemote` instance has a single `TokenHome` instance that it receives token transfers from to mint tokens. It also handles sending messages (and correspondingly burning tokens) to route tokens back to other chains (either its `TokenHome`, or other `TokenRemote` instances).
-
-Once deployed, a `TokenRemote` instance must be registered with its specified `TokenHome` contract. This is done by calling `registerWithHome` on the remote contract, which will send a Interchain Messaging message to the home contract with the information to register.
-
-All messages sent by `TokenRemote` instances are sent to the specified `TokenHome` contract, whether they are to redeem the collateral from the `TokenHome` instance or route the tokens to another `TokenRemote` instance.
-
-Routing tokens from one `TokenRemote` instance to another is referred to as a "multi-hop", where the tokens are first sent back to their `TokenHome` contract to update its accounting, and then automatically routed on to their intended destination `TokenRemote` instance.
-
-TokenRemote contracts allow for scaling token amounts, which should be used when the remote asset has a higher or lower denomination than the home asset, such as allowing for a ERC20 home asset with a denomination of 6 to be used as the native EVM asset on a remote chain (with a denomination of 18).
-
-### `ERC20TokenRemote`
-
-A concrete implementation of `TokenRemote`, `IERC20TokenTransferrer`, and `IERC20` that handles the minting and burning of an ERC20 asset. Note that the `ERC20TokenRemote` contract is an ERC20 implementation itself, which is why it takes the `tokenName`, `tokenSymbol`, and `tokenDecimals` in its constructor.
-
-All of the ERC20 interface implementations are inherited from the standard OpenZeppelin ERC20 implementation and can be overridden in other implementations if desired.
-
-### `NativeTokenRemote`
-
-A concrete implementation of `TokenRemote`, `INativeTokenTransferrer`, and `IWrappedNativeToken` that handles the minting and burning of the native EVM asset on its chain using the native minter precompile.
-
-Deployments of this contract must be permitted to mint native coins in the chain's configuration. Note that the `NativeTokenRemote` is also an implementation of `IWrappedNativeToken` itself, which is why the `nativeAssetSymbol` must be provided in its constructor.
-`NativeTokenRemote` instances always have a denomination of 18, which is the denomination of the native asset of EVM chains. We will cover Native Token Remote in depth later in the course.
-
diff --git a/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/01-erc-20-to-erc-20-bridge.mdx b/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/01-erc-20-to-erc-20-bridge.mdx
deleted file mode 100644
index d17cb37a..00000000
--- a/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/01-erc-20-to-erc-20-bridge.mdx
+++ /dev/null
@@ -1,32 +0,0 @@
----
-title: ERC-20 to ERC-20 Bridge
-description: Transfer ERC-20 tokens between Avalanche L1s
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Book
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-import Link from 'next/link';
-import { cn } from '@/utils/cn';
-import { buttonVariants } from '@/components/ui/button.tsx'
-
-## Transfer an ERC-20 Token &rarr; Avalanche L1 as an ERC-20 Token
-
-This chapter will show you how to send an ERC-20 Token on C-Chain to an Avalanche L1 using Interchain Messaging and Foundry. This demo is conducted on a local network, but can be applied to Fuji Testnet and Avalanche Mainnet directly.
-
-**All Avalanche Interchain Token Transfer contracts and interfaces implemented in this chapter implementation are maintained in the [`avalanche-interchain-token-transfer`](https://github.com/ava-labs/avalanche-interchain-token-transfer/tree/main/contracts/src) repository.**
-
-Deep dives on each template interface can be found [here](https://github.com/ava-labs/avalanche-interchain-token-transfer/blob/main/contracts/README.md).
-
-_Disclaimer: The avalanche-interchain-token-transfer contracts used in this tutorial are under active development and are not yet intended for production deployments. Use at your own risk._
-
-## What we will do
-
-1. Deploy an ERC-20 Contract on C-Chain
-2. Deploy the Interchain Token Transferer Contracts on C-Chain and Avalanche L1
-3. Register Remote Token contract with the Home Transferer contract
-4. Add Collateral and Start Sending Tokens
-
-
-
-
diff --git a/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/02-deploy-erc-20-token.mdx b/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/02-deploy-erc-20-token.mdx
deleted file mode 100644
index 820c919b..00000000
--- a/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/02-deploy-erc-20-token.mdx
+++ /dev/null
@@ -1,43 +0,0 @@
----
-title: Deploy an ERC-20 
-description: Deploy the asset to transfer
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-<Steps>
-<Step>
-
-### Deploy an ERC-20 Token
-
-To transfer an ERC20 token from C-chain to your own blockchain, the first thing we will need is the ERC20 token to bridge. You will find a contract in the Starter-Kit under `contracts/interchain-token-transfer/MyToken.sol:TOK` 
-
-```bash 
-forge create --rpc-url local-c --private-key $PK contracts/interchain-token-transfer/MyToken.sol:TOK
-```
-
-</Step>
-<Step>
-
-### Save the ERC-20 Address 
-
-```bash
-export ERC20_C_CHAIN=<"Deployed to" address>
-```
-
-</Step>
-<Step>
-
-### Check the Balance
-
-If you deployed the above example contract, you should see a balance of 100,000 tokens when you run the below command:
-
-```bash
-cast call --rpc-url local-c --private-key $PK $ERC20_C_CHAIN "balanceOf(address)(uint)" $FUNDED_ADDRESS
-```
-
-</Step>
-</Steps>
\ No newline at end of file
diff --git a/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/03-deploy-home.mdx b/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/03-deploy-home.mdx
deleted file mode 100644
index 9478aed9..00000000
--- a/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/03-deploy-home.mdx
+++ /dev/null
@@ -1,32 +0,0 @@
----
-title: Deploy a Home Contract
-description: Deploy the Token Home on C-chain
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-
-We will deploy two Avalanche Interchain Token Transfer contracts. One of the source chain (which is C-chain in our case) and another on the destination chain (myblockchain in our case).
-
-<Steps>
-<Step>
-
-### Deploy ERC20Home Contract
-
-```bash
-forge create --rpc-url local-c --private-key $PK lib/avalanche-interchain-token-transfer/contracts/src/TokenHome/ERC20TokenHome.sol:ERC20TokenHome --constructor-args $TELEPORTER_REGISTRY_C_CHAIN $FUNDED_ADDRESS $ERC20_C_CHAIN 18
-```
-
-</Step>
-<Step>
-
-### Save the ERC-20 Home Address
-
-```bash
-export ERC20_HOME_C_CHAIN=<"Deployed to" address>
-```
-
-</Step>
-</Steps>
diff --git a/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/04-deploy-remote.mdx b/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/04-deploy-remote.mdx
deleted file mode 100644
index ff24bd20..00000000
--- a/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/04-deploy-remote.mdx
+++ /dev/null
@@ -1,134 +0,0 @@
----
-title: Deploy a Remote Contract
-description: Deploy the Token Remote on your own blockchain
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-
-To ensure the wrapped token is bridged into the destination chain (in this case, C-Chain) you'll need to deploy a _remote_ contract that implements the `IERC20Bridge` interface, as well as inheriting the properties of `TeleporterTokenRemote`. In order for the bridged tokens to have all the normal functionality of a locally deployed ERC20 token, this remote contract must also inherit the properties of a standard `ERC20` contract.
-
-<Steps>
-
-<Step>
-### Get the `Teleporter Registry` address of your Avalanche L1
-
-```bash
-avalanche blockchain describe myblockchain
-```
-
-```
-+-------------------------------------------------------------------------------------------+
-|                                         TELEPORTER                                        |
-+---------------+------------------------------+--------------------------------------------+
-| Local Network | Teleporter Messenger Address | 0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf |
-|               +------------------------------+--------------------------------------------+
-|               | Teleporter Registry Address  | 0x82EeEf8e31D4Bf95916219D7949D66c468Ac0681 | // [!code highlight]
-+---------------+------------------------------+--------------------------------------------+
-```
-</Step>
-<Step>
-### Save the `Teleporter Registry Address`
-
-Most other environment variables we will need are already set in the devcontainer.
-```bash
-export TELEPORTER_REGISTRY_L1=0x82EeEf8e31D4Bf95916219D7949D66c468Ac0681
-```
-</Step>
-<Step>
-
-### Get the Source Blockchain ID
-
-Get the `Source Blockchain ID` in hexidecimal format from the output of `avalanche blockchain describe myblockchain` above, which in this example is the BlockchainID of your Avalanche L1:
-
-```
-+---------------------------------------------------------------------------------------------------------------+
-|                                                  MYBLOCKCHAIN                                                 |
-+---------------+-----------------------------------------------------------------------------------------------+
-| Name          | myblockchain                                                                                  |
-+---------------+-----------------------------------------------------------------------------------------------+
-| VM ID         | qDNV9vtxZYYNqm7TN1mYBuaaknLdefDbFK8bFmMLTJQJKaWjV                                             |
-+---------------+-----------------------------------------------------------------------------------------------+
-| VM Version    | v0.6.9                                                                                        |
-+---------------+--------------------------+--------------------------------------------------------------------+
-| Local Network | ChainID                  | 1                                                                  |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | SubnetID                 | 2AKbBT8jFUfUsUJ2hhRiDUnAAajJdNhTKeNgEe3q77spMj1N8F                 |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | Owners (Threhold=1)      | P-custom18jma8ppw3nhx5r4ap8clazz0dps7rv5u9xde7p                    |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | BlockchainID (CB58)      | 2EzvQgth5D5aZ81gmF13TsA61c2zduHWqszYPVvzzvRWZXcQgA                 |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | BlockchainID (HEX)       | 0xa37b5143f12ecf020ec893e4a8f48159e470b47fd9ff293ab0a808be47a4f67c | // [!code highlight]
-+---------------+--------------------------+--------------------------------------------------------------------+
-
-```
-</Step>
-<Step>
-
-### Save the Source Blockchain ID
-
-```bash
-export SOURCE_BLOCKCHAIN_ID_HEX=<BlockchainID (HEX)>
-```
-
-</Step>
-<Step>
-
-### Deploy the Remote Contract
-
-Using the [`forge create`](https://book.getfoundry.sh/reference/forge/forge-create) command, we will deploy the `ERC20TokenRemote.sol` contract, passing in the following constructor arguments:
-
-- Interchain Messaging Registry Address **(for C-Chain)**
-- Interchain Messaging Manager (our funded address)
-- Source Blockchain ID (hexidecimal representation of our Avalanche L1's Blockchain ID)
-- Token Home Address (address of NativeTokenHome.sol deployed on Avalanche L1 in the last step)
-- Token Name (input in the constructor of the [wrapped token contract](https://github.com/ava-labs/avalanche-interchain-token-transfer/blob/main/contracts/src/WrappedNativeToken.sol))
-- Token Symbol (input in the constructor of the [wrapped token contract](https://github.com/ava-labs/avalanche-interchain-token-transfer/blob/main/contracts/src/WrappedNativeToken.sol))
-- Token Decimals (uint8 integer representing number of decimal places for the ERC20 token being created. Most ERC20 tokens follow the Ethereum standard, which defines 18 decimal places.)
-
-```bash
-forge create --rpc-url myblockchain --private-key $PK \
-lib/avalanche-interchain-token-transfer/contracts/src/TokenRemote/ERC20TokenRemote.sol:ERC20TokenRemote \
---constructor-args "(${TELEPORTER_REGISTRY_L1}, ${FUNDED_ADDRESS}, ${C_CHAIN_BLOCKCHAIN_ID_HEX}, ${ERC20_HOME_C_CHAIN}, 18)" "TOK" "TOK" 18
-```
-
-</Step>
-<Step>
-
-### Save the Remote Contract Address
-
-Note the address the remote contract was "Deployed to".
-
-```bash
-export ERC20_TOKEN_REMOTE_L1=<"Deployed to" address>
-```
-
-</Step>
-<Step>
-
-### Register Remote Bridge with Home Bridge
-
-After deploying the bridge contracts, you'll need to register the remote bridge by sending a dummy message using the `registerWithHome` method. This message includes details which inform the Home Bridge about your destination blockchain and bridge settings, eg. `initialReserveImbalance`.
-
-```bash
-cast send --rpc-url myblockchain --private-key $PK $ERC20_TOKEN_REMOTE_L1 \
-"registerWithHome((address, uint256))" "(0x0000000000000000000000000000000000000000, 0)"
-```
-
-</Step>
-<Step>
-
-### Approve tokens for the Home Bridge contract
-
-You can increase/decrease the numbers here as per your requirements. (All values are mentioned in wei)
-
-```bash
-cast send --rpc-url local-c --private-key $PK $ERC20_C_CHAIN \
-"approve(address, uint256)" $ERC20_HOME_C_CHAIN 2000000000000000000000
-```
-
-</Step>
-</Steps>
diff --git a/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/05-transfer-tokens.mdx b/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/05-transfer-tokens.mdx
deleted file mode 100644
index a4d7573f..00000000
--- a/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/05-transfer-tokens.mdx
+++ /dev/null
@@ -1,33 +0,0 @@
----
-title: Transfer Tokens
-description: Transfer an ERC20 from C-chain to your own blockchain
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-<Steps>
-<Step>
-
-### Transfer the Token Cross-chain
-
-Now that all the bridge contracts have been deployed, send a native token from your Avalanche L1 to C-Chain with the [`cast send`](https://book.getfoundry.sh/reference/cast/cast-send) foundry command.
-
-```bash
-cast send --rpc-url local-c --private-key $PK $ERC20_HOME_C_CHAIN "send((bytes32, address, address, address, uint256, uint256, uint256, address), uint256)" "(${SOURCE_BLOCKCHAIN_ID_HEX}, ${ERC20_TOKEN_REMOTE_L1}, ${FUNDED_ADDRESS}, ${ERC20_C_CHAIN}, 0, 0, 250000, 0x0000000000000000000000000000000000000000)" 1000000000000000000000
-```
-
-</Step>
-<Step>
-
-### Check Balances
-
-To confirm the token was bridged from C-Chain to a Avalanche L1, we will check the recipient's balance of wrapped tokens on the Avalanche L1 with the [`cast call`](https://book.getfoundry.sh/reference/cast/cast-call?highlight=cast%20call#cast-call) foundry command:
-
-```bash
-cast call --rpc-url myblockchain $ERC20_TOKEN_REMOTE_L1 "balanceOf(address)(uint)" $FUNDED_ADDRESS
-```
-
-</Step>
-</Steps> 
diff --git a/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/06-deploy-with-avalanche-cli.mdx b/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/06-deploy-with-avalanche-cli.mdx
deleted file mode 100644
index 5fc1bc1e..00000000
--- a/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/06-deploy-with-avalanche-cli.mdx
+++ /dev/null
@@ -1,121 +0,0 @@
----
-title: Deploy and Use ICTT with Avalanche CLI
-description: Alternative and simplified way to deploy ICTT to transfer ERC-20 to ERC-20 assets
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Terminal
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-import Link from 'next/link';
-import { cn } from '@/utils/cn';
-import { buttonVariants } from '@/components/ui/button.tsx'
-
-In the previous sections of this chapter we manually deployed and interacted with the Interchain Token Transfer contracts. In this section we will use the Avalanche CLI to deploy the contracts and transfer the tokens.
-
-## What we will do
-
-2. Create an Avalanche L1 and Deploy on Local Network
-3. Deploy an ERC-20 Contract on C-chain
-4. Deploy the Avalanche Interchain Token Transfer Contracts on C-chain and Avalanche L1
-5. Start Sending Tokens
-
-<Steps>
-<Step>
-
-### Deploy Avalanche Interchain Token Transfer Contracts
-
-First retrieve the address of the ERC-20 token on C-Chain.
-
-```bash
-echo $ERC20_C_CHAIN
-```
-    
-Next we will deploy two Interchain Token Transfer contracts using the Avalanche CLI. It will deploy the contracts on the source chain (C-Chain) and on the destination chain (myblockchain) for us. 
-
-```bash
-avalanche interchain tokenTransferrer deploy
-```
-
-```bash
-✔ Local Network
-✔ C-Chain
-✔ Deploy a new Home for the token
-✔ An ERC-20 token
-Enter the address of the ERC-20 Token: 0x5DB9A7629912EBF95876228C24A848de0bfB43A9
-...
-Home Deployed to http://127.0.0.1:9650/ext/bc/C/rpc
-Home Address: 0x4Ac1d98D9cEF99EC6546dEd4Bd550b0b287aaD6D
-
-Remote Deployed to http://127.0.0.1:9650/ext/bc/2u9Hu7Noja3Z1kbZyrztTMZcDeqb6acwyPyqP4BbVDjoT8ZaYc/rpc
-Remote Address: 0x0D189a705c1FFe77F1bF3ee834931b6b9B356c05
-```
-
-Save the Remote contract address in the environment variables.
-
-```bash
-export ERC20_REMOTE_L1=<"Remote address">
-```
-</Step>
-<Step>
-### Get Balances
-
-Before transfering some funds Cross-Chain, check the current balances of both the ERC20 Home token and the Remote one. 
-
-```bash
-avalanche key list --local --keys ewoq  --blockchains c,myblockchain --tokens $ERC20_C_CHAIN,$ERC20_REMOTE_L1
-```
-
-```bash
-+--------+------+---------+--------------------------------------------+---------------+------------------+---------------+
-|  KIND  | NAME | SUBNET  |                  ADDRESS                   |     TOKEN     |     BALANCE      |    NETWORK    |
-+--------+------+---------+--------------------------------------------+---------------+------------------+---------------+
-| stored | ewoq | myblockchain |                                        | TOK (0x0D18.)|               0  | Local Network |
-+        +      +----------+--------------------------------------------+---------------+-----------------+---------------+
-|        |      | C-Chain  | 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC | TOK (0x5DB9.)| 100000.000000000 | Local Network |
-+--------+------+----------+--------------------------------------------+---------------+-----------------+---------------+
-```
-</Step>
-<Step>
-### Transfer the Token Cross-chain
-
-Now that the Avalanche Interchain Token Transfer contracts have been deployed, transfer some ERC20 tokens `TOK` from C-Chain to _myblockchain_
-
-```bash
-avalanche key transfer
-```
-
-```
-✔ Local Network
-✔ C-Chain
-✔ Blockchain myblockchain
-Enter the address of the Token Transferrer on c-chain: 0x4Ac1d98D9cEF99EC6546dEd4Bd550b0b287aaD6D
-Enter the address of the Token Transferrer on myblockchain: 0x0D189a705c1FFe77F1bF3ee834931b6b9B356c05
-✔ ewoq
-✔ Key
-✔ ewoq
-Amount to send (TOKEN units): 100
-```
-</Step>
-<Step>
-### Check Balances
-
-Now we can check the balances of both the ERC-20 Home token and the Remote one. 
-
-```bash
-avalanche key list --local --keys ewoq  --blockchains c,myblockchain --tokens $ERC20_C_CHAIN,$ERC20_REMOTE_L1
-```
-
-```bash
-+--------+------+----------+--------------------------------------------+---------------+-----------------+---------------+
-|  KIND  | NAME |  SUBNET  |                  ADDRESS                   |     TOKEN     |     BALANCE     |    NETWORK    |
-+--------+------+----------+--------------------------------------------+---------------+-----------------+---------------+
-| stored | ewoq | myblockchain | 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC | TOK (0x0D18.) |   100.000000000 | Local Network |
-+        +      +----------+--------------------------------------------+---------------+-----------------+---------------+
-|        |      | C-Chain  | 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC | TOK (0x5DB9.) | 99900.000000000 | Local Network |
-+--------+------+----------+--------------------------------------------+---------------+-----------------+---------------+
-```
-
-</Step>
-</Steps>
-
-**Success!** We have transferred 100 tokens from C-Chain to myblockchain using the Avalanche CLI.
diff --git a/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/07-avacloud-and-core-bridge.mdx b/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/07-avacloud-and-core-bridge.mdx
deleted file mode 100644
index 243e50a2..00000000
--- a/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/07-avacloud-and-core-bridge.mdx
+++ /dev/null
@@ -1,36 +0,0 @@
----
-title:  Integrate ICTT with Core
-description: Learn how to integrate ICTT bridges into the Core Bridge through AvaCloud.
-updated: 2024-05-31
-icon: Book
-authors: [owenwahlgren]
----
-
-## Integrate Interchain Token Transfers (ICTT) Into Core
-
-ICTT bridges deployed through [**AvaCloud**](https://avacloud.io/) will automatically integrate into the [**Core Bridge**](https://core.app/en/bridge). This ensures that any bridges created through AvaCloud are available immediately and do not need extra review.
-
-However, **ICTT bridges** deployed outside of AvaCloud (by third-party developers or other methods) will need to be submitted for manual review. Developers will need to provide:
-
-1. **Token Bridge Contract Address(es)**: The bridge contract(s) on the L1.
-2. **Layer 1 Information**: Name and other key details of the associated L1 blockchain.
-
-The Core team will review this info to ensure the bridge meets security and compliance standards. This guarantees network reliability while allowing more flexibility.
-
-### [Community Submission Form](https://forms.gle/jdcKcYWu26CsY6jRA)
-
-<iframe src="https://forms.gle/jdcKcYWu26CsY6jRA" className="w-full h-96" />
-
-### AvaCloud Relayer Service and Bridge Integration
-
-When deploying ICTT bridges, the **meta-transaction relayer** plays a key role in enhancing the user experience. Once the bridge is set up, the relayer ensures users can transfer assets between chains without worrying about gas fees. 
-
-By using the **relayer service**, gas costs for transactions made through the bridge are handled on behalf of users, streamlining cross-chain operations. The relayer, funded with the L1's gas token, forwards transactions signed by users to the destination chain, ensuring the asset bridge between chains works smoothly without requiring users to hold or manage gas tokens.
-
-This integration is especially useful for bridging clients who are not familiar with Web3, as it removes the need for them to manage gas tokens during the cross-chain asset transfer process. Once set up, the relayer infrastructure includes:
-
-1. A **relaying node** to handle transactions.
-2. A **relayer wallet** funded with gas tokens from the subnet.
-3. A **trusted forwarder contract** that securely relays transactions.
-
-With this setup, users benefit from a gas-free experience when interacting with your bridge, making cross-chain transfers and other actions seamless and accessible.
diff --git a/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/08-deploy-your-own-frontend.mdx b/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/08-deploy-your-own-frontend.mdx
deleted file mode 100644
index 5d3deb93..00000000
--- a/content/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/08-deploy-your-own-frontend.mdx
+++ /dev/null
@@ -1,178 +0,0 @@
----
-title:  Deploy Your Own ICTT Frontend
-description: Set up the BuilderKit for deploying your own Interchain Token Transfer (ICTT) frontend with custom tokens and chains.
-updated: 2024-05-31
-icon: Terminal
-authors: [0xstt]
----
-import Link from 'next/link';
-import { cn } from '@/utils/cn';
-import { buttonVariants } from '@/components/ui/button.tsx'
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-In this section, you’ll learn how to deploy your own **ICTT frontend** using the BuilderKit and pre-configured tokens and chains. Follow these steps to quickly set up and test your own ICTT frontends with Avalanche L1s.
-
----
-
-<Steps>
-
-<Step>
-### Open the AvaCloudSDK Starter Kit Github Repository
-
-Start by opening the repository on Github.
-
-<Link
-    href="https://github.com/ava-labs/avalanche-starter-kit"
-    className={cn(
-    buttonVariants({ variant: 'default', className: 'mt-4' }),
-    )}
-    target='_blank'
->Open Avalanche Starter Kit</Link>
-</Step>
-
-<Step>
-### Open the Dev Container and Navigate to the Chain Definitions
-
-- Open the repository in a Github Codespace or Visual Studio Code.
-- Navigate to the `web-apps/builderkit/chains/definitions` folder.
-
-In this folder, you’ll find separate files for each chain configuration. For example, `echo.ts` contains the definition for the **Echo L1** chain:
-
-```ts
-import { defineChain } from "viem";
-
-export const echo = defineChain({
-    id: 173750,
-    name: 'Echo L1',
-    network: 'echo',
-    nativeCurrency: {
-        decimals: 18,
-        name: 'Ech',
-        symbol: 'ECH',
-    },
-    rpcUrls: {
-        default: {
-            http: ['https://subnets.avax.network/echo/testnet/rpc']
-        },
-    },
-    blockExplorers: {
-        default: { name: 'Explorer', url: 'https://subnets-test.avax.network/echo' },
-    },
-    iconUrl: "/chains/logo/173750.png"
-});
-```
-
-### How to Configure Your Own Blockchain
-
-To configure your custom blockchain (e.g., `myblockchain`):
-
-1. Copy the existing echo.ts file and rename it to myblockchain.ts.
-2. Update the fields to match your blockchain’s specific details, such as chain ID, network name, and native currency.
-3. Save the file in the chains/definitions folder. 
-
-</Step>
-<Step> 
-### Import Your Chains
-
-- Navigate to the `web-apps/builderkit/flows/ictt` folder.
-
-Once you're inside the **ICTT** folder, open the `page.tsx` file to begin configuring the tokens and chains.
-
-```tsx
-import { myblockchain } from './chains/definitions';
-```
-
-**Add Imported Chains to Array**
-
-After importing the chains, add them into the chains array:
-
-```tsx
-const chains = [avalanche, avalancheFuji, echo, dispatch, myblockchain];
-```
-
-This array will hold the configuration of all the chains that will interact with your ICTT frontend.
-</Step>
-<Step> 
-### Add Your Chain, and Configure Tokens
-
-Next, configure your tokens. Here’s an example token configuration:
-
-```tsx
-const tokens = [
-  {
-    address: "0x8D6f0E153B1D4Efb46c510278Db3678Bb1Cc823d",
-    name: "TOK",
-    symbol: "TOK",
-    decimals: 18,
-    chain_id: 43113,
-    supports_ictt: true,
-    transferer: "0xD63c60859e6648b20c38092cCceb92c5751E32fF",
-    mirrors: [
-      {
-        address: "0x8D6f0E153B1D4Efb46c510278Db3678Bb1Cc823d",
-        transferer: "0x8D6f0E153B1D4Efb46c510278Db3678Bb1Cc823d",
-        chain_id: 173750,
-        decimals: 18
-      }
-    ]
-  },
-  {
-    address: "0x8D6f0E153B1D4Efb46c510278Db3678Bb1Cc823d",
-    name: "TOK.e",
-    symbol: "TOK.e",
-    decimals: 18,
-    chain_id: 173750,
-    supports_ictt: true,
-    is_transferer: true,
-    mirrors: [
-      {
-        home: true,
-        address: "0x8D6f0E153B1D4Efb46c510278Db3678Bb1Cc823d",
-        transferer: "0xD63c60859e6648b20c38092cCceb92c5751E32fF",
-        chain_id: 43113,
-        decimals: 18
-      }
-    ]
-  }
-];
-```
-
-<Accordions>
-<Accordion title="What Are `is_transferer` and `home` Flags?">
-- **`is_transferer` Flag**: This flag is used to indicate if the token on the current chain is a transferer. A transferer is a contract that allows the token to be moved between chains using Interchain Token Transfers (ICTT). Set this flag to true if this token is responsible for transferring assets.
-- **`home` Flag**: The `home` flag is used to indicate that this token is the original version of the asset on the **home chain**. When a token is mirrored on multiple chains, the home chain holds the original token, while the mirrors are representations of it on other chains.
-
-These flags ensure proper handling of tokens when they are moved across chains. The `home` flag helps identify which chain holds the token, while `the is_transferer` flag specifies whether the token contract is responsible for transfers. 
-</Accordion>
-</Accordions>
-
-
-</Step>
-<Step> 
-### Implement the ICTT Component
-
-After configuring the tokens and chains, implement the **ICTT component** in the page. Here’s how to pass the token and chain details to the component:
-
-```tsx
-<ICTT tokens={tokens} token_in="0x8D6f0E153B1D4Efb46c510278Db3678Bb1Cc823d" source_chain_id={43113} destination_chain_id={173750}></ICTT>
-```
-
-In this example:
-
-- `tokens` contains the configuration.
-- `token_in` specifies the address of the token being transferred.
-- `source_chain_id` and `destination_chain_id` represent the IDs of the source and destination chains. 
-</Step>
-<Step> 
-### Run the Application
-
-Move back to the `web-apps` folder and run the following command to start the app in development mode:
-
-```bash
-yarn run dev
-```
-
-You can now interact with the ICTT component. 
-![](/course-images/interchain-token-transfer/site-running.png)
-</Step>
-</Steps>
\ No newline at end of file
diff --git a/content/course/interchain-token-transfer/07-tokens-on-multiple-chains/01-tokens-on-multiple-chain.mdx b/content/course/interchain-token-transfer/07-tokens-on-multiple-chains/01-tokens-on-multiple-chain.mdx
deleted file mode 100644
index 952440a6..00000000
--- a/content/course/interchain-token-transfer/07-tokens-on-multiple-chains/01-tokens-on-multiple-chain.mdx
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Overview of Multi-hop Transfers
-description: Learn about how ICTT supports multi-hop transfers between spoke chains.
-updated: 2024-05-31
-authors: [owenwahlgren]
-icon: Book
----
-
-The token bridge also supports "multi-hop" transfers, where tokens can be transferred between remote chains via the home chain. To illustrate, consider two remotes _R<sub>a</sub>_ and _R<sub>b</sub>_ that are both connected to the same home _H_. A multi-hop transfer from _R<sub>a</sub>_ to _R<sub>b</sub>_ first gets routed from _R<sub>a</sub>_ to _H_, where the remote balances are updated, and then _H_ automatically routes the transfer on to _R<sub>b</sub>_.
-
-In this example, our _R<sub>a</sub>_ chain is `myblockchain`, our _R<sub>b</sub>_ chain is `myblockchain2`, and _H_ chain is the Avalanche C-Chain.
-
-### What we will do
-
-1. Deploy a new local blockchain `myblockchain2`
-2. Deploy a new `ERC20TokenRemote` contract to `myblockchain2`
-3. Register the new `ERC20TokenRemote` contract with the `TokenHome` contract on the Avalanche C-Chain
-3. Perform a multi-hop transfer of `TOK` from `myblockchain` to `myblockchain2`, with a 'hop' through the Avalanche C-Chain
-
-
-<Quiz quizId="127"/>
\ No newline at end of file
diff --git a/content/course/interchain-token-transfer/07-tokens-on-multiple-chains/02-deploy-additional-blockchain.mdx b/content/course/interchain-token-transfer/07-tokens-on-multiple-chains/02-deploy-additional-blockchain.mdx
deleted file mode 100644
index 75556d00..00000000
--- a/content/course/interchain-token-transfer/07-tokens-on-multiple-chains/02-deploy-additional-blockchain.mdx
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: Deploy Additional Blockchain for Multi-hop
-description: Set up a new blockchain to test ICTT multi-hop transfers.
-updated: 2024-05-31
-authors: [owenwahlgren]
-icon: Book
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-<Steps>
-<Step>
-### Create a new blockchain `myblockchain2` for multi-hop transfer
-
-```bash
-avalanche blockchain create myblockchain2
-```
-```bash
-✔ Subnet-EVM
-✔ I want to use defaults for a test environment
-✔ Chain ID: 2
-✔ Token Symbol: chain2
-prefunding address 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC with balance 1000000000000000000000000
-✓ Successfully created blockchain configuration
-```
-</Step>
-<Step>
-### Deploy the new blockchain `myblockchain2`
-```bash
-avalanche blockchain deploy myblockchain2
-```
-```bash
-✔ Local Network
-```
-</Step>
-<Step>
-### Get the `Teleporter Registry Address` of `myblockchain2`
-
-```bash
-avalanche blockchain describe myblockchain2
-```
-
-```
-+-------------------------------------------------------------------------------------------+
-|                                         TELEPORTER                                        |
-+---------------+------------------------------+--------------------------------------------+
-| Local Network | Teleporter Messenger Address | 0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf |
-|               +------------------------------+--------------------------------------------+
-|               | Teleporter Registry Address  | 0xa3493940a13b426BD2f7dA6E55A39c060C0e6020 | // [!code highlight]
-+---------------+------------------------------+--------------------------------------------+
-```
-</Step>
-<Step>
-### Save the `Teleporter Registry Address`
-
-Most other environment variables we will need are already set in the devcontainer or from the [previous section](/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/01-erc-20-to-erc-20-bridge).
-```bash
-export TELEPORTER_REGISTRY_CHAIN2=0xa3493940a13b426BD2f7dA6E55A39c060C0e6020
-```
-</Step>
-<Step>
-
-### Get the `Blockchain ID (hex)` of `myblockchain2`
-
-
-```
-+---------------------------------------------------------------------------------------------------------------+
-|                                                 MYBLOCKCHAIN2                                                 |
-+---------------+-----------------------------------------------------------------------------------------------+
-| Name          | myblockchain2                                                                                 |
-+---------------+-----------------------------------------------------------------------------------------------+
-| VM ID         | qDNV9vtxZYYNqm7TSa9KnDTRabGxtBLv6vd888791J9a89kTF                                             |
-+---------------+-----------------------------------------------------------------------------------------------+
-| VM Version    | v0.6.9                                                                                        |
-+---------------+--------------------------+--------------------------------------------------------------------+
-| Local Network | ChainID                  | 2                                                                  |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | SubnetID                 | 2KhsQJhH3VqS7WWMreodAAHpGfGCUNuGQDSaP2vUT29p1HELBV                 |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | Owners (Threhold=1)      | P-custom18jma8ppw3nhx5r4ap8clazz0dps7rv5u9xde7p                    |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | BlockchainID (CB58)      | 2ZempAyezixFRdJhJribDdj2wiK6YFF63CkXKaimfPb3hWeWVH                 |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | BlockchainID (HEX)       | 0xcdd5b2b99ae462c32a8e4ea47e94f2c7804519353558fd4127cf7ae11d8a6e52 | // [!code highlight]
-+---------------+--------------------------+--------------------------------------------------------------------+
-
-```
-</Step>
-<Step>
-
-### Save the Source Blockchain ID
-
-```bash
-export SOURCE_BLOCKCHAIN2_ID_HEX=0xcdd5b2b99ae462c32a8e4ea47e94f2c7804519353558fd4127cf7ae11d8a6e52
-```
-
-</Step>
-
-<Step>
-### Add `myblockchain2` RPC to `foundry.toml` config
-```toml
-[rpc_endpoints]
-local-c = "http://localhost:9650/ext/bc/C/rpc"
-myblockchain = "http://localhost:9650/ext/bc/myblockchain/rpc"
-myblockchain2 = "http://localhost:9650/ext/bc/myblockchain2/rpc" // [!code highlight]
-```
-</Step>
-</Steps>
\ No newline at end of file
diff --git a/content/course/interchain-token-transfer/07-tokens-on-multiple-chains/03-deploy-token-remote.mdx b/content/course/interchain-token-transfer/07-tokens-on-multiple-chains/03-deploy-token-remote.mdx
deleted file mode 100644
index 951d63fd..00000000
--- a/content/course/interchain-token-transfer/07-tokens-on-multiple-chains/03-deploy-token-remote.mdx
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: Deploy Token Remote for Multi-hop
-description: Deploy and configure the ERC20TokenRemote contract on the second blockchain.
-updated: 2024-05-31
-authors: [owenwahlgren]
-icon: Book
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-
-<Steps>
-<Step>
-### Deploy the Remote Contract
-
-Using the [`forge create`](https://book.getfoundry.sh/reference/forge/forge-create) command, we will deploy the `ERC20TokenRemote.sol` contract, passing in the following constructor arguments:
-
-- Interchain Messaging Registry Address **(for `myblockchain2`)**
-- Interchain Messaging Manager (our funded address)
-- Source Blockchain ID (hexidecimal representation of Avalanche C-Chain)
-- Token Home Address (address of `NativeTokenHome.sol` deployed on Avalanche C-Chain in the [Deploy a Home Contract](/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/03-deploy-home) section)
-- Token Name (input in the constructor of the [wrapped token contract](https://github.com/ava-labs/avalanche-interchain-token-transfer/blob/main/contracts/src/WrappedNativeToken.sol))
-- Token Symbol (input in the constructor of the [wrapped token contract](https://github.com/ava-labs/avalanche-interchain-token-transfer/blob/main/contracts/src/WrappedNativeToken.sol))
-- Token Decimals (uint8 integer representing number of decimal places for the ERC20 token being created. Most ERC20 tokens follow the Ethereum standard, which defines 18 decimal places.)
-
-```bash
-forge create --rpc-url myblockchain2 --private-key $PK \
-lib/avalanche-interchain-token-transfer/contracts/src/TokenRemote/ERC20TokenRemote.sol:ERC20TokenRemote \
---constructor-args "(${TELEPORTER_REGISTRY_CHAIN2}, ${FUNDED_ADDRESS}, ${C_CHAIN_BLOCKCHAIN_ID_HEX}, ${ERC20_HOME_C_CHAIN}, 18)" "TOK" "TOK" 18
-```
-
-</Step>
-<Step>
-
-### Save the Remote Contract Address
-
-Note the address the remote contract was "Deployed to".
-
-```bash
-export ERC20_TOKEN_REMOTE_CHAIN2=<"Deployed to" address>
-```
-
-</Step>
-<Step>
-
-### Register Remote Contract with Home Contract
-
-After deploying the bridge contracts, you'll need to register the remote bridge by sending a dummy message using the `registerWithHome` method. This message includes details which inform the Home Bridge about your destination blockchain and bridge settings, eg. `initialReserveImbalance`.
-
-```bash
-cast send --rpc-url myblockchain2 --private-key $PK $ERC20_TOKEN_REMOTE_CHAIN2 \
-"registerWithHome((address, uint256))" "(0x0000000000000000000000000000000000000000, 0)"
-```
-
-</Step>
-<Step>
-
-### Approve tokens for the Token Remote contract on `myblockchain`
-Now that our `ERC20TokenRemote` contract is deployed and configured on `myblockchain2`, we need to prepare `myblockchain` for the token transfer. 
-We will approve the `ERC20TokenRemote` contract to spend a certain amount of tokens on behalf of the sender.
-
-You can increase/decrease the numbers here as per your requirements. (All values are mentioned in wei)
-
-```bash
-cast send --rpc-url myblockchain --private-key $PK $ERC20_TOKEN_REMOTE_L1 \
-"approve(address, uint256)" $ERC20_TOKEN_REMOTE_L1 2000000000000000000000
-```
-
-</Step>
-</Steps>
diff --git a/content/course/interchain-token-transfer/07-tokens-on-multiple-chains/04-multihop.mdx b/content/course/interchain-token-transfer/07-tokens-on-multiple-chains/04-multihop.mdx
deleted file mode 100644
index a9becd69..00000000
--- a/content/course/interchain-token-transfer/07-tokens-on-multiple-chains/04-multihop.mdx
+++ /dev/null
@@ -1,41 +0,0 @@
----
-title: Multi-hop Transfer
-description: Perform the multi-hop transfer of `TOK` from `myblockchain` to `myblockchain2`, with a 'hop' through the Avalanche C-Chain.
-updated: 2024-05-31
-authors: [owenwahlgren]
-icon: Book
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-<Steps>
-<Step>
-
-### Transfer the Token Cross-chain with a Multi-hop Transfer
-
-Now that all the bridge contracts have been deployed and configured, send the ERC-20 token from `myblockchain` to `myblockchain2` with the [`cast send`](https://book.getfoundry.sh/reference/cast/cast-send) foundry command.
-
-The token will be routed through the Avalanche C-Chain and then to `myblockchain2`.
-
-```bash
-cast send --rpc-url myblockchain --private-key $PK $ERC20_TOKEN_REMOTE_L1 \
-"send((bytes32, address, address, address, uint256, uint256, uint256, address), uint256)" \
-"(${SOURCE_BLOCKCHAIN2_ID_HEX}, ${ERC20_TOKEN_REMOTE_CHAIN2}, ${FUNDED_ADDRESS}, ${ERC20_C_CHAIN}, 0, 0, 250000, ${FUNDED_ADDRESS})" 500000000000000
-```
-
-</Step>
-<Step>
-
-### Check Balance
-
-To confirm the token was bridged from `myblockchain1` to `myblockchain2` via the C-Chain, we will check the recipient's balance on `myblockchain2` with the [`cast call`](https://book.getfoundry.sh/reference/cast/cast-call?highlight=cast%20call#cast-call) foundry command:
-
-```bash
-cast call --rpc-url myblockchain2 $ERC20_TOKEN_REMOTE_CHAIN2 "balanceOf(address)(uint)" $FUNDED_ADDRESS
-```
-
-```bash
-500000000000000 [5e14]
-```
-</Step>
-</Steps> 
diff --git a/content/course/interchain-token-transfer/08-native-to-erc-20-bridge/01-native-to-erc-20-bridge.mdx b/content/course/interchain-token-transfer/08-native-to-erc-20-bridge/01-native-to-erc-20-bridge.mdx
deleted file mode 100644
index e6ca628b..00000000
--- a/content/course/interchain-token-transfer/08-native-to-erc-20-bridge/01-native-to-erc-20-bridge.mdx
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Native to ERC-20 Token Bridge Overview
-description: Learn how to transfer native Avalanche L1 tokens to the C-Chain as ERC-20 tokens.
-updated: 2024-09-09
-authors: [owenwahlgren]
-icon: Book
----
-
-ICTT is also capable of bridging native tokens from Avalanche L1s to the C-Chain as ERC-20 tokens. This process involves deploying a `NativeTokenHome` contract on the Avalanche L1, and a `ERC20TokenRemote` contract on the C-Chain. The `NativeTokenHome` contract will be used to bridge the native token to the C-Chain as an ERC-20 token.
-
-This example will cover native to ERC-20 token bridging between `myblockchain` and the C-Chain, but the process can be adapted to bridge the C-Chain's native asset, `AVAX`, to any L1 as an ERC-20 token.
-
-### What we will do
-1. Deploy a Wrapped Native Token to `myblockchain`
-2. Deploy the `NativeTokenHome` contract on `myblockchain`
-3. Deploy the `ERC20TokenRemote` contract on the C-Chain
-4. Register `ERC20TokenRemote` on C-Chain with `NativeTokenHome` on `myblockchain`
-4. Perform a transfer of the native token on `myblockchain` to the C-Chain as an ERC-20 token
diff --git a/content/course/interchain-token-transfer/08-native-to-erc-20-bridge/02-deploy-wrapped-native.mdx b/content/course/interchain-token-transfer/08-native-to-erc-20-bridge/02-deploy-wrapped-native.mdx
deleted file mode 100644
index 38df08e8..00000000
--- a/content/course/interchain-token-transfer/08-native-to-erc-20-bridge/02-deploy-wrapped-native.mdx
+++ /dev/null
@@ -1,34 +0,0 @@
----
-title: Deploy Wrapped Native Token Contracts
-description: Deploy the wrapped native token contract to the Avalanche L1 blockchain.
-updated: 2024-05-31
-authors: [ashucoder9, owenwahlgren]
-icon: Book
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-<Steps>
-<Step>
-### Deploy Wrapped Native Token `ExampleWNATV`
-
-```bash
-forge create --rpc-url myblockchain --private-key $PK contracts/interchain-token-transfer/ExampleWNATV.sol:WNATV
-```
-```
-[⠊] Compiling...
-[⠰] Compiling 7 files with Solc 0.8.18
-[⠔] Solc 0.8.18 finished in 371.02ms
-Compiler run successful!
-Deployer: 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-Deployed to: 0x52C84043CD9c865236f11d9Fc9F56aa003c1f922 // [!code highlight]
-Transaction hash: 0x481398f0648cd2298a6e14fcbc474f71feaff9c85eb367100b31bb7a2213232b
-```
-</Step>
-<Step>
-### Save the Wrapped Native Token Address
-
-```bash
-export WRAPPED_ERC20_L1=0x52C84043CD9c865236f11d9Fc9F56aa003c1f922
-```
-</Step>
-</Steps>
\ No newline at end of file
diff --git a/content/course/interchain-token-transfer/08-native-to-erc-20-bridge/03-deploy-native-token-home.mdx b/content/course/interchain-token-transfer/08-native-to-erc-20-bridge/03-deploy-native-token-home.mdx
deleted file mode 100644
index 6edaee1f..00000000
--- a/content/course/interchain-token-transfer/08-native-to-erc-20-bridge/03-deploy-native-token-home.mdx
+++ /dev/null
@@ -1,103 +0,0 @@
----
-title: Deploy Native Token Home
-description: Deploy the NativeTokenHome contract on the Avalanche L1 blockchain.
-updated: 2024-05-31
-authors: [owenwahlgren]
-icon: Book
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-<Callout>You may already have `TELEPORTER_REGISTRY_L1` and `SOURCE_BLOCKCHAIN_ID_HEX` set from previous sections. If you do, you can skip to step 5.</Callout>
-<Steps>
-<Step>
-### Get the `Teleporter Registry Address` of `myblockchain`
-
-```bash
-avalanche blockchain describe myblockchain
-```
-
-```
-+-------------------------------------------------------------------------------------------+
-|                                         TELEPORTER                                        |
-+---------------+------------------------------+--------------------------------------------+
-| Local Network | Teleporter Messenger Address | 0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf |
-|               +------------------------------+--------------------------------------------+
-|               | Teleporter Registry Address  | 0xB4DC3d786D658d118631F5C6B75CB5935be8407C | // [!code highlight]
-+---------------+------------------------------+--------------------------------------------+
-```
-</Step>
-<Step>
-### Save the `Teleporter Registry Address`
-
-Most other environment variables we will need are already set in the devcontainer or from the [previous section](/course/interchain-token-transfer/06-erc-20-to-erc-20-bridge/01-erc-20-to-erc-20-bridge).
-```bash
-export TELEPORTER_REGISTRY_L1=0xa3493940a13b426BD2f7dA6E55A39c060C0e6020
-```
-</Step>
-<Step>
-
-### Get the `Blockchain ID (hex)` of `myblockchain`
-
-
-```
-+---------------------------------------------------------------------------------------------------------------+
-|                                                 MYBLOCKCHAIN                                                  |
-+---------------+-----------------------------------------------------------------------------------------------+
-| Name          | myblockchain                                                                                  |
-+---------------+-----------------------------------------------------------------------------------------------+
-| VM ID         | qDNV9vtxZYYNqm7TSa9KnDTRabGxtBLv6vd888791J9a89kTF                                             |
-+---------------+-----------------------------------------------------------------------------------------------+
-| VM Version    | v0.6.9                                                                                        |
-+---------------+--------------------------+--------------------------------------------------------------------+
-| Local Network | ChainID                  | 1                                                                  |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | SubnetID                 | 2KhsQJhH3VqS7WWMreodAAHpGfGCUNuGQDSaP2vUT29p1HELBV                 |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | Owners (Threhold=1)      | P-custom18jma8ppw3nhx5r4ap8clazz0dps7rv5u9xde7p                    |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | BlockchainID (CB58)      | 2ZempAyezixFRdJhJribDdj2wiK6YFF63CkXKaimfPb3hWeWVH                 |
-|               +--------------------------+--------------------------------------------------------------------+
-|               | BlockchainID (HEX)       | 0xcdd5b2b99ae462c32a8e4ea47e94f2c7804519353558fd4127cf7ae11d8a6e52 | // [!code highlight]
-+---------------+--------------------------+--------------------------------------------------------------------+
-
-```
-</Step>
-<Step>
-
-### Save the `Blockchain ID (hex)`
-
-```bash
-export SOURCE_BLOCKCHAIN_ID_HEX=0xcdd5b2b99ae462c32a8e4ea47e94f2c7804519353558fd4127cf7ae11d8a6e52
-```
-
-</Step>
-<Step>
-### Deploy `NativeTokenHome` on `myblockchain`
-
-Using the [`forge create`](https://book.getfoundry.sh/reference/forge/forge-create) command, we will deploy the [NativeTokenHome.sol](https://github.com/ava-labs/avalanche-interchain-token-transfer/blob/main/contracts/src/TokenHome/NativeTokenHome.sol) contract, passing in the following constructor arguments:
-
-- Interchain Messaging Registry (for our Avalanche L1)
-- Interchain Messaging Manager (our funded address)
-- Wrapped Token Address (deployed in the last step)
-
-```bash
-forge create --rpc-url myblockchain --private-key $PK lib/avalanche-interchain-token-transfer/contracts/src/TokenHome/NativeTokenHome.sol:NativeTokenHome --constructor-args $TELEPORTER_REGISTRY_L1 $FUNDED_ADDRESS $WRAPPED_ERC20_L1
-```
-```
-[⠊] Compiling...
-[⠊] Compiling 22 files with Solc 0.8.18
-[⠒] Solc 0.8.18 finished in 1.95s
-Compiler run successful!
-Deployer: 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-Deployed to: 0x17aB05351fC94a1a67Bf3f56DdbB941aE6c63E25 // [!code highlight]
-Transaction hash: 0x91c60be19a69aadb1415112dd42302764b30bc48f09957c3a191021d70ccc9d4
-```
-</Step>
-<Step>
-### Save the Native Token Home Address
-
-```bash 
-export ERC20_HOME_BRIDGE_L1=0x17aB05351fC94a1a67Bf3f56DdbB941aE6c63E25
-```
-</Step>
-</Steps>
\ No newline at end of file
diff --git a/content/course/interchain-token-transfer/08-native-to-erc-20-bridge/04-deploy-erc20-token-remote.mdx b/content/course/interchain-token-transfer/08-native-to-erc-20-bridge/04-deploy-erc20-token-remote.mdx
deleted file mode 100644
index 68993ca1..00000000
--- a/content/course/interchain-token-transfer/08-native-to-erc-20-bridge/04-deploy-erc20-token-remote.mdx
+++ /dev/null
@@ -1,57 +0,0 @@
----
-title: Deploy ERC20 Token Remote
-description: Deploy and register the ERC20TokenRemote contract to the Avalanche C-Chain.
-updated: 2024-05-31
-authors: [owenwahlgren]
-icon: Book
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-<Steps>
-<Step>
-### Deploy `ERC20TokenRemote` on C-Chain
-
-Using the [`forge create`](https://book.getfoundry.sh/reference/forge/forge-create) command, we will deploy the [ERC20TokenRemote.sol](https://github.com/ava-labs/avalanche-interchain-token-transfer/blob/main/contracts/src/TokenRemote/ERC20TokenRemote.sol) contract, passing in the following constructor arguments:
-
-- Interchain Messaging Registry Address **(for C-Chain)**
-- Interchain Messaging Manager (our funded address)
-- Source Blockchain ID (hexidecimal representation of our Avalanche L1's Blockchain ID `myblockchain`)
-- Token Home Address (address of NativeTokenHome.sol deployed on our Avalanche L1 `myblockchain` in the last step)
-- Token Name (input in the constructor of the [wrapped token contract](https://github.com/ava-labs/avalanche-interchain-token-transfer/blob/main/contracts/src/WrappedNativeToken.sol))
-- Token Symbol (input in the constructor of the [wrapped token contract](https://github.com/ava-labs/avalanche-interchain-token-transfer/blob/main/contracts/src/WrappedNativeToken.sol))
-- Token Decimals (uint8 integer representing number of decimal places for the ERC20 token being created; typically 18 decimals)
-
-
-```bash
-forge create --rpc-url local-c --private-key $PK lib/avalanche-interchain-token-transfer/contracts/src/TokenRemote/ERC20TokenRemote.sol:ERC20TokenRemote \
---constructor-args "(${TELEPORTER_REGISTRY_C_CHAIN}, ${FUNDED_ADDRESS}, ${SOURCE_BLOCKCHAIN_ID_HEX}, ${ERC20_HOME_BRIDGE_L1}, 18)" "Wrapped NATV" "WNATV" 18
-```
-```
-[⠊] Compiling...
-[⠆] Compiling 5 files with Solc 0.8.18
-[⠰] Solc 0.8.18 finished in 1.23s
-Compiler run successful!
-Deployer: 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-Deployed to: 0x5DB9A7629912EBF95876228C24A848de0bfB43A9 // [!code highlight]
-Transaction hash: 0x3d437a3421f7b2b1bf0276e9a80f57815291e62313584ff48afb69fb206b5daf
-```
-</Step>
-<Step>
-### Save the ERC20 Token Remote Address
-
-```bash
-export ERC20_TOKEN_REMOTE_C_CHAIN=0x5DB9A7629912EBF95876228C24A848de0bfB43A9
-```
-</Step>
-<Step>
-
-### Register `ERC20TokenRemote` on C-Chain with `NativeTokenHome` on `myblockchain`
-
-After deploying the bridge contracts, you'll need to register the remote bridge by sending a dummy message using the `registerWithHome` method. This message includes details which inform the home bridge about your destination blockchain and bridge settings, eg. `initialReserveImbalance`.
-
-```bash
-cast send --rpc-url local-c --private-key $PK $ERC20_TOKEN_REMOTE_C_CHAIN "registerWithHome((address, uint256))" "(0x0000000000000000000000000000000000000000, 0)"
-```
-</Step>
-
-</Steps>
\ No newline at end of file
diff --git a/content/course/interchain-token-transfer/08-native-to-erc-20-bridge/05-bridge-tokens.mdx b/content/course/interchain-token-transfer/08-native-to-erc-20-bridge/05-bridge-tokens.mdx
deleted file mode 100644
index b59d5626..00000000
--- a/content/course/interchain-token-transfer/08-native-to-erc-20-bridge/05-bridge-tokens.mdx
+++ /dev/null
@@ -1,36 +0,0 @@
----
-title: Native Token Bridge Transfer
-description: Perform a transfer of a native Avalanche L1 token to the C-Chain as an ERC-20 token.
-updated: 2024-05-31
-authors: [ashucoder9, owenwahlgren]
-icon: Book
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-<Steps>
-<Step>
-### Transfer the L1's Native Token to the C-Chain
-
-Now that all the bridge contracts have been deployed and configured, send some native tokens from your Avalanche L1 to C-Chain with the [`cast send`](https://book.getfoundry.sh/reference/cast/cast-send) foundry command.
-
-```bash
-cast send --rpc-url myblockchain --private-key $PK $ERC20_HOME_BRIDGE_L1 \
-"send((bytes32, address, address, address, uint256, uint256, uint256, address))" \
-"(${C_CHAIN_BLOCKCHAIN_ID_HEX}, ${ERC20_TOKEN_REMOTE_C_CHAIN}, ${FUNDED_ADDRESS}, 0x0000000000000000000000000000000000000000, 0, 0, 250000, 0x0000000000000000000000000000000000000000)"  --value 1ether
-```
-</Step>
-
-<Step>
-### Check Balance
-To confirm the token was bridged from Avalanche L1 to C-Chain, we will check the recipient's balance of wrapped tokens on the C-Chain with the [`cast call`](https://book.getfoundry.sh/reference/cast/cast-call?highlight=cast%20call#cast-call) foundry command:
-
-```bash
-cast call --rpc-url local-c $ERC20_TOKEN_REMOTE_C_CHAIN "balanceOf(address)(uint)" $FUNDED_ADDRESS
-```
-
-```bash
-1000000000000000000
-```
-**Success!** We have bridged 1 native token from our Avalanche L1 to the C-Chain as an ERC-20 token.
-</Step>
-</Steps>
diff --git a/content/course/interchain-token-transfer/12-send-and-call/01-intro.mdx b/content/course/interchain-token-transfer/12-send-and-call/01-intro.mdx
deleted file mode 100644
index d8219aa8..00000000
--- a/content/course/interchain-token-transfer/12-send-and-call/01-intro.mdx
+++ /dev/null
@@ -1,31 +0,0 @@
----
-title: Introduction
-description: Learn how to call another contract function after send tokens to another L1s.
-updated: 2024-08-23
-authors: [0xstt]
-icon: Book
----
-
-In addition to supporting basic token transfers, the token transferrer contracts offer a `sendAndCall` interface for bridging tokens and using them in a smart contract interaction all within a single Interchain Messaging message. If the call to the recipient smart contract fails, the transferred tokens are sent to a fallback recipient address on the destination chain of the transfer. The `sendAndCall` interface enables the direct use of transferred tokens in dApps on other chains, such as performing swaps, using the tokens to pay for fees when invoking services, etc.
-
-Teleporter Messenger has the ability to receive cross-chain messages on the destination chain and casts related messages to the `TeleporterMessage` struct. It then sends these messages to the Home/Remote Transferrer contract, and handles them as `SEND` or `CALL`, as implemented in `TokenHome.sol` or `TokenRemote.sol`.
-
-In this section we will cover the usage of the `CALL` message type with an example implementation.
-
-When `sendAndCall` function is triggered, the following actions are taken;
-
-- The Transferrer Contract grants an allowance to spend tokens on the destination contract.
-- The Transferrer Contract encodes the received message as parameters for the `receiveToken` function, as defined in the `IERC20SendAndCallReceiver` or `INativeSendAndCallReceiver` interface.
-- The Transferrer Contract checks whether the destination contract's function execution is successfull.
-- The Transferrer Contract retrieves the remaining allowance to check if there are any unspent tokens exists.
-- The Transferrer Contract removes the allowance for the destination contract.
-- The Transferrer Contract sends the remaining tokens to the fallback recipient. If the destination contract fails to execute the function, the full amount will be sent to the fallback recipient.
-
-## Prerequisites
-
-The following prerequisites were covered in previous sections, so you should have already deployed the following contracts before starting this chapter:
-
-- Base ERC20 Token on L1
-- Home Transferrer Contract on L1
-- Remote Transferrer Contract on Fuji
-- A Running AWM-relayer from your L1 to Fuji
diff --git a/content/course/interchain-token-transfer/12-send-and-call/03-send-and-call-receivers.mdx b/content/course/interchain-token-transfer/12-send-and-call/03-send-and-call-receivers.mdx
deleted file mode 100644
index 5852e342..00000000
--- a/content/course/interchain-token-transfer/12-send-and-call/03-send-and-call-receivers.mdx
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: Send and Call Receivers
-description: Learn how tokens are received by the receivers.
-updated: 2024-08-23
-authors: [0xstt]
-icon: BookOpen
----
-
-The interfaces `IERC20SendAndCallReceiver` or `INativeSendAndCallReceiver` are used for contracts that handle receiving ERC20 or native tokens of the Interchain Token Transfer protocol. They are similar to the `ITeleporterReceiver` interface, but they are specifically designed to handle token transfers.
-
-### IERC20SendAndCallReceiver
-
-The `receiveTokens` function will be called by the Transferrer bridge contract. The contract must implement this function to receive the tokens and can retrieve all the information about the origin of the tokens, the token, the bridge used, and the amount of tokens transferred from the parameters.
-
-```solidity title="lib/avalanche-interchain-token-transfer/contracts/src/interfaces/IERC20SendAndCallReceiver.sol"
-/**
- * @notice Interface for contracts that are called to receive token transfers.
- */
-interface IERC20SendAndCallReceiver {
-    /**
-     * @notice Called to receive the amount of the given token
-     * @param sourceBlockchainID Blockchain ID that the transfer originated from
-     * @param originTokenTransferrerAddress Address of the token transferrer that initiated the Teleporter message
-     * @param originSenderAddress Address of the sender that sent the transfer. This value
-     * should only be trusted if {originTokenTransferrerAddress} is verified and known.
-     * @param token Address of the token to be received
-     * @param amount Amount of the token to be received
-     * @param payload Arbitrary data provided by the caller
-     */
-    function receiveTokens(
-        bytes32 sourceBlockchainID,
-        address originTokenTransferrerAddress,
-        address originSenderAddress,
-        address token,
-        uint256 amount,
-        bytes calldata payload
-    ) external;
-}
-```
-
-### INativeSendAndCallReceiver
-
-The `INativeSendAndCallReceiver` interface is used for contracts that handle receiving native tokens of the Interchain Token Transfer protocol. It is similar to the `IERC20SendAndCallReceiver` interface, but does not include the `token` and `amount` parameters. The `receiveTokens` is now `payable`. There is only a single native token on each chain, so the address is not needed. The amount can be determined from calling `msg.value`.
-
-```solidity title="lib/avalanche-interchain-token-transfer/contracts/src/interfaces/INativeSendAndCallReceiver.sol"
-/**
- * @notice Interface for a contracts that are called to receive native tokens.
- */
-interface INativeSendAndCallReceiver {
-    /**
-     * @notice Called to receive the amount of the native token. Implementations
-     * must properly handle the msg.value of the call in order to ensure it doesn't
-     * become improperly made inaccessible.
-     * @param sourceBlockchainID Blockchain ID that the transfer originated from
-     * @param originTokenTransferrerAddress Address of the token transferrer that initiated the Teleporter message
-     * @param originSenderAddress Address of the sender that sent the transfer. This value
-     * should only be trusted if {originTokenTransferrerAddress} is verified and known.
-     * @param payload Arbitrary data provided by the caller
-     */
-    function receiveTokens(
-        bytes32 sourceBlockchainID,
-        address originTokenTransferrerAddress,
-        address originSenderAddress,
-        bytes calldata payload
-    ) external payable;
-}
-```
\ No newline at end of file
diff --git a/content/course/interchain-token-transfer/12-send-and-call/04-mock-receivers.mdx b/content/course/interchain-token-transfer/12-send-and-call/04-mock-receivers.mdx
deleted file mode 100644
index 294710e5..00000000
--- a/content/course/interchain-token-transfer/12-send-and-call/04-mock-receivers.mdx
+++ /dev/null
@@ -1,93 +0,0 @@
----
-title: Mock Receivers
-description: A brief overview of the mock ERC20 and native token receivers used for testing in sendAndCall functions.
-updated: 2024-08-23
-authors: [0xstt]
-icon: BookOpen
----
-
-The primary purpose of these mock contracts is to test cross-chain token transfers and execute contract logic. These contracts implement the `IERC20SendAndCallReceiver` and `INativeSendAndCallReceiver` interfaces to handle token transfers, either for ERC20 tokens or native tokens, across Avalanche L1s.
-
-This contract only performs the following actions:
-
-- Checks if the message was received from a blocked sender.
-- Emits a TokensReceived event.
-- Checks if the payload is empty.
-- Receives tokens to itself.
-
-```solidity title="lib/avalanche-interchain-token-transfer/contracts/src/mocks/MockERC20SendAndCallReceiver.sol"
-pragma solidity 0.8.25;
-
-import {IERC20SendAndCallReceiver} from "../interfaces/IERC20SendAndCallReceiver.sol";
-import {SafeERC20TransferFrom} from "../utils/SafeERC20TransferFrom.sol";
-import {SafeERC20} from "@openzeppelin/contracts@5.0.2/token/ERC20/utils/SafeERC20.sol";
-import {IERC20} from "@openzeppelin/contracts@5.0.2/token/ERC20/IERC20.sol";
-import {Context} from "@openzeppelin/contracts@5.0.2/utils/Context.sol";
-
-/**
- * THIS IS AN EXAMPLE CONTRACT THAT USES UN-AUDITED CODE.
- * DO NOT USE THIS CODE IN PRODUCTION.
- */
-
-/**
- * @notice This is mock implementation of {receiveTokens} to be used in tests.
- * This contract DOES NOT provide a mechanism for accessing the tokens transfered to it.
- * Real implementations must ensure that tokens are properly handled and not incorrectly locked.
- */
-contract MockERC20SendAndCallReceiver is Context, IERC20SendAndCallReceiver {
-    using SafeERC20 for IERC20;
-
-    mapping(bytes32 blockchainID => mapping(address senderAddress => bool blocked)) public
-        blockedSenders;
-
-    /**
-     * @dev Emitted when receiveTokens is called.
-     */
-    event TokensReceived(
-        bytes32 indexed sourceBlockchainID,
-        address indexed originTokenTransferrerAddress,
-        address indexed originSenderAddress,
-        address token,
-        uint256 amount,
-        bytes payload
-    );
-
-    /** // [!code highlight:28]
-     * @dev See {IERC20SendAndCallReceiver-receiveTokens}
-     */
-    function receiveTokens(
-        bytes32 sourceBlockchainID,
-        address originTokenTransferrerAddress,
-        address originSenderAddress,
-        address token,
-        uint256 amount,
-        bytes calldata payload
-    ) external {
-        require(
-            !blockedSenders[sourceBlockchainID][originSenderAddress],
-            "MockERC20SendAndCallReceiver: sender blocked"
-        );
-        emit TokensReceived({
-            sourceBlockchainID: sourceBlockchainID,
-            originTokenTransferrerAddress: originTokenTransferrerAddress,
-            originSenderAddress: originSenderAddress,
-            token: token,
-            amount: amount,
-            payload: payload
-        });
-
-        require(payload.length > 0, "MockERC20SendAndCallReceiver: empty payload");
-
-        SafeERC20TransferFrom.safeTransferFrom(IERC20(token), _msgSender(), amount);
-    }
-
-    /**
-     * @notice Block a sender from sending tokens to this contract.
-     * @param blockchainID The blockchain ID of the sender.
-     * @param senderAddress The address of the sender.
-     */
-    function blockSender(bytes32 blockchainID, address senderAddress) external {
-        blockedSenders[blockchainID][senderAddress] = true;
-    }
-}
-```
\ No newline at end of file
diff --git a/content/course/interchain-token-transfer/12-send-and-call/05-mock-receiver.mdx b/content/course/interchain-token-transfer/12-send-and-call/05-mock-receiver.mdx
deleted file mode 100644
index b92a8aa7..00000000
--- a/content/course/interchain-token-transfer/12-send-and-call/05-mock-receiver.mdx
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title: Deploy a Mock Receiver
-description: Learn how to deploy a mock receiver contract.
-updated: 2024-08-23
-authors: [0xstt]
-icon: Terminal
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-In this section, you will deploy mock receiver contracts on the Avalanche L1. 
-
-<Steps>
-<Step>
-
-### Receiver Deployment
-
-You can choose to deploy either the `MockERC20SendAndCallReceiver` or the `MockNativeSendAndCallReceiver` contract depending your token type.
-
-```bash
-forge create --rpc-url myblockchain --private-key $PK lib/avalanche-interchain-token-transfer/contracts/src/mocks/MockERC20SendAndCallReceiver.sol:MockERC20SendAndCallReceiver
-```
-
-</Step>
-<Step>
-
-### Save Receiver Address
-
-After deployment, save the `Deployed to` address in an environment variable for future use.
-
-```bash
-export MOCK_RECEIVER_ADDRESS=<address>
-```
-
-</Step>
-<Step>
-
-### Send Tokens
-
-Use the following command to send tokens to the mock receiver contract:
-
-```bash
-cast send --rpc-url myblockchain --private-key $PK $ERC20_HOME_C_CHAIN \
-"sendAndCall((bytes32, address, address, bytes, uint256, uint256, address, address, address, uint256, uint256), uint256)" \
-"(${C_CHAIN_BLOCKCHAIN_ID_HEX}, ${ERC20_TOKEN_REMOTE_L1}, ${MOCK_RECEIVER_ADDRESS}, 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, 2500000, 2000000, 0x0000000000000000000000000000000000000000, ${FUNDED_ADDRESS}, ${ERC20_HOME_C_CHAIN}, 0, 0)" 100000000000000000000
-```
-
-</Step>
-<Step>
-
-### Verify the Results
-
-Check the logs and emitted events to verify that the tokens were received correctly.
-
-TBD: Provide instructions
-
-</Step>
-</Steps>
-
-After successfully deploying the contract, move on to testing the mock receivers.
\ No newline at end of file
diff --git a/content/course/interchain-token-transfer/13-cross-chain-token-swaps/07-exchange-contract.mdx b/content/course/interchain-token-transfer/13-cross-chain-token-swaps/07-exchange-contract.mdx
deleted file mode 100644
index d1b5a20e..00000000
--- a/content/course/interchain-token-transfer/13-cross-chain-token-swaps/07-exchange-contract.mdx
+++ /dev/null
@@ -1,165 +0,0 @@
----
-title: Wrap Exchange Contract
-description: Wrap the exchange contract to execute cross-chain swap operations.
-updated: 2024-08-23
-authors: [0xstt]
-icon: Book
----
-
-In this example, we will wrap Trader Joe's Factory contract to execute swap operations on the destination chain. Trader Joe's exchange contracts are already deployed on Fuji, which why we are choosing Fuji as the destination chain.
-
-An example of the exchange wrapper code is provided below. This contract only allows swap operations on Trader Joe V1 pools or any other Uniswap V2-like contracts.
-
-**Walkthrough**:
-
-- The wrapper contract receives the payload via the `receiveTokens` function.
-- The wrapper contract transfers the tokens to itself.
-- The wrapper contract gets a quote from the exchange.
-- The wrapper contract casts `payload` into `SwapOptions` struct.
-- The wrapper contract checks if the received `amountOut` is greater than the `minAmountOut` requested when the contract was called from the source chain.
-- The wrapper contract executes the swap operation and transfers the received asset to caller, depending on the preferred asset (wrapped token or native token).
-
-_Disclaimer: The avalanche-interchain-token-transfer contracts used in this tutorial are under active development and are not yet intended for production deployments. Use at your own risk._
-
-```solidity  title="src/interchain-token-transfer/4-send-and-call/DexERC20Wrapper.sol"
-// (c) 2024, Ava Labs, Inc. All rights reserved.
-// See the file LICENSE for licensing terms.
-
-// SPDX-License-Identifier: Ecosystem
-
-pragma solidity 0.8.18;
-
-import {IERC20SendAndCallReceiver} from "../interfaces/IERC20SendAndCallReceiver.sol";
-import {SafeERC20TransferFrom} from "../utils/SafeERC20TransferFrom.sol";
-import {SafeERC20} from "@openzeppelin/contracts@4.8.1/token/ERC20/utils/SafeERC20.sol";
-import {IERC20} from "@openzeppelin/contracts@4.8.1/token/ERC20/IERC20.sol";
-import {Context} from "@openzeppelin/contracts@4.8.1/utils/Context.sol";
-
-import {IWAVAX} from "./interface/IWAVAX.sol";
-import {IUniswapFactory} from "./interface/IUniswapFactory.sol";
-import {IUniswapPair} from "./interface/IUniswapPair.sol";
-
-/**
- * THIS IS AN EXAMPLE CONTRACT THAT USES UN-AUDITED CODE.
- * DO NOT USE THIS CODE IN PRODUCTION.
- */
-
-contract DexERC20Wrapper is Context, IERC20SendAndCallReceiver {
-    using SafeERC20 for IERC20;
-
-    address public immutable WNATIVE;
-    address public immutable factory;
-
-    struct SwapOptions {
-        address tokenOut;
-        uint256 minAmountOut;
-    }
-
-    constructor(
-        address wrappedNativeAddress,
-        address dexFactoryAddress
-    ) {
-        WNATIVE = wrappedNativeAddress;
-        factory = dexFactoryAddress;
-    }
-
-    event TokensReceived(
-        bytes32 indexed sourceBlockchainID,
-        address indexed originTokenTransferrerAddress,
-        address indexed originSenderAddress,
-        address token,
-        uint256 amount,
-        bytes payload
-    );
-
-    // To receive native when another contract called.
-    receive() external payable {}
-
-    function getAmountOut(
-        uint256 amountIn,
-        uint256 reserveIn,
-        uint256 reserveOut
-    ) internal pure returns (uint256 amountOut) {
-        uint256 amountInWithFee = amountIn * 997;
-        uint256 numerator = amountInWithFee * reserveOut;
-        uint256 denominator = reserveIn * 1e3 + amountInWithFee;
-        amountOut = numerator / denominator;
-    }
-
-    function query(
-        uint256 amountIn,
-        address tokenIn,
-        address tokenOut
-    ) internal view returns (uint256 amountOut) {
-        if (tokenIn == tokenOut || amountIn == 0) {
-            return 0;
-        }
-        address pair = IUniswapFactory(factory).getPair(tokenIn, tokenOut);
-        if (pair == address(0)) {
-            return 0;
-        }
-        (uint256 r0, uint256 r1, ) = IUniswapPair(pair).getReserves();
-        (uint256 reserveIn, uint256 reserveOut) = tokenIn < tokenOut ? (r0, r1) : (r1, r0);
-        if (reserveIn > 0 && reserveOut > 0) {
-            amountOut = getAmountOut(amountIn, reserveIn, reserveOut);
-        }
-    }
-
-    function swap(
-        uint256 amountIn,
-        uint256 amountOut,
-        address tokenIn,
-        address tokenOut,
-        address to
-    ) internal {
-        address pair = IUniswapFactory(factory).getPair(tokenIn, tokenOut);
-        (uint256 amount0Out, uint256 amount1Out) = (tokenIn < tokenOut)
-            ? (uint256(0), amountOut) : (amountOut, uint256(0));
-        IERC20(tokenIn).safeTransfer(pair, amountIn);
-        IUniswapPair(pair).swap(amount0Out, amount1Out, to, new bytes(0));
-    }
-
-    function receiveTokens(
-        bytes32 sourceBlockchainID,
-        address originTokenTransferrerAddress,
-        address originSenderAddress,
-        address token,
-        uint256 amount,
-        bytes calldata payload
-    ) external {
-        emit TokensReceived({
-            sourceBlockchainID: sourceBlockchainID,
-            originTokenTransferrerAddress: originTokenTransferrerAddress,
-            originSenderAddress: originSenderAddress,
-            token: token,
-            amount: amount,
-            payload: payload
-        });
-
-        require(payload.length > 0, "DexERC20Wrapper: empty payload");
-
-        IERC20 _token = IERC20(token);
-        // Receives teleported assets to be used for different purposes.
-        SafeERC20TransferFrom.safeTransferFrom(_token, _msgSender(), amount);
-
-        // Requests a quote from the Uniswap V2-like contract.
-        uint256 amountOut = query(amount, token, WNATIVE);
-        require(amountOut > 0, "DexERC20Wrapper: insufficient liquidity");
-
-        // Parses the payload of the message.
-        SwapOptions memory swapOptions = abi.decode(payload, (SwapOptions));
-        // Checks if the target swap price is still valid.
-        require(amountOut >= swapOptions.minAmountOut, "DexERC20Wrapper: slippage exceeded");
-        
-        // Verifies if the desired tokenOut is a native or wrapped asset.
-        if (swapOptions.tokenOut == address(0)) {
-            swap(amount, amountOut, token, WNATIVE, address(this));
-            IWAVAX(WNATIVE).withdraw(amountOut);
-            payable(originSenderAddress).transfer(amountOut);
-        } else {
-            swap(amount, amountOut, token, WNATIVE, originSenderAddress);
-        }
-    }
-
-}
-```
\ No newline at end of file
diff --git a/content/course/interchain-token-transfer/13-cross-chain-token-swaps/08-deploy-wrapped-exchange-contract.mdx b/content/course/interchain-token-transfer/13-cross-chain-token-swaps/08-deploy-wrapped-exchange-contract.mdx
deleted file mode 100644
index fc698d32..00000000
--- a/content/course/interchain-token-transfer/13-cross-chain-token-swaps/08-deploy-wrapped-exchange-contract.mdx
+++ /dev/null
@@ -1,97 +0,0 @@
----
-title: Deploy Wrapped Exchange Contract
-description: Deploy the DexERC20Wrapper on your own blockchain
-updated: 2024-08-23
-authors: [0xstt]
-icon: Terminal
----
-
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-import { Accordion, Accordions } from 'fumadocs-ui/components/accordion';
-
-Let's deploy our wrapper for the exchange contract on your own blockchain. 
-
-<Steps>
-<Step>
-
-### Wrapper Deployment
-
-While deploying the wrapped exchange contract, you will need to send two constructor arguments to the contract.
-
-- The first argument is the wrapped native token (WAVAX) address on the destination chain (Fuji), which is: [`0xd00ae08403B9bbb9124bB305C09058E32C39A48c`](https://testnet.snowtrace.io/address/0xd00ae08403B9bbb9124bB305C09058E32C39A48c).
-- The second argument is the Trader Joe's (or any other Uniswap V2-like dapp) Factory V1 contract address on the destination chain (Fuji), which is: [`0xF5c7d9733e5f53abCC1695820c4818C59B457C2C`](https://testnet.snowtrace.io/address/0xF5c7d9733e5f53abCC1695820c4818C59B457C2C). Deployed contracts of TraderJoe can be found [here](https://docs.traderjoexyz.com/deployment-addresses/fuji).
-
-```bash
-forge create --rpc-url local-c --private-key $PK contracts/interchain-token-transfer/cross-chain-token-swaps/DexERC20Wrapper.sol:DexERC20Wrapper --constructor-args 0xd00ae08403B9bbb9124bB305C09058E32C39A48c 0xF5c7d9733e5f53abCC1695820c4818C59B457C2C
-```
-
-</Step>
-<Step>
-
-### Save the Wrapper Address
-
-Save the `Deployed to` address in an environment variable.
-
-
-```bash
-export WRAPPED_EXCHANGE_ADDRESS=<address>
-```
-
-In case you skipped the deployment phase mentioned on the previous page, you can use a wrapper contract, that is already deployed at [`0x38B097d95B96CD17966Cf617A71b7B20F61ba85B`](https://testnet.snowtrace.io/address/0x38B097d95B96CD17966Cf617A71b7B20F61ba85B).
-
-```bash
-export WRAPPED_EXCHANGE_ADDRESS=0x38B097d95B96CD17966Cf617A71b7B20F61ba85B
-```
-
-</Step>
-<Step>
-
-### Initiate the Cross-Chain Swap
-
-Now that the wrapped exchange contract has been deployed, send an ERC20 token to execute a swap for WAVAX or AVAX from your Avalanche L1 to Fuji using the [`cast send`](https://book.getfoundry.sh/reference/cast/cast-send) command in foundry.
-
-```bash
-cast send --rpc-url echo --private-key $PK $ERC20_HOME_C_CHAIN "sendAndCall((bytes32, address, address, bytes, uint256, uint256, address, address, address, uint256, uint256), uint256)" "(${C_CHAIN_BLOCKCHAIN_ID_HEX}, ${ERC20_TOKEN_REMOTE_L1}, ${WRAPPED_EXCHANGE_ADDRESS}, 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, 2500000, 2000000, 0x0000000000000000000000000000000000000000, ${FUNDED_ADDRESS}, ${ERC20_HOME_C_CHAIN}, 0, 0)" 100000000000000000000
-```
-
-<Accordions>
-<Accordion title="Generate Payload">
- 
-The ```payload``` parameter that we sent can be generated via following JavaScript file:
-
-```typescript
-const { ethers } = require("ethers");
-
-function encode() {
-
-    const struct = {
-        tokenOut: "0xd00ae08403B9bbb9124bB305C09058E32C39A48c",
-        minAmountOut: 0
-    };
-
-    const types = ["address", "uint256"];
-    const encoded = ethers.AbiCoder.defaultAbiCoder().encode(types, [ struct.tokenOut, struct.minAmountOut ]);
-
-    console.log(encoded);
-
-}
-
-encode();
-```
- 
-</Accordion>
-</Accordions>
-
-</Step>
-<Step>
-
-### Verify the Results
-
-TBD: Provide instructions
-
-</Step>
-</Steps>
-
-
-
-
diff --git a/content/course/interchain-token-transfer/14-scaling-decimals/01-math-example.mdx b/content/course/interchain-token-transfer/14-scaling-decimals/01-math-example.mdx
deleted file mode 100644
index 00518d36..00000000
--- a/content/course/interchain-token-transfer/14-scaling-decimals/01-math-example.mdx
+++ /dev/null
@@ -1,58 +0,0 @@
----
-title: Scaling with TokenRemote
-description: Learn how to handle token scaling with TokenRemote contracts when bridging assets with different decimal systems.
-updated: 2024-10-04
-authors: [owenwahlgren]
-icon: Calculator
----
-
-## Math Example
-
-Token scaling is a crucial part of cross-chain token transfers, especially when dealing with varying decimal denominations between the home and remote assets. This chapter will provide a math example to demonstrate how the scaling works with `TokenRemote` contracts.
-
-In this example, let's assume we are bridging an ERC-20 token from a home chain where the token uses 6 decimal places to a remote chain as the native token that uses 18 decimal places (e.g., USDC on Avalanche). 
-
-The key variables here are:
-- `_homeTokenDecimals = 6`
-- `_tokenDecimals = 18`
-- `_tokenMultiplier` is calculated as:
-
-<Mermaid chart={`
-sequenceDiagram
-    participant Home as TokenHome.sol (_homeTokenDecimals)
-    participant Remote as TokenRemote.sol (_tokenDecimals)
-    participant Multiplier as Token Multiplier (_tokenMultiplier)
-    
-    Home->>Remote: Calculate _tokenDecimals - _homeTokenDecimals
-    Remote->>Multiplier: 18 - 6 = 12
-    Multiplier-->>Multiplier: 10^12
-`} />
-
-This multiplier helps scale the token amounts when transferring between chains.
-
-### Scenario 1: Transferring from Home (6 decimals) to Remote (18 decimals)
-
-When transferring tokens from the home chain (6 decimals) to the remote chain (18 decimals), the token amount is multiplied by `_tokenMultiplier` to normalize the denomination. If `multiplyOnRemote = true`, we perform the following:
-
-For example, if we transfer **100 USDC** (which is represented as `100 × 10^6` in the 6-decimal system), it will be scaled as follows on the remote chain:
-
-```
-100 × 10^6 × 10^{12} = 100 × 10^{18}
-```
-Thus, the value on the remote chain would be 100 × 10^{18}, equivalent to 100 USDC in 18 decimals.
-
-### Scenario 2: Transferring from Remote (18 decimals) to Home (6 decimals)
-
-When transferring tokens back from the remote chain (18 decimals) to the home chain (6 decimals), the token amount is divided by `_tokenMultiplier`. If `multiplyOnRemote = true`, the reverse scaling applies:
-
-For example, transferring `100 × 10^{18}` (which is 100 USDC in the 18-decimal system) back to the home chain would scale down:
-
-```
-100 × 10^{18} ÷ 10^{12} = 100 × 10^6
-```
-
-This results in 100 × 10^6 USDC, which correctly represents 100 USDC in the 6-decimal system.
-
-By applying this multiplier, tokens retain their value across chains with different decimal systems.
-
-<Quiz quizId="126" />
diff --git a/content/course/interchain-token-transfer/14-scaling-decimals/02-example.mdx b/content/course/interchain-token-transfer/14-scaling-decimals/02-example.mdx
deleted file mode 100644
index a1f4a433..00000000
--- a/content/course/interchain-token-transfer/14-scaling-decimals/02-example.mdx
+++ /dev/null
@@ -1,129 +0,0 @@
----
-title: Example USDC as Native Token (DIY)
-description: Learn how to transfer USDC to a new Avalanche L1 and use it as a native token via ICTT.
-updated: 2024-09-03
-authors: [owenwahlgren]
-icon: Terminal
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-In this section, you will learn how to transfer USDC from Avalanche’s C-Chain to a new Avalanche L1 using Interchain Token Transfers (ICTT) and set it up to act as the **native token** on the new L1. This guide will take you through the steps of configuring a local network environment, deploying the necessary contracts, and transferring tokens.
-
-
-<Steps>
-<Step>
-### Create a new blockchain and Deploy on Local Network
-
-Use the **Avalanche CLI** to create a new blockchain where you will deploy USDC as the native token.
-
-
-```bash
-avalanche blockchain create myblockchain  
-```
-```bash
-avalanche blockchain deploy myblockchain
-```
-</Step>
-<Step>
-### Acquire USDC On Fuji C-Chain
-
-The address for USDC on Fuji C-Chain is [`0x5425890298aed601595a70ab815c96711a31bc65`](https://testnet.snowtrace.io/token/0x5425890298aed601595a70ab815c96711a31bc65).
-For convience we have already deployed a `TokenHome` to the C-Chain for USDC with the address [`0x546526F786115af1FE7c11aa8Ac5682b8c181E3A`](https://testnet.snowtrace.io/address/0x546526F786115af1FE7c11aa8Ac5682b8c181E3A)
-
-You can use the [Core Faucet to get some USDC](https://core.app/en/tools/testnet-faucet/?subnet=c&token=usdcc) on Fuji. 
-```bash
-export USDC=0x5425890298aed601595a70ab815c96711a31bc65
-export USDC_HOME_C_CHAIN=0x546526F786115af1FE7c11aa8Ac5682b8c181E3A
-```
-</Step>
-<Step>
-### Deploy Interchain Token Transfer Contracts
-Set up the remote transferer contracts for transferring tokens between the C-Chain and the newly created L1.
-   
-- `NativeTokenRemote` Contract on `myblockchain` 
-```bash 
-forge create --rpc-url myblockchain --private-key $PK lib/avalanche-interchain-token-transfer/contracts/src/TokenRemote/NativeTokenRemote.sol:NativeTokenRemote --constructor-args "($TELEPORTER_REGISTRY_L1, $FUNDED_ADDRESS, $C_CHAIN_BLOCKCHAIN_ID_HEX, $USDC_HOME_C_CHAIN, 6)" "USDC" 100000000000000000000 0
-```
-
-_Note: When deploying the `NativeTokenRemote` contract on the L1, ensure that the **initial amount** matches the native token amount that was minted when the blockchain was created. This ensures consistency between the native token supply and the remote token counterpart._
-
-```bash
-export NATIVE_TOKEN_REMOTE_L1="Deployed To Address"
-```
-</Step>
-<Step>
-### Granting Native Minting Rights to NativeTokenRemote Contract
-To ensure that the `NativeTokenRemote` contract can mint native tokens on the L1 when USDC tokens are transferred from the `C-Chain`, the contract must be granted **minting rights**. This is done by adding the `NativeTokenRemote contract` address to the `Native Minter Precompile`.
-
-1. You will need to interact with the `Native Minter Precompile`, which resides at a fixed address on all Avalanche L1s:  
-**Native Minter Precompile Address**: `0x0200000000000000000000000000000000000001`
-     
-2. Use the following command to grant the `NativeTokenRemote` contract minting rights by setting it as an **enabled** address on the Native Minter Precompile:
-  
-```bash
-cast send --rpc-url myblockchain --private-key $PK 0x0200000000000000000000000000000000000001 "setEnabled(address)" $NATIVE_TOKEN_REMOTE_L1
-```
-
-- `$NATIVE_TOKEN_REMOTE_L1`: The deployed address of the `NativeTokenRemote` contract on your L1.
-
-Once this step is completed, the `NativeTokenRemote` contract will have the necessary permissions to mint native tokens when USDC tokens are transferred from the C-Chain.
-</Step>
-<Step>
-### Register Remote Token with Home Transferer
-Register the remote token on the home chain so that it recognizes the transferer contracts.
-
-```bash 
-cast send --rpc-url myblockchain --private-key $PK $NATIVE_TOKEN_REMOTE_L1 "registerWithHome((address, uint256))" "(0x0000000000000000000000000000000000000000, 0)"
-```
-</Step>
-<Step>
-### Collateralize and Transfer Tokens
-Add collateral to the transferer contract on the home chain, and then send the USDC tokens across chains.
-
-<Accordions>
-<Accordion title="What is Collateral?">
-Collateral in this context refers to the amount of the token that is locked in the `Home Transferer contract` on the source chain (`C-Chain`) to back the value of the token on the destination chain (`myblockchain`). This ensures that for every token minted on the remote chain, there’s an equivalent token locked as collateral on the home chain.
-</Accordion>
-<Accordion title="Why is Collateral Important?">
-Collateralization ensures that the total supply of the token remains consistent across both chains. When tokens are sent from the `home chain`, they are locked as collateral, and a corresponding number of tokens is minted on the remote chain. If tokens are sent back to the home chain, the collateral is unlocked, and the minted tokens on the remote chain are burned.
-</Accordion>
-</Accordions>
-
-- **Approve Tokens for Transfer**  
-Approve a certain number of tokens to be used by the Home Transferer. 
-
-```bash  
-cast send --rpc-url local-c --private-key $PK $USDC "approve(address, uint256)" $USDC_HOME_C_CHAIN 2000000000000000000000
-```
-
-- **Add Collateral and Send Tokens**  
-Add collateral to the transferer contract.
-```bash 
-cast send --rpc-url local-c --private-key $PK $USDC_HOME_C_CHAIN "addCollateral(bytes32, address, uint256)" $L1_BLOCKCHAIN_ID_HEX $NATIVE_TOKEN_REMOTE_L1 100000000000000000000
-```
-You can also confirm whether the Transferer is collateralized now by running the below command:
-
-```bash
-cast call --rpc-url myblockchain $NATIVE_TOKEN_REMOTE_L1 "isCollateralized()(bool)"
-```
-Send tokens to the L1
-```bash 
-cast send --rpc-url local-c --private-key $PK $USDC_HOME_C_CHAIN "send((bytes32, address, address, address, uint256, uint256, uint256, address), uint256)" "(${L1_BLOCKCHAIN_ID_HEX}, ${NATIVE_TOKEN_REMOTE_L1}, ${FUNDED_ADDRESS}, ${USDC}, 0, 0, 250000, 0x0000000000000000000000000000000000000000)" 1000000000000000000000
-```
-</Step>
-
-<Step>
-Check Balance
-```bash
-cast balance --rpc-url myblockchain $FUNDED_ADDRESS
-```
-</Step>
-</Steps>
-
----
-
-### Conclusion
-
-Follow the steps above to transfer a USDC token from the C-Chain to your custom Avalanche L1 and use it as the native token. This exercise will demonstrate how Avalanche’s **Interchain Token Transfer (ICTT)** system works, ensuring that tokens are properly locked, transferred, and minted across multiple chains.
-
-For more detailed information, refer to the [official Avalanche ICTT documentation](/course/interchain-token-transfer).
diff --git a/content/course/interchain-token-transfer/certificate.mdx b/content/course/interchain-token-transfer/certificate.mdx
deleted file mode 100644
index 98ce13c1..00000000
--- a/content/course/interchain-token-transfer/certificate.mdx
+++ /dev/null
@@ -1,14 +0,0 @@
----
-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-token-transfer"/>
-
-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-token-transfer/index.mdx b/content/course/interchain-token-transfer/index.mdx
deleted file mode 100644
index dd407036..00000000
--- a/content/course/interchain-token-transfer/index.mdx
+++ /dev/null
@@ -1,84 +0,0 @@
----
-title: Welcome to the Course
-description: Learn about sending assets to another L1s with Avalanche Interchain Token Transfer.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Smile
----
-
-In this course, you will learn how to transfer assets across multiple Avalanche blockchains with Avalanche Interchain Token Transfer ICTT.
-
-## Why Take This Course?
-
-A significant innovation in blockchain is the development of multi-chain systems, like Avalanche, which provide a significant improvement in scalability, interoperability, and flexibility. At the core of these multi-chain systems is the ability to run multiple blockchains that communicate. Each chain's VM is optimized for specialized use cases, thereby boosting the network's overall performance.
-
-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
-
-In this section, you will learn how to set up your development environment with the Avalanche Starter Kit. Using this development environment you will be able to perform the exercises in this course.
-
-### Tokens
-
-In this section, you will learn about the different types of tokens that can be transferred between Avalanche blockchains. We will cover ERC-20 and native tokens and interact with them on chain. Furthermore, you will learn what wrapped native tokens are and how they can be used to transfer assets between chains.
-
-### Token Bridging
-
-Next we will talk about the high level concepts of token bridging and use a demo bridge.
-
-### Interchain Token Transfer
-
-In this chapter we will look at the design of Avalanche Interchain Token Transfer. You will learn about the file structure of the contracts and the concepts of the token home and token remote.
-
-### ERC-20 to ERC-20 bridge
-
-You will learn how to set up a bridge to bridge an ERC-20 token from one L1 blockchain to another.
-
-### Token on multiple chains
-
-Here you will learn about the concept of multi-hops and how tokens can be bridged between multiple remote chains.
-
-### Native to ERC-20 bridge
-
-In this chapter you will learn how to bridge a native token as an ERC-20 token to another chain.
-
-### Send and Call
-
-In this chapter you will learn how to call smart contracts with the tokens after sending them to another chain.
-
-### Cross-Chain Token Swaps
-
-In this chapter you will learn how to swap tokens on another chain.
-
-## Prerequisites
-
-### Avalanche
-
-This course is intended for people with knowledge about Cross-Chain communication protocols, and a solid understanding of the basic concepts of Avalanche. You should be familiar with these concepts:
-
-1. Avalanche Architecture: Be familiar with Avalanche blockchains.
-2. Interchain Messaging: Know how to communicate between two Avalanche blockchains with ICM. 
-
-If some of this is not clear, we strongly recommend taking the Avalanche Fundamentals, Multi-Chain Architecture, and Interchain Messaging courses first.
-
-### Software Development
-
-You will need a general understanding of Software Development. You won't have to write a lot of code, but you will have to be able to understand some. Therefore, we recommend:
-
-1. Solidity: Basic Knowledge, familiarity with types and interfaces. 
-2. Foundry: Familiarity with Foundry will help to deploy and interact with contracts. 
-
-## Learning Outcomes
-
-By the end of this course, you will:
-
-- Understand what Avalanche Interchain Token Transfer is and when to use it.
-- Understand the differents options on how you can transfer assets between multiple chains.
-- Apply the knowledge gained in the course by enabiling assets to be transfered between multiple Avalanche blockchains.
-
-We are still working on enabling some features, so in the future you will be able to evaluate your own understanding of the material through quizzes and claim a certificate for successful completion at the end.
-
diff --git a/content/course/interchain-token-transfer/meta.json b/content/course/interchain-token-transfer/meta.json
deleted file mode 100644
index 24e333bd..00000000
--- a/content/course/interchain-token-transfer/meta.json
+++ /dev/null
@@ -1,32 +0,0 @@
-{
-  "title": "interchain-token-transfer",
-  "root": true,
-  "pages": [
-    "---Interchain Token Transfer---",
-    "index",
-    "...01-intro",
-    "---Environment Setup---",
-    "...02-avalanche-starter-kit",
-    "---Tokens---",
-    "...03-tokens",
-    "---Token Bridging---",
-    "...04-token-bridging",
-    "---Interchain Token Transfer---",
-    "...05-avalanche-interchain-token-transfer",
-    "---ERC-20 to ERC-20 Token Bridge---",
-    "...06-erc-20-to-erc-20-bridge",
-    "---ERC-20 Multi-Hop Transfer---",
-    "...07-tokens-on-multiple-chains",
-    "---Native to ERC-20 Token Bridge---",
-    "...08-native-to-erc-20-bridge",
-    "---Send and Call---",
-    "...12-send-and-call",
-    "---Cross-Chain Token Swaps---",
-    "...13-cross-chain-token-swaps",
-    "---Scaling Token Decimals---",
-    "...14-scaling-decimals",
-    "---Conclusion---",
-    "certificate"
-  ]
-}
-
diff --git a/content/course/l1-tokenomics/01-basics/01-native-tokens.mdx b/content/course/l1-tokenomics/01-basics/01-native-tokens.mdx
deleted file mode 100644
index 6515454a..00000000
--- a/content/course/l1-tokenomics/01-basics/01-native-tokens.mdx
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title: Native Tokens
-description: Learn about native tokens and their role in blockchain ecosystems.
-updated: 2024-09-03
-authors: [0xstt]
-icon: Book
----
-
-A **native token** in a blockchain running the Ethereum Virtual Machine (EVM) refers to the primary digital currency or cryptocurrency native to that blockchain. Native tokens act as the foundation for value transfer and network operation within their respective ecosystems.
-
-- **Ethereum**: ETH
-- **Avalanche C-Chain**: AVAX
-- **Dexalot**: ALOT
-- many more...
-
----
-
-### The Role of Native Tokens
-
-Native tokens serve multiple key roles within EVM-based blockchain networks, such as:
-
-- **Value Transfer**: Native tokens act as the primary currency for peer-to-peer transactions within the network, enabling value exchange between participants.
-- **Gas Fees**: Native tokens are used as **gas** to pay for transaction fees, contract deployments, and other network operations. This ensures that resources are allocated efficiently within the network.
-- **Security**: In Proof-of-Stake (PoS) networks, native tokens are often used for staking to secure the network and validate transactions.
-- **Governance**: In some cases, native tokens grant holders governance rights, allowing them to participate in decision-making processes that shape the blockchain’s future.
-
----
-
-Native tokens are the backbone of blockchain ecosystems, serving multiple roles that maintain the network's stability, security, and functionality.
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/01-basics/02-erc-20-tokens.mdx b/content/course/l1-tokenomics/01-basics/02-erc-20-tokens.mdx
deleted file mode 100644
index a769db3d..00000000
--- a/content/course/l1-tokenomics/01-basics/02-erc-20-tokens.mdx
+++ /dev/null
@@ -1,98 +0,0 @@
----
-title: ERC-20 Tokens
-description: Learn about ERC-20 tokens and their role in blockchain ecosystems.
-updated: 2024-09-03
-authors: [0xstt]
-icon: Book
----
-
-While a blockchain has a single **native token**, the **ERC-20** token standard was developed to allow for the representation of a wide range of assets on EVM-compatible chains. 
-
-**ERC** stands for **Ethereum Request for Comment**, and **20** is the identifier for the specific proposal that defines the standard.
-
-ERC-20 tokens are **fungible**, meaning each token is identical to another and can be exchanged on a one-to-one basis. These tokens are created and managed through smart contracts that adhere to the ERC-20 standard, ensuring interoperability between different tokens and decentralized applications (DApps).
-
----
-
-### ERC-20 Token Architecture
-
-At the core of every ERC-20 token is a simple **mapping** of addresses to balances, representing the number of tokens an address holds.
-
-```solidity
-abstract contract ERC20 is Context, IERC20, IERC20Metadata, IERC20Errors {
-    
-  mapping(address account => uint256) private _balances;
-  
-  //...
-}
-```
-
-Addresses holding ERC-20 tokens can belong to either **Externally Owned Accounts (EOAs)** or **smart contracts**. Both types of accounts can store and transfer ERC-20 tokens, making ERC-20 tokens versatile in decentralized finance (DeFi) and decentralized applications.
-
----
-
-### Role of ERC-20 Tokens in Blockchain Ecosystems
-
-ERC-20 tokens play an essential role in enabling the creation of decentralized applications with various functionalities:
-
-- **Tokenized Assets**: ERC-20 tokens can represent anything from digital currencies to tokenized real-world assets.
-- **DeFi Protocols**: Many DeFi protocols use ERC-20 tokens for lending, staking, and liquidity pools.
-- **Token Sales**: ICOs (Initial Coin Offerings) and other fundraising models rely heavily on ERC-20 tokens.
-
----
-
-### The ERC-20 Interface
-
-All ERC-20 tokens follow a standard interface to ensure compatibility with decentralized applications (DApps). This allows tokens to be easily transferred, approved for spending, and managed by any DApp that follows the same rules.
-
-```solidity
-interface IERC20 {
-    function name() external view returns (string memory);
-
-    function symbol() external view returns (string memory);
-
-    function decimals() external view returns (uint8);
-
-    function totalSupply() external view returns (uint256);
-
-    function balanceOf(address _owner) external view returns (uint256 balance);
-
-    function transfer(address _to, uint256 _value) external returns (bool success);
-
-    function transferFrom(address _from, address _to, uint256 _value) external returns (bool success);
-
-    function approve(address _spender, uint256 _value) external returns (bool success);
-
-    function allowance(address _owner, address _spender) external view returns (uint256 remaining);
-}
-```
-
-You can review the full **ERC-20 standard** [here](https://eips.ethereum.org/EIPS/eip-20).
-
----
-
-### Transferring ERC-20 Tokens
-
-To transfer ERC-20 tokens between accounts, you use the `transfer()` function, where the sender specifies the recipient’s address and the amount to be transferred.
-
-For more complex interactions, such as allowing a smart contract to transfer tokens on behalf of someone else, the ERC-20 standard includes the `approve()` and `transferFrom()` functions. 
-
-
-<Accordions>
-<Accordion title="transfer()">
-Transfers tokens from the sender’s account to another account, decreasing the sender's balance and increasing the recipient’s.
-</Accordion>
-<Accordion title="approve()">
-This function allows the owner of a token balance to approve another account (the **spender**) to withdraw up to a specified amount of tokens. The spender can withdraw from the owner's balance multiple times, as long as the total amount doesn’t exceed the approved limit.
-</Accordion>
-<Accordion title="allowance()">
-The `allowance()` function returns the amount that a spender is still allowed to withdraw from an owner's balance.
-</Accordion>
-<Accordion title="transferFrom()">
-This function facilitates the transfer of tokens from one account to another on behalf of the account owner. It is typically used in scenarios where smart contracts need to execute token transfers according to the contract's logic.
-</Accordion>
-</Accordions>
-
----
-
-ERC-20 tokens revolutionized the blockchain space by enabling the tokenization of assets and simplifying the creation of decentralized applications. Their standardization ensures compatibility across platforms and DApps, making them an integral part of the broader crypto ecosystem.
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/01-basics/03-deploy-and-transfer-erc-20-tokens.mdx b/content/course/l1-tokenomics/01-basics/03-deploy-and-transfer-erc-20-tokens.mdx
deleted file mode 100644
index 5131ac6a..00000000
--- a/content/course/l1-tokenomics/01-basics/03-deploy-and-transfer-erc-20-tokens.mdx
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: Deploy and Transfer an ERC-20 Token
-description: Learn how to deploy an ERC-20 token and transfer it between accounts.
-updated: 2024-09-03
-authors: [0xstt]
-icon: Terminal
----
-
-In this section, you will follow a step-by-step guide to deploy an ERC-20 token on a blockchain network and transfer it between accounts. This will provide practical experience with token creation, deployment, and handling transactions.
-
-### Objectives:
-- Deploy an ERC-20 token smart contract.
-- Interact with your token by transferring it between different accounts.
-
-To learn how to deploy an ERC-20 token and interact with your token on a blockchain, follow [this guide](/course/interchain-token-transfer/03-tokens/08-transfer-an-erc-20-token) to explore the deployment process using the CLI on our Avalanche L1.
-
-<Quiz quizId="201"/>
diff --git a/content/course/l1-tokenomics/01-basics/04-wrapped-tokens.mdx b/content/course/l1-tokenomics/01-basics/04-wrapped-tokens.mdx
deleted file mode 100644
index de523184..00000000
--- a/content/course/l1-tokenomics/01-basics/04-wrapped-tokens.mdx
+++ /dev/null
@@ -1,56 +0,0 @@
----
-title: Wrapped Native Tokens
-description: Learn about wrapped tokens and their role in blockchain ecosystems.
-updated: 2024-09-03
-authors: [0xstt]
-icon: Book
----
-
-**Wrapped tokens** are blockchain assets that represent a native cryptocurrency (e.g., AVAX, ALOT, ETH) in a tokenized form, typically conforming to the **ERC-20 token standard**. Wrapping a native token allows it to be used in decentralized applications (dApps) and protocols that require ERC-20 tokens.
-
----
-
-### What Are Wrapped Tokens?
-
-Wrapped tokens are created through a process where the native cryptocurrency is locked in a smart contract, and an equivalent amount of the wrapped token is minted. These wrapped tokens are backed 1:1 by the underlying native asset, ensuring that the value of the wrapped token mirrors that of the original native cryptocurrency.
-
-This **ERC-20 compatibility** is crucial for enabling the native asset to interact with dApps, decentralized exchanges (DEXs), and smart contracts within the EVM ecosystem, where ERC-20 tokens are the standard.
-
----
-
-### Why Are Wrapped Tokens Important?
-
-Wrapped tokens play an essential role in **interoperability** within the EVM ecosystem, facilitating seamless use across decentralized applications and protocols. Some key benefits include:
-
-- **Liquidity**: Wrapped tokens increase liquidity in DeFi by enabling users to participate in protocols that require ERC-20 tokens, even when their original asset is a native token.
-- **Cross-Chain Compatibility**: Wrapped tokens allow assets from one blockchain (e.g., Bitcoin) to be used on another chain, enhancing cross-chain functionality.
-- **DeFi Integration**: Wrapped tokens are vital in DeFi protocols such as lending, borrowing, staking, and liquidity pools, where ERC-20 tokens are the standard.
-
----
-
-### Wrapped Token Contract Interface
-
-A **wrapped token contract** is typically an implementation of the ERC-20 token standard, with added functions for minting and burning tokens to facilitate the wrapping and unwrapping process. Here's a basic contract interface for a wrapped token:
-
-```solidity
-interface IWrappedToken {
-    function deposit() external payable;
-    function withdraw(uint256 amount) external;
-    
-    function totalSupply() external view returns (uint256);
-    function balanceOf(address account) external view returns (uint256);
-    function transfer(address recipient, uint256 amount) external returns (bool);
-    function allowance(address owner, address spender) external view returns (uint256);
-    function approve(address spender, uint256 amount) external returns (bool);
-    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
-}
-```
-
-<Accordions>
-<Accordion title="deposit()">
-This function is used to wrap native tokens. When a user calls deposit(), they send the native cryptocurrency (e.g., AVAX, ETH) to the contract, which then mints an equivalent amount of the wrapped token.
-</Accordion>
-<Accordion title="withdraw()">
-This function is used to unwrap the tokens. It burns the specified amount of wrapped tokens and returns the equivalent amount of native cryptocurrency to the user.
-</Accordion>
-</Accordions>
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/01-basics/05-deploy-and-interact-wrapped-tokens.mdx b/content/course/l1-tokenomics/01-basics/05-deploy-and-interact-wrapped-tokens.mdx
deleted file mode 100644
index 67815b79..00000000
--- a/content/course/l1-tokenomics/01-basics/05-deploy-and-interact-wrapped-tokens.mdx
+++ /dev/null
@@ -1,103 +0,0 @@
----
-title: Deploy and Interact with Wrapped Token
-description: Learn how to deploy and interact with wrapped tokens
-updated: 2024-09-03
-authors: [0xstt]
-icon: Terminal
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-In this section, we will deploy and interact with a wrapped token using **Forge** and **cast** commands. Forge simplifies smart contract deployment, and cast allows you to interact with deployed contracts.
-
----
-
-<Steps>
-<Step>
-
-#### 1. Write the Wrapped Token Contract
-Here is a basic implementation of a wrapped token contract in Solidity:
-
-```solidity
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.0;
-
-import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
-
-contract WrappedToken is ERC20 {
-    address public nativeTokenHolder;
-
-    constructor() ERC20("Wrapped Token", "WTKN") {}
-
-    function deposit() external payable {
-        _mint(msg.sender, msg.value);
-        nativeTokenHolder = msg.sender;
-    }
-
-    function withdraw(uint256 amount) external {
-        _burn(msg.sender, amount);
-        payable(msg.sender).transfer(amount);
-    }
-}
-```
-
-</Step>
-<Step>
-
-### Deploy ERC20 Receiver
-Deploy the Contract Using Forge's `create` Command
-
-```bash
-forge create --rpc-url myblockchain --private-key $PK WrappedToken.sol:WrappedToken
-```
-
-</Step>
-
-<Step>
-
-### Save the Wrapped Token Address
-
-Save the `Deployed to` address in an environment variable.
-
-```bash
-export WRAPPED_TOKEN=<address>
-```
-
-</Step>
-
-<Step>
-
-### Interacting with the Deployed Contract
-
-Once the contract is deployed, you can interact with it using **cast** commands.
-
-
-<Accordions>
-<Accordion title="Depositing Native Tokens (Wrapping)">
-
-To deposit native tokens and mint wrapped tokens, use the following `cast send` command:
-
-```bash
-cast send $WRAPPED_TOKEN "deposit()" --value <AMOUNT> --rpc-url myblockchain --private-key $PK
-```
-
-- `<AMOUNT>`: The amount of native tokens you want to wrap (in wei).
-</Accordion>
-<Accordion title="Withdrawing Native Tokens (Unwrapping)">
-
-To burn the wrapped tokens and retrieve the equivalent amount of native tokens:
-
-```bash
-cast send $WRAPPED_TOKEN "withdraw(uint256)" <AMOUNT> --rpc-url myblockchain --private-key $PK
-```
-
-- `<AMOUNT>`: The number of wrapped tokens to burn and convert back to native tokens.
-</Accordion>
-</Accordions>
-
-You can use the following page for [**wei conversions**](https://snowtrace.io/unitconverter).
-
-</Step>
-
-</Steps>
-
-<Quiz quizId="202"/>
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/01-basics/06-token-decimals.mdx b/content/course/l1-tokenomics/01-basics/06-token-decimals.mdx
deleted file mode 100644
index cd57da9b..00000000
--- a/content/course/l1-tokenomics/01-basics/06-token-decimals.mdx
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Token Decimals
-description: Learn about token decimals and their impact on blockchain applications.
-updated: 2024-09-03
-authors: [0xstt]
-icon: Book
----
-
-**Token decimals** refer to the level of precision used to define a token’s smallest unit. When a token contract is created, the number of decimals is specified to determine how divisible the token will be. This can have significant implications for user experience, application development, and overall token functionality.
-
-For example:
-- **6 decimals**: A token with 6 decimals means the smallest unit is 0.000001.
-- **18 decimals**: A token with 18 decimals means the smallest unit is 0.000000000000000001.
-
----
-
-### Why Are Token Decimals Important?
-
-Token decimals are critical because they determine how small a fraction of the token can be used in transactions. The choice of decimals directly affects how the token is used in various applications, including decentralized finance (DeFi), payments, and staking.
-
-- **Greater Precision**: More decimals allow for finer divisions of the token, which is useful in systems where very small amounts of a token need to be handled (e.g., high-frequency trading, micro-payments, or rewards distribution).
-- **User Perception**: The number of decimals can also influence how users perceive the value of the token. A token with fewer decimals might appear more “whole,” making it seem like larger amounts are being used in transactions.
-
----
-
-**Conclusion**: Token decimals are a fundamental aspect of token design. Choosing the right number of decimals depends on the token's use case, balancing the need for precision with user experience and technical requirements.
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/02-native-tokens/01-custom-native-tokens.mdx b/content/course/l1-tokenomics/02-native-tokens/01-custom-native-tokens.mdx
deleted file mode 100644
index d56e1f67..00000000
--- a/content/course/l1-tokenomics/02-native-tokens/01-custom-native-tokens.mdx
+++ /dev/null
@@ -1,42 +0,0 @@
----
-title: Custom Native Tokens
-description: Learn how custom native tokens can be used in the Avalanche network.
-updated: 2024-09-03
-authors: [0xstt]
-icon: Book
----
-
-In the Avalanche network, each Layer 1 (L1) blockchain has its own **native token**, which is used to pay for transaction fees (gas). This design isolates the gas fees on one blockchain from others in the ecosystem. For example, high transaction volume on the Avalanche C-Chain will not affect the transaction fees on a custom Avalanche L1 chain, giving developers greater flexibility in managing costs.
-
----
-
-### Custom Native Tokens: Unlocking Flexibility
-
-Custom native tokens allow developers to design and control transaction costs and economic models within their blockchain. By managing gas fees and tokenomics, they can create a tailored system that fits the specific needs of their blockchain application.
-
-- **Isolated Fees**: Custom native tokens ensure that each blockchain maintains its own fee structure, preventing external factors from impacting transaction costs.
-- **Tokenomics Control**: Developers can design custom economic models that support their application's needs, from low-fee environments to systems that incentivize specific user behaviors.
-
----
-
-### Creating a Seamless User Experience with Native Tokens
-
-Developers may want to provide a more streamlined, **cost-free experience** for users who are unfamiliar with the concept of paying for transactions. One approach to achieve this is to eliminate the burden of transaction fees for users by covering these costs through the native token itself. This can make interacting with blockchain applications feel more like traditional platforms, enhancing accessibility and ease of use.
-
-#### Simplifying Blockchain Interaction
-- **Transaction Fee Subsidization**: Developers can cover or significantly reduce transaction fees, ensuring that users can perform actions without directly incurring gas costs. This helps reduce friction for users and promotes engagement.
-- **Lowering Entry Barriers**: By minimizing the complexity of gas payments, developers can attract a wider audience, especially users not familiar with blockchain technology.
-
----
-
-### Stabilizing Native Token Value
-
-Some developers may want to ensure **price stability** for their native tokens, particularly if they need to maintain consistent transaction fees over time. Instead of issuing a token subject to market volatility, they can **peg the value of the native token to an existing stable asset**. This provides the dual benefits of isolated transaction fees with the predictability of stable pricing.
-
-#### Maintaining Fee Consistency
-- **Stable Value Tokens**: Tying the native token’s value to a stable asset (such as a stablecoin) ensures that transaction fees remain predictable, regardless of fluctuations in token supply or market demand.
-- **Predictable Costs**: This model allows developers to maintain consistent, low-cost transactions, helping to avoid disruptions caused by price volatility in the broader crypto market.
-
----
-
-**Conclusion**: Custom native tokens on the Avalanche network give developers the freedom to design blockchain economies that suit their project’s needs. Whether by managing gas fees for seamless user experiences or ensuring stable pricing through value-pegged tokens, custom tokens provide the flexibility required to build innovative and accessible blockchain applications.
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/02-native-tokens/02-configure-custom-native-token.mdx b/content/course/l1-tokenomics/02-native-tokens/02-configure-custom-native-token.mdx
deleted file mode 100644
index 7d4d8771..00000000
--- a/content/course/l1-tokenomics/02-native-tokens/02-configure-custom-native-token.mdx
+++ /dev/null
@@ -1,87 +0,0 @@
----
-title: Configure Custom Native Tokens
-description: Learn how to configure a custom native token in an Avalanche L1 blockchain.
-updated: 2024-09-04
-authors: [0xstt]
-icon: Terminal
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-When creating a custom Avalanche L1 blockchain, you can configure the native token according to your specific requirements. In this section, we'll explore the steps to configure a custom native token using the Subnet-EVM, allowing you to tailor it to your blockchain's needs.
-
-
-
-<Steps>
-<Step>
-### Creating the Blockchain
-Start by creating a new blockchain using the `avalanche` CLI tool:
-```bash
-avalanche blockchain create myblockchain
-```
-</Step>
-<Step>
-### Select VM
-You will be prompted to select the Subnet-EVM as the virtual machine for your blockchain:
-
-```bash
-? Which Virtual Machine would you like to use?: 
-  ▸ Subnet-EVM
-    Custom VM
-    Explain the difference
-```
-
-Select Subnet-EVM to proceed.
-</Step>
-<Step>
-### Customizing Blockchain Configuration
-After selecting Subnet-EVM, you’ll have the option to use default values or customize your blockchain settings:
-
-```bash
-? Do you want to use default values for the Blockchain configuration?: 
-    I want to use defaults for a test environment
-    I want to use defaults for a production environment
-  ▸ I don't want to use default values
-    Explain the difference
-```
-
-Select **I don’t want to use default values** to manually configure your blockchain.
-</Step>
-<Step>
-### Setting the Version, ChainID, and Token Symbol
-Next, you will be asked to choose the version of Subnet-EVM and configure the ChainID and token symbol:
-
-```bash
-✔ Subnet-EVM
-✔ I don't want to use default values
-? Version: 
-  ▸ Use latest release version
-    Specify custom version
-```
-
-Choose Use latest release version for the Subnet-EVM. After that, you will configure the following:
-
-```bash
-✔ Chain ID: 123456
-✔ Token Symbol: CNT
-```
-
-- **ChainID**: Choose a unique Chain ID that hasn’t been used on another blockchain. You can reference available Chain IDs by visiting [ChainList](https://chainlist.org/), which lists in-use Chain IDs.
-<Accordions>
-<Accordion title="Why Avoid Chain ID Replication?">
-When configuring your custom Avalanche blockchain, it’s crucial to select a unique Chain ID to avoid replication. Replicating a Chain ID that is already in use can lead to several problems, the most critical being replay attacks.
-
-**Replay Attacks**
-
-A replay attack occurs when a valid transaction on one blockchain can be maliciously replayed on another chain that shares the same Chain ID. For example, if two blockchains have the same Chain ID, a transaction on one chain could be copied and executed on the other, leading to unintended consequences, such as unauthorized token transfers.
-</Accordion>
-</Accordions>
-- **Token Symbol**: Set a token symbol for your custom native token (e.g., CNT). This symbol will represent your blockchain’s native token in transactions and applications.
-</Step>
-</Steps>
-
-
-
----
-
-What’s Next?
-After configuring the custom native token, the next step is to define the initial token allocation, where you’ll decide how the tokens will be distributed across validators, participants, and other stakeholders in your blockchain.
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/02-native-tokens/03-native-token-allocation.mdx b/content/course/l1-tokenomics/02-native-tokens/03-native-token-allocation.mdx
deleted file mode 100644
index ee5a6bd7..00000000
--- a/content/course/l1-tokenomics/02-native-tokens/03-native-token-allocation.mdx
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: Native Token Allocation
-description: Learn how to configure a custom native token in an Avalanche L1 blockchain.
-updated: 2024-09-04
-authors: [0xstt]
-icon: Book
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-After configuring your custom native token, the next step is to define how the token supply will be distributed. **Initial token allocation** is crucial as it determines the distribution of tokens among validators, developers, early participants, and other stakeholders in your blockchain ecosystem.
-
----
-
-### Why Initial Token Allocation Matters
-
-The way you allocate tokens at the start of your blockchain’s lifecycle sets the foundation for how your network will operate. Proper allocation ensures that incentives align with network security, participation, and governance. 
-
-- **Validators**: Allocating tokens to validators ensures that they have the necessary stake to secure the network and participate in consensus.
-- **Developers & Ecosystem**: Distributing tokens to developers and contributors incentivizes growth and innovation within your ecosystem.
-- **Early Participants**: Rewarding early participants helps build a strong, engaged community.
-
----
-
-### Structuring Initial Token Allocation
-
-When prompted, you’ll be given several options to structure the initial token allocation:
-
-```bash
-? How should the initial token allocation be structured?: 
-  ▸ Allocate 1m tokens to a new account
-    Allocate 1m to the ewoq account 0x8db...2FC (Only recommended for testing, not recommended for production)
-    Define a custom allocation (Recommended for production)
-```
-
----
-
-### Minting New Native Tokens
-
-You will also be asked whether you want to allow minting of new tokens beyond the initial supply:
-
-```bash
-? Allow minting of new native tokens?: 
-  ▸ No, I want the supply of the native tokens to be hard-capped
-    Yes, I want to be able to mint additional native tokens (Native Minter Precompile ON)
-```
-
-- **Hard-capped Supply**: Selecting `No` creates a finite supply of tokens, which cannot be increased. This is similar to the design of assets like Bitcoin, where the total supply is fixed.
-- **Mintable Tokens**: Selecting `Yes` enables the Native Minter Precompile, allowing the minting of new native tokens over time. This option gives you flexibility to issue more tokens as needed. We will discuss the Native Minter Precompile in detail in upcoming chapters.
-
----
-
-What’s Next? If you enabled minting, explore how to configure and interact with the **Native Minter Precompile** to mint new tokens and manage supply over time.
-
-<Quiz quizId="203"/>
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/02-native-tokens/04-activating-native-minter-precompile.mdx b/content/course/l1-tokenomics/02-native-tokens/04-activating-native-minter-precompile.mdx
deleted file mode 100644
index 9a2bf811..00000000
--- a/content/course/l1-tokenomics/02-native-tokens/04-activating-native-minter-precompile.mdx
+++ /dev/null
@@ -1,121 +0,0 @@
----
-title: Activating Native Minter Precompile
-description: Learn how to activate the native minter precompile.
-updated: 2024-09-04
-authors: [0xstt]
-icon: Terminal
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-The **Native Minter Precompile** allows you to mint additional native tokens beyond the initial supply on your Avalanche L1 blockchain. By enabling this feature, you can define who has permission to mint new tokens and how minting is managed over time. This section walks you through activating the Native Minter Precompile and configuring the necessary **allow list**.
-
----
-
-### What is the AllowList?
-
-The **AllowList** is a security feature used by precompiles to manage which addresses have permission to interact with certain contract functionalities. In the case of the **Native Minter Precompile**, the allow list is used to control who can mint new native tokens.
-
-The AllowList consists of three roles:
-- **Admin**: Full control over the allow list, including the ability to add or remove Admins, Managers, and Enabled addresses.
-- **Manager**: Can add or remove **Enabled** addresses but cannot modify Admins or Managers.
-- **Enabled**: These addresses can use the precompiled contract (e.g., mint native tokens) but cannot modify the allow list.
-
-The allow list provides a granular way to assign permissions, ensuring that only authorized addresses can mint native tokens or manage the minting process.
-
-<Accordions>
-<Accordion title="Allow List Interface">
-The AllowList Interface manages which addresses have permissions to interact with the precompiled contract. Here is the Solidity interface used for the allow list:
-
-```solidity
-//SPDX-License-Identifier: MIT
-pragma solidity ^0.8.24;
-
-interface IAllowList {
-  event RoleSet(uint256 indexed role, address indexed account, address indexed sender, uint256 oldRole);
-
-  function setAdmin(address addr) external;
-  function setEnabled(address addr) external;
-  function setManager(address addr) external;
-  function setNone(address addr) external;
-  function readAllowList(address addr) external view returns (uint256 role);
-}
-```
-
-This interface provides the ability to:
-
-- **Set Admin, Manager, and Enabled roles** for specific addresses.
-- **Read the role** of an address to check its permissions.
-- **Remove roles** from addresses when needed.
-
-</Accordion>
-</Accordions>
-
----
-
-<Steps>
-<Step>
-### Activating the Native Minter Precompile
-
-During the configuration process, you’ll be prompted to choose whether you want the native token supply to be hard-capped or if you want the ability to mint new tokens:
-
-```bash
-? Allow minting of new native tokens?: 
-  ▸ Yes, I want to be able to mint additional native tokens (Native Minter Precompile ON)
-    No, I want the supply of the native tokens to be hard-capped
-```
-
-Select **Yes, I want to be able to mint additional native tokens** to enable the Native Minter Precompile. This will allow your blockchain to mint new tokens as needed.
-</Step>
-<Step>
-### Configuring the Allow List
-
-After enabling minting, you will need to configure the **allow list**, which determines who has permission to mint tokens and manage the precompile contract. Initially, the allow list will be empty, so you will need to manually add addresses for each role.
-
-```bash
-? Configure the addresses that are allowed to mint native tokens: 
-  ▸ Add an address for a role to the allow list
-    Preview Allow List
-    Confirm Allow List
-    Cancel
-```
-</Step>
-<Step>
-### Adding Addresses to the Allow List
-
-To add addresses to the allow list, choose **Add an address for a role to the allow list** and assign a role to each address:
-
-```bash
-? What role should the address have?: 
-  ▸ Admin
-    Manager
-    Enabled
-```
-</Step>
-<Step>
-### Example Allow List Setup
-
-After adding an address for each role, you can preview the current allow list:
-
-```bash
-✔ Preview Allow List
-+---------+--------------------------------------------+
-| Admins  | 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC |
-+---------+--------------------------------------------+
-| Manager |                                            |
-+---------+--------------------------------------------+
-| Enabled |                                            |
-+---------+--------------------------------------------+
-```
-
-After verifying the allow list, confirm the configuration:
-
-```bash
-? Configure the addresses that are allowed to mint native tokens: 
-  ▸ Confirm Allow List
-    Add an address for a role to the allow list
-    Remove an address from the allow list
-    Preview Allow List
-    Cancel
-```
-</Step>
-</Steps>
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/02-native-tokens/05-native-minter-precompile.mdx b/content/course/l1-tokenomics/02-native-tokens/05-native-minter-precompile.mdx
deleted file mode 100644
index cc966d7b..00000000
--- a/content/course/l1-tokenomics/02-native-tokens/05-native-minter-precompile.mdx
+++ /dev/null
@@ -1,33 +0,0 @@
----
-title: Native Minter Precompile
-description: Learn how to enable minting of new native tokens and configure the allow list in an Avalanche L1 blockchain.
-updated: 2024-09-04
-authors: [0xstt]
-icon: Book
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-### Minting Native Tokens
-
-Once the allow list is configured, addresses with the Enabled role can mint new native tokens using the following interface:
-
-```solidity
-//SPDX-License-Identifier: MIT
-pragma solidity ^0.8.24;
-
-interface INativeMinter {
-  event NativeCoinMinted(address indexed sender, address indexed recipient, uint256 amount);
-
-  function mintNativeCoin(address addr, uint256 amount) external;
-}
-```
-
-<Accordions>
-<Accordion title="mintNativeCoin()">
-This function mints a specified amount of native tokens and sends them to the designated address. Only addresses with the Enabled role can call this function.
-</Accordion>
-</Accordions>
-
-**Conclusion**: By enabling the Native Minter Precompile and setting up an allow list with proper roles, you can effectively manage who has permission to mint new native tokens and adjust the token supply as needed. By doing so at the **smart contract level**, Avalanche provides flexibility and security, allowing developers to control minting directly within their blockchain applications.
-
-<Quiz quizId="204"/>
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/02-native-tokens/06-use-erc20-as-native-token.mdx b/content/course/l1-tokenomics/02-native-tokens/06-use-erc20-as-native-token.mdx
deleted file mode 100644
index e86a9fbc..00000000
--- a/content/course/l1-tokenomics/02-native-tokens/06-use-erc20-as-native-token.mdx
+++ /dev/null
@@ -1,41 +0,0 @@
----
-title: Use ERC-20 as Native Token
-description: Learn how an ERC-20 token can be used as a native token in a custom Avalanche L1 blockchain.
-updated: 2024-09-03
-authors: [0xstt]
-icon: Book
----
-
-In a custom Avalanche L1 blockchain, you can opt to use an **ERC-20 token** as the native token. Typically, ERC-20 tokens serve as fungible assets within decentralized applications (dApps), but in this setup, the ERC-20 token is transferred to the new L1 via the **Interchain Token Transfer (ICTT)** mechanism. Once transferred, the ERC-20 token no longer behaves as a standard ERC-20 token but is instead **converted into the native token** of the new L1 blockchain.
-
----
-
-### Features Unlocked by Using ERC-20 as Native Token
-
-By using an ERC-20 token as the native token on a new Avalanche L1 blockchain, several unique features and benefits become available:
-
-- **Leverage Existing Ecosystem Liquidity**
-
-Bringing an ERC-20 token into the new L1 as a native token allows you to tap into the existing liquidity and user base of that ERC-20 token. For example, a stablecoin like USDC, transferred as an ERC-20 token, can be used as the native token to provide price stability while facilitating cross-chain transactions.
-
-- **Interoperability with Existing dApps**
-
-An ERC-20 token as a native token allows the new L1 to **interoperate with existing decentralized applications** (dApps) and DeFi protocols that are built around that token. This can increase user adoption by maintaining familiar token functionality across different chains.
-
-- **Cross-Chain Compatibility**
-
-Transferring an ERC-20 token via ICTT unlocks **cross-chain compatibility**, meaning that assets and value from one blockchain ecosystem can seamlessly move and function on another blockchain. This helps promote greater liquidity across blockchains and removes barriers to token usage.
-
-- **Gas Fee Flexibility**
-
-Using an ERC-20 token as a native token offers flexibility in how gas fees are handled. Rather than relying on a brand-new native token, you can use the transferred ERC-20 token to **pay for gas fees**, making it easier for users already familiar with that token to interact with the new chain.
-
-- **Governance and Staking**
-
-Once an ERC-20 token becomes the native token on the new L1, it can be used for staking and **governance functions**, such as voting on proposals or participating in consensus mechanisms. This expands the token's utility beyond simple transactions, enabling it to play a critical role in securing and managing the new L1.
-
----
-
-### Next Steps
-
-In the next section, **Multi-chain Ecosystems**, we’ll explore how the transfer of assets between different chains works and how using tokens like ERC-20 as native tokens enhances cross-chain liquidity and interoperability. We’ll also look into the technical challenges and solutions involved in building robust, multi-chain ecosystems that support the seamless movement of assets like these.
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/03-multi-chain-ecosystems/01-introduction.mdx b/content/course/l1-tokenomics/03-multi-chain-ecosystems/01-introduction.mdx
deleted file mode 100644
index 9000a560..00000000
--- a/content/course/l1-tokenomics/03-multi-chain-ecosystems/01-introduction.mdx
+++ /dev/null
@@ -1,71 +0,0 @@
----
-title: Introduction
-description: Learn how multi-chain ecosystems influence tokenomics and unlock new possibilities for token utility and interoperability.
-updated: 2024-09-03
-authors: [0xstt]
-icon: Book
----
-
-A **multi-chain ecosystem** refers to the integration of multiple blockchain networks that operate together to enable the seamless transfer of assets, data, and functionality across chains. As blockchain adoption grows, multi-chain ecosystems are becoming a crucial part of tokenomics, unlocking new opportunities for how tokens are used, transferred, and governed across different blockchain environments.
-
----
-
-### Impact on Tokens and Tokenomics
-
-In a single-chain environment, tokens are confined to the limitations of their original network, restricting their usability and liquidity. However, in a **multi-chain ecosystem**, tokens can move freely between blockchains, enhancing their utility and making them more adaptable to various use cases. This has profound implications for **tokenomics**:
-
-- **Expanded Token Utility**
-
-In a multi-chain ecosystem, tokens are not limited to their native chain. They can be used across various platforms and blockchains, unlocking new use cases. For example, a token can be used for governance on one chain and staking or liquidity provision on another, maximizing its functionality.
-
-- **Increased Liquidity**
-
-The ability to transfer tokens between chains increases liquidity by allowing assets to flow freely across decentralized exchanges (DEXs) and lending platforms on multiple chains.
-
-- **Enhanced Security and Governance**
-
-Multi-chain ecosystems can offer more robust security mechanisms by distributing consensus and governance across several chains. This makes networks less vulnerable to attacks and enables cross-chain governance models, where token holders from multiple chains can vote on protocol upgrades or community decisions.
-
-- **Tokenomics Flexibility**
-
-Tokenomics models can be more flexible and adaptive in multi-chain ecosystems. For instance, the same token might have different roles on different chains, such as paying for gas fees on one chain while being used for collateral in DeFi protocols on another. This adaptability makes it easier to create sustainable and efficient token economies.
-
----
-
-### Challenges of Multi-Chain Ecosystems
-
-While multi-chain ecosystems unlock significant benefits, they also come with **challenges** that developers and projects must address:
-
-- **Fragmented Liquidity**
-
-One of the key challenges in multi-chain ecosystems is **liquidity fragmentation**. When tokens are spread across multiple chains, liquidity can become diluted, making it harder to pool sufficient liquidity on any single platform. This can reduce efficiency for decentralized finance (DeFi) platforms, increasing slippage and reducing market depth.
-
-- **Complexity of Cross-Chain Communication**
-
-Managing assets across multiple chains requires complex **cross-chain communication** protocols.
-
-- **Security Risks**
-
-While multi-chain ecosystems offer greater flexibility, they also introduce potential **security risks**, such as the vulnerability of bridges. If a bridge or cross-chain protocol is compromised, tokens or assets on the receiving chain can be at risk.
-
-- **Difficulty in Managing Governance**
-
-Cross-chain governance can be difficult to coordinate, especially when token holders are spread across multiple chains with different governance models. Aligning voting mechanisms and decision-making processes can create friction and delays.
-
----
-
-### How Avalanche Helps Power Multi-Chain Ecosystems
-
-Avalanche plays a critical role in the development and support of multi-chain ecosystems. As a platform built with scalability, interoperability, and customizability in mind, Avalanche enables the seamless transfer of tokens and data across its L1s and beyond. Some of the key features that make Avalanche ideal for multi-chain ecosystems include:
-
-- **Interchain Token Transfer (ICTT)**: 
-
-ICTT enables the **seamless movement of assets** between Avalanche L1s and other blockchain networks. This ensures that tokens can move freely between chains without compromising security or usability.
-  
-- **Cross-Chain Messaging**: 
-
-Avalanche’s cross-chain communication protocols enable the exchange of messages and transactions between chains, ensuring smooth interaction and data sharing between networks.
-
----
-
-What's next? In the following sections, we will explore the technical aspects of **interchain token transfers** and how Avalanche’s architecture supports the movement of assets and tokens across various chains. You’ll also learn how to leverage Avalanche’s tools to build multi-chain applications and unlock the full potential of your tokenomics.
diff --git a/content/course/l1-tokenomics/03-multi-chain-ecosystems/02-interchain-token-transfers.mdx b/content/course/l1-tokenomics/03-multi-chain-ecosystems/02-interchain-token-transfers.mdx
deleted file mode 100644
index 27ce3fc0..00000000
--- a/content/course/l1-tokenomics/03-multi-chain-ecosystems/02-interchain-token-transfers.mdx
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title: Interchain Token Transfers
-description: Learn how to transfer assets across Avalanche L1 blockchains using Interchain Token Transfers.
-updated: 2024-09-03
-authors: [0xstt]
-icon: Book
----
-
-**Interchain Token Transfers (ICTT)** allow assets, such as ERC-20 or native tokens, to move seamlessly between different Avalanche L1 blockchains. The system consists of a **TokenHome** contract, which lives on the source blockchain, and **TokenRemote** contracts, which reside on other Avalanche L1s that want to receive the asset.
-
----
-![](/course-images/ictt/ictt.png)
-
----
-### Overview of How It Works
-
-- **Home and Remote Contracts**:
-
-The `TokenHome` contract manages the transfer of assets from the source Avalanche L1 blockchain. It locks the original asset as collateral and tracks token balances sent to `TokenRemote` contracts on other L1s.
-
-The `TokenRemote` contracts, on the receiving chains, mint a representation of the original token, allowing users to interact with it as if it were the native token of that chain.
-
-- **Transfer Process**:
-
-When a user transfers an asset from the `source chain` to a `remote chain`, the asset is **locked** on the `home chain`, and a corresponding representation of the token is **minted** on the `remote chain`.
-
-This setup allows for different configurations, where the token can be represented as either an **ERC-20 token** or a **native token** on both the home and remote chains, giving flexibility to developers.
-
-- **Cross-Chain Flexibility**:
-
-Assets can be transferred in multiple configurations:
-- `ERC-20` -> `ERC-20`
-- `ERC-20` -> `Native`
-- `Native` -> `ERC-20`
-- `Native` -> `Native`
-
-This flexibility allows developers to choose how assets are represented and used across multiple Avalanche L1s.
-
-Configurations of the `TokenHome` and `TokenRemote` contracts can be found [here](https://github.com/ava-labs/avalanche-interchain-token-transfer/tree/main/contracts/src)
-
-- **Permissionless Registration**:
-
-ICTT is designed to be permissionless. Anyone can register a compatible `TokenRemote` instance to a `TokenHome` contract, expanding the network of chains that can receive transferred tokens.
-
-- **Customizable Logic**:
-
-Developers can extend the default `ERC20TokenRemote` contract to implement custom minting, burning, or transfer logic, giving them flexibility to add functionality specific to their use cases.
-
----
-
-### Learn More
-
-For more detailed information on setting up and managing Interchain Token Transfers, please refer to the [related guide](/course/interchain-token-transfer) on how to configure these contracts and customize their behavior for your multi-chain applications.
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/03-multi-chain-ecosystems/03-use-erc20-as-native-token.mdx b/content/course/l1-tokenomics/03-multi-chain-ecosystems/03-use-erc20-as-native-token.mdx
deleted file mode 100644
index b8be738e..00000000
--- a/content/course/l1-tokenomics/03-multi-chain-ecosystems/03-use-erc20-as-native-token.mdx
+++ /dev/null
@@ -1,146 +0,0 @@
----
-title: Use ERC-20 as Native Token (DIY)
-description: Learn how to transfer an ERC-20 token to a new Avalanche L1 and use it as a native token via ICTT.
-updated: 2024-09-03
-authors: [0xstt]
-icon: Terminal
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-In this section, you will learn how to transfer an ERC-20 token from Avalanche’s C-Chain to a new Avalanche L1 using Interchain Token Transfers (ICTT) and set it up to act as the **native token** on the new L1. This guide will take you through the steps of configuring a local network environment, deploying the necessary contracts, and transferring tokens.
-
-
-<Steps>
-<Step>
-### Create a new blockchain and Deploy on Local Network
-
-Use the **Avalanche CLI** to create a new blockchain where you will deploy the ERC-20 as the native token.
-
-
-```bash
-avalanche blockchain create myblockchain  
-```
-For this exercise, create a Proof of Authority blockchain that has Native Minter Precompile activated. This precompile is not activated NOT with the default test values, so make sure to go through the manual configuration of your L1 with the Avalanche-CLI. Add the deployer address as the `admin`for this, for convinience we will use the ewoq key that is already loaded as part of the Starter-Kit environment variables and which public key is 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC. Go with the default values for all other steps in the configuration process.
-_Note: Having the Native Minter Precompile active and the correct admin rights assigned to the deployer is crucial for the rest of this lesson._
-
-```bash
-avalanche blockchain deploy myblockchain
-```
-Add all the environment variables. You can retrieve all your L1 detailes with `avalanche blockchain describe myblockchain` and `avalanche primary describe` for C-chain details.
-```bash
-export TELEPORTER_REGISTRY_C_CHAIN=0x...
-export FUNDED_ADDRESS=0x...
-export TELEPORTER_REGISTRY_L1=0x...
-export L1_BLOCKCHAIN_ID_HEX=0x...
-export C_CHAIN_BLOCKCHAIN_ID_HEX=0x...
-```
-
-</Step>
-<Step>
-### Deploy an ERC-20 Contract on C-Chain
-
-Use the **Avalanche CLI** to create a new blockchain where you will deploy the ERC-20 as the native token.
-
-You will deploy an ERC-20 token on the Avalanche C-Chain, which will later be transferred and used as the native token on the new L1.
-
-```bash
-forge create --rpc-url local-c --private-key $PK lib/avalanche-interchain-token-transfer/contracts/src/mocks/ExampleERC20Decimals.sol:ExampleERC20Decimals --constructor-args 18
-```
-
-Save the newly created ERC20 address to the environment variables
-
-```bash
-export $ERC20_HOME_C_CHAIN=0x...
-```
-
-</Step>
-<Step>
-### Deploy Interchain Token Transfer Contracts
-Set up the home and remote transferer contracts for transferring tokens between the C-Chain and the newly created L1.
-
-- `ERC20TokenHome` Contract on C-Chain  
-```bash
-forge create --rpc-url local-c --private-key $PK lib/avalanche-interchain-token-transfer/contracts/src/TokenHome/ERC20TokenHome.sol:ERC20TokenHome --constructor-args $TELEPORTER_REGISTRY_C_CHAIN $FUNDED_ADDRESS $ERC20_HOME_C_CHAIN 18
-```
-
-Export to environment variables:
-
-```bash
-export ERC20_HOME_TRANSFERER_C_CHAIN=0x...
-``` 
-
-- `NativeTokenRemote` Contract on `myblockchain` 
-```bash 
-forge create --rpc-url myblockchain --private-key $PK lib/avalanche-interchain-token-transfer/contracts/src/TokenRemote/NativeTokenRemote.sol:NativeTokenRemote --constructor-args "($TELEPORTER_REGISTRY_L1, $FUNDED_ADDRESS, $C_CHAIN_BLOCKCHAIN_ID_HEX, $ERC20_HOME_TRANSFERER_C_CHAIN, 18)" "EXMP.b" 100000000000000000000 0 false 0
-```
-
-Add to the enviroment variables 
-
-```bash
-export NATIVE_TOKEN_REMOTE_L1=0x...
-```
-
-_Note: When deploying the `NativeTokenRemote` contract on the L1, ensure that the **initial amount** matches the native token amount that was minted when the blockchain was created. This ensures consistency between the native token supply and the remote token counterpart._
-
-</Step>
-<Step>
-### Granting Native Minting Rights to NativeTokenRemote Contract
-To ensure that the `NativeTokenRemote` contract can mint native tokens on the L1 when ERC-20 tokens are transferred from the `C-Chain`, the contract must be granted **minting rights**. This is done by adding the `NativeTokenRemote contract` address to the `Native Minter Precompile`.
-
-1. You will need to interact with the `Native Minter Precompile`, which resides at a fixed address on all Avalanche L1s:  
-**Native Minter Precompile Address**: `0x0200000000000000000000000000000000000001`
-     
-2. Use the following command to grant the `NativeTokenRemote` contract minting rights by setting it as an **enabled** address on the Native Minter Precompile:
-  
-```bash
-cast send --rpc-url myblockchain --private-key $PK 0x0200000000000000000000000000000000000001 "setEnabled(address)" $NATIVE_TOKEN_REMOTE_L1
-```
-Once this step is completed, the `NativeTokenRemote` contract will have the necessary permissions to mint native tokens when ERC-20 tokens are transferred from the C-Chain.
-</Step>
-<Step>
-### Register Remote Token with Home Transferer
-Register the remote token on the home chain so that it recognizes the transferer contracts.
-
-```bash 
-cast send --rpc-url myblockchain --private-key $PK $NATIVE_TOKEN_REMOTE_L1 "registerWithHome((address, uint256))" "(0x0000000000000000000000000000000000000000, 0)"
-```
-</Step>
-<Step>
-### Collateralize and Transfer Tokens
-Add collateral to the transferer contract on the home chain, and then send the ERC-20 tokens across chains.
-
-<Accordions>
-<Accordion title="What is Collateral?">
-Collateral in this context refers to the amount of the token that is locked in the `Home Transferer contract` on the source chain (`C-Chain`) to back the value of the token on the destination chain (`myblockchain`). This ensures that for every token minted on the remote chain, there’s an equivalent token locked as collateral on the home chain.
-</Accordion>
-<Accordion title="Why is Collateral Important?">
-Collateralization ensures that the total supply of the token remains consistent across both chains. When tokens are sent from the `home chain`, they are locked as collateral, and a corresponding number of tokens is minted on the remote chain. If tokens are sent back to the home chain, the collateral is unlocked, and the minted tokens on the remote chain are burned.
-</Accordion>
-</Accordions>
-
-- **Approve Tokens for Transfer**  
-Approve a certain number of tokens to be used by the Home Transferer. 
-
-```bash  
-cast send --rpc-url local-c --private-key $PK $ERC20_HOME_C_CHAIN "approve(address, uint256)" $ERC20_HOME_TRANSFERER_C_CHAIN 2000000000000000000000
-```
-
-- **Add Collateral and Send Tokens**  
-Add collateral to the transferer contract.
-```bash 
-cast send --rpc-url local-c --private-key $PK $ERC20_HOME_TRANSFERER_C_CHAIN "addCollateral(bytes32, address, uint256)" $L1_BLOCKCHAIN_ID_HEX $NATIVE_TOKEN_REMOTE_L1 100000000000000000000
-```
-Send tokens to the L1
-```bash 
-cast send --rpc-url local-c --private-key $PK $ERC20_HOME_TRANSFERER_C_CHAIN "send((bytes32, address, address, address, uint256, uint256, uint256, address), uint256)" "(${L1_BLOCKCHAIN_ID_HEX}, ${NATIVE_TOKEN_REMOTE_L1}, ${FUNDED_ADDRESS}, ${ERC20_HOME_C_CHAIN}, 0, 0, 250000, 0x0000000000000000000000000000000000000000)" 1000000000000000000000
-```
-</Step>
-</Steps>
-
----
-
-### Conclusion
-
-Follow the steps above to transfer an ERC-20 token from the C-Chain to your custom Avalanche L1 and use it as the native token. This exercise will demonstrate how Avalanche’s **Interchain Token Transfer (ICTT)** system works, ensuring that tokens are properly locked, transferred, and minted across multiple chains.
-
-For more detailed information, refer to the [official Avalanche ICTT documentation](/course/interchain-token-transfer).
diff --git a/content/course/l1-tokenomics/03-multi-chain-ecosystems/04-use-any-native-as-native-token.mdx b/content/course/l1-tokenomics/03-multi-chain-ecosystems/04-use-any-native-as-native-token.mdx
deleted file mode 100644
index 30c0bfaf..00000000
--- a/content/course/l1-tokenomics/03-multi-chain-ecosystems/04-use-any-native-as-native-token.mdx
+++ /dev/null
@@ -1,148 +0,0 @@
----
-title: Use any Native as Native Token (DIY)
-description: Learn how to transfer a native token to a new Avalanche L1 and use it as the native token via ICTT.
-updated: 2024-09-03
-authors: [0xstt]
-icon: Terminal
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-In this section, you will learn how to transfer a native token from Avalanche’s C-Chain to a new Avalanche L1 using Interchain Token Transfers (ICTT) and set it up to act as the **native token** on the new L1. This guide will walk you through each step, from creating a L1 to transferring and using the native token.
-
-<Steps>
-<Step>
-### Create a new blockchain and Deploy on Local Network
-
-Use the `avalanche` CLI to create a new blockchain where you will deploy the ERC-20 as the native token.
-
-
-```bash
-avalanche blockchain create myblockchain  
-```
-```bash
-avalanche blockchain deploy myblockchain
-```
-
-Take note of the important addresses (e.g., `Teleporter Registry`, `Funded Address`) from the deployment output as they will be needed in the following steps.
-</Step>
-<Step>
-### Wrap the Native Token on C-Chain
-
-You'll need to deploy a wrapped token contract for your native token on the C-Chain. The wrapped token will serve as the transferable asset between the chains.
-
-```bash
-forge create --rpc-url local-c --private-key $PK lib/avalanche-interchain-token-transfer/contracts/src/WrappedNativeToken.sol:WrappedNativeToken
-```
-
-After deployment, save the `Deployed to` address in an environment variable for future use.
-
-```bash
-export WRAPPED_NATIVE_C_CHAIN=<address>
-```
-</Step>
-<Step>
-### Deploy Interchain Token Transfer Contracts
-
-Now, deploy the Interchain Token Transfer contracts on both the `C-Chain` and the `myblockchain` to enable cross-chain token transfers.
-
-- `NativeTokenHome` Contract on C-Chain  
-
-```bash
-forge create --rpc-url local-c --private-key $PK lib/avalanche-interchain-token-transfer/contracts/src/TokenHome/NativeTokenHome.sol:NativeTokenHome --constructor-args $TELEPORTER_REGISTRY_C_CHAIN $FUNDED_ADDRESS $WRAPPED_NATIVE_C_CHAIN
-```
-
-- `NativeTokenRemote` Contract on `myblockchain`
-
-```bash
-forge create --rpc-url myblockchain --private-key $PK lib/avalanche-interchain-token-transfer/contracts/src/TokenRemote/NativeTokenRemote.sol:NativeTokenRemote --constructor-args "(${TELEPORTER_REGISTRY_L1}, ${FUNDED_ADDRESS}, ${C_CHAIN_BLOCKCHAIN_ID_HEX}, ${NATIVE_HOME_TRANSFERER_C_CHAIN})" "NATV" 700000000000000000000 0 false 0
-```
-
-_Note: Ensure that the initial amount matches the native token amount minted on the C-Chain during the wrapped token deployment._
-
-Export the deployed addresses as environment variables:
-
-```
-export NATIVE_HOME_TRANSFERER_C_CHAIN=<"Deployed to" address>
-export NATIVE_TOKEN_REMOTE_L1=<"Deployed to" address>
-```
-</Step>
-<Step>
-### Grant Native Minting Rights to NativeTokenRemote
-
-To ensure that the `NativeTokenRemote` contract can mint native tokens on the L1 when ERC-20 tokens are transferred from the `C-Chain`, the contract must be granted **minting rights**. This is done by adding the `NativeTokenRemote` contract address to the `Native Minter Precompile`.
-
-1. You will need to interact with the `Native Minter Precompile`, which resides at a fixed address on all Avalanche L1s:  
-**Native Minter Precompile Address**: `0x0200000000000000000000000000000000000001`
-     
-2. Use the following command to grant the `NativeTokenRemote` contract minting rights by setting it as an **enabled** address on the Native Minter Precompile:
-  
-```bash
-cast send --rpc-url myblockchain --private-key $PK 0x0200000000000000000000000000000000000001 "setEnabled(address)" $NATIVE_TOKEN_REMOTE_L1
-```
-
-- `$NATIVE_TOKEN_REMOTE_L1`: The deployed address of the `NativeTokenRemote` contract on your L1.
-
-Once this step is completed, the `NativeTokenRemote` contract will have the necessary permissions to mint native tokens when ERC-20 tokens are transferred from the C-Chain.
-</Step>
-<Step>
-### Register Remote Token with Home Transferer
-Register the remote token on the home chain so that it recognizes the transferer contracts.
-
-```bash 
-cast send --rpc-url myblockchain --private-key $PK $NATIVE_TOKEN_REMOTE_L1 "registerWithHome((address, uint256))" "(0x0000000000000000000000000000000000000000, 0)"
-```
-</Step>
-<Step>
-### Collateralize and Transfer Tokens
-Collateralize the home contract by locking native tokens. The amount of collateral should match the initial token reserve set on the `myblockchain`.
-
-<Accordions>
-<Accordion title="What is Collateral?">
-Collateral in this context refers to the amount of the token that is locked in the `Home Transferer contract` on the source chain (`C-Chain`) to back the value of the token on the destination chain (`myblockchain`). This ensures that for every token minted on the remote chain, there’s an equivalent token locked as collateral on the home chain.
-</Accordion>
-<Accordion title="Why is Collateral Important?">
-Collateralization ensures that the total supply of the token remains consistent across both chains. When tokens are sent from the `home chain`, they are locked as collateral, and a corresponding number of tokens is minted on the remote chain. If tokens are sent back to the home chain, the collateral is unlocked, and the minted tokens on the remote chain are burned.
-</Accordion>
-</Accordions>
-
-- **Approve Tokens for Transfer**  
-Approve a certain number of tokens to be used by the Home Transferer. 
-
-```bash  
-cast send --rpc-url local-c --private-key $PK $ERC20_HOME_C_CHAIN "approve(address, uint256)" $ERC20_HOME_TRANSFERER_C_CHAIN 2000000000000000000000
-```
-
-- **Add Collateral and Send Tokens**  
-Add collateral to the transferer contract.
-```bash 
-cast send --rpc-url local-c --private-key $PK $ERC20_HOME_TRANSFERER_C_CHAIN "addCollateral(bytes32, address, uint256)" $L1_BLOCKCHAIN_ID_HEX $NATIVE_TOKEN_REMOTE_L1 100000000000000000000
-```
-Send tokens to the L1.
-```bash 
-cast send --rpc-url local-c --private-key $PK $ERC20_HOME_TRANSFERER_C_CHAIN "send((bytes32, address, address, address, uint256, uint256, uint256, address), uint256)" "(${L1_BLOCKCHAIN_ID_HEX}, ${NATIVE_TOKEN_REMOTE_L1}, ${FUNDED_ADDRESS}, ${ERC20_HOME_C_CHAIN}, 0, 0, 250000, 0x0000000000000000000000000000000000000000)" 1000000000000000000000
-```
-</Step>
-<Step>
-### Check Balances
-
-Finally, check the balance on the L1 to confirm that the tokens were successfully transferred and minted.
-
-```bash
-cast balance --rpc-url myblockchain $FUNDED_ADDRESS
-```
-
-You can also verify that the token is collateralized:
-
-```bash
-cast call --rpc-url myblockchain $NATIVE_TOKEN_REMOTE_L1 "isCollateralized()(bool)"
-```
-</Step>
-</Steps>
-
----
-
-### Conclusion
-
-By following these steps, you’ll successfully transfer a native token from the C-Chain to a L1 and use it as the native token via Avalanche’s Interchain Token Transfer system. 
-
-For more detailed information, refer to the refer to the [official Avalanche ICTT documentation](/course/interchain-token-transfer).
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/03-multi-chain-ecosystems/05-cross-chain-liquidity-pools.mdx b/content/course/l1-tokenomics/03-multi-chain-ecosystems/05-cross-chain-liquidity-pools.mdx
deleted file mode 100644
index 3ee59d1a..00000000
--- a/content/course/l1-tokenomics/03-multi-chain-ecosystems/05-cross-chain-liquidity-pools.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Cross-Chain Liquidity Pools
-description: Enter description
-updated: 2024-09-03
-authors: [0xstt]
-icon: Microscope
----
-
-TBD
-WIP: Implementation
-
diff --git a/content/course/l1-tokenomics/03-multi-chain-ecosystems/06-quiz-time.mdx b/content/course/l1-tokenomics/03-multi-chain-ecosystems/06-quiz-time.mdx
deleted file mode 100644
index 570bd9b0..00000000
--- a/content/course/l1-tokenomics/03-multi-chain-ecosystems/06-quiz-time.mdx
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Quiz Time
-description: Check your Progress!
-updated: 2024-09-03
-authors: [0xstt]
-icon: Terminal
----
-
-You've made it to the end of the section. Let's check your progress.
-
----
-
-<Quiz quizId="205"/>
----
-<Quiz quizId="206"/>
----
-<Quiz quizId="207"/>
----
-<Quiz quizId="208"/>
----
-<Quiz quizId="209"/>
diff --git a/content/course/l1-tokenomics/04-staking/01-staking-tokens.mdx b/content/course/l1-tokenomics/04-staking/01-staking-tokens.mdx
deleted file mode 100644
index 613d7cb4..00000000
--- a/content/course/l1-tokenomics/04-staking/01-staking-tokens.mdx
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Introduction
-description: Learn about staking on Avalanche L1s
-updated: 2024-09-03
-authors: [0xstt]
-icon: Book
----
-
-In many networks, such as Ethereum, the same token is used for both staking and paying for gas. However, in the Avalanche network, staking tokens and gas tokens can be separated, as they fulfill different purposes within the blockchain ecosystem.
-
-### Staking Tokens
-
-Staking tokens are used for securing public, permissionless Avalanche L1s through a proof-of-stake (PoS) consensus mechanism. Holders of staking tokens can:
-
-- Run validators
-- Participate in the consensus process by staking a certain amount of tokens as collateral
-
-Validators propose and validate new blocks on your L1 blockchain. Staking tokens play a crucial role in:
-
-- Maintaining network security
-- Incentivizing validator participation
-
-### Private Avalanche L1s
-
-Not all Avalanche L1s are public and permissionless. Many enterprises choose a **Proof-of-Authority** setup, where the validators are selected by the enterprise. These blockchains do not require a staking token.
diff --git a/content/course/l1-tokenomics/04-staking/02-liquid-staking.mdx b/content/course/l1-tokenomics/04-staking/02-liquid-staking.mdx
deleted file mode 100644
index 9787d552..00000000
--- a/content/course/l1-tokenomics/04-staking/02-liquid-staking.mdx
+++ /dev/null
@@ -1,88 +0,0 @@
----
-title: Liquid Staking
-description: Learn about Liquid Staking and its role in the Avalanche ecosystem.
-updated: 2024-10-08
-authors: [owenwahlgren]
-icon: Book
----
-
-**Liquid Staking** is an innovative mechanism in blockchain networks that allows users to stake their tokens to secure the network while maintaining liquidity. In the Avalanche ecosystem, liquid staking enables participants to earn staking rewards without locking up their assets entirely, providing flexibility and additional opportunities for yield.
-
----
-
-## Understanding Liquid Staking
-
-In traditional staking, users lock up their tokens to support network operations like block validation and consensus. While staked, these tokens are illiquid and cannot be used for other purposes until the staking period ends. Liquid staking addresses this limitation by issuing **staking derivatives** or **liquid tokens** that represent the staked assets.
-
-### How It Works
-
-- **Stake Tokens**: Users stake their AVAX or other supported tokens through a liquid staking provider.
-- **Receive Liquid Tokens**: In return, they receive liquid tokens equivalent to their staked amount.
-- **Earn Rewards**: Users continue to earn staking rewards over time.
-- **Maintain Liquidity**: Liquid tokens can be traded, transferred, or used in decentralized finance (**DeFi**) applications.
-- **Redeem Staked Assets**: At any time, users can redeem their liquid tokens for the original staked assets, subject to network protocols.
-
----
-
-## Benefits of Liquid Staking
-
-### Enhanced Liquidity
-
-- **Flexibility**: Users can participate in staking without sacrificing access to their assets.
-- **DeFi Integration**: Liquid tokens can be used in lending, borrowing, or yield farming platforms, maximizing potential returns.
-
-### Increased Capital Efficiency
-
-- **Dual Rewards**: Earn staking rewards and additional yields from DeFi activities simultaneously.
-- **Portfolio Diversification**: Utilize staked assets in various financial strategies without unstaking.
-
-### Network Security
-
-- **Higher Participation**: Lower barriers encourage more users to stake, enhancing network security and decentralization.
-- **Economic Incentives**: Aligns individual incentives with network health by rewarding active participation.
-
----
-
-## Liquid Staking Providers on Avalanche
-
-### Gogopool
-
-[Gogopool](https://gogopool.com) is a prominent liquid staking provider in the Avalanche ecosystem. It offers a user-friendly platform for staking AVAX tokens while retaining liquidity through their liquid staking token.
-
-#### Features of Gogopool
-
-- **Secure Staking**: Utilizes robust smart contracts audited for security.
-- **Competitive Rewards**: Offers attractive staking yields.
-- **Easy Integration**: Provides seamless integration with popular DeFi platforms on Avalanche.
-- **Community Support**: Active support channels and resources for users.
-
----
-
-## Considerations and Risks
-
-While liquid staking offers numerous benefits, users should be aware of potential risks:
-
-### Smart Contract Risk
-
-- **Vulnerabilities**: Liquid staking relies on smart contracts that may have undiscovered bugs or vulnerabilities.
-- **Mitigation**: Choose providers like Gogopool that have undergone thorough security audits.
-
-### Market Risk
-
-- **Price Volatility**: The value of liquid tokens may fluctuate based on market conditions.
-- **Liquidity**: Ensure there is sufficient market liquidity to trade liquid tokens without significant slippage.
-
-### Protocol Risk
-
-- **Slashing Penalties**: In cases of validator misconduct, staked assets may be slashed, affecting the value of liquid tokens.
-- **Validator Selection**: Use reputable providers that delegate stakes to trustworthy validators.
-
----
-
-## Conclusion
-
-Liquid staking enhances the staking experience on Avalanche by combining the benefits of network participation with the flexibility of liquidity. Providers like [Gogopool](https://gogopool.com) make it accessible and secure for users to maximize their asset utility.
-
-By understanding the mechanics and benefits of liquid staking, participants can make informed decisions that align with their investment strategies and contribute to the overall health and decentralization of the Avalanche network.
-
----
\ No newline at end of file
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
deleted file mode 100644
index 1863e1f2..00000000
--- a/content/course/l1-tokenomics/04-staking/03-staking-contract-post-etna.mdx
+++ /dev/null
@@ -1,151 +0,0 @@
----
-title: Staking Contract (post Etna Upgrade)
-description: How staking will work post Etna upgrade
-updated: 2024-09-03
-authors: [0xstt]
-icon: Book
----
-import { Steps, Step } from 'fumadocs-ui/components/steps';
-
-The contracts in the [`validator-manager`](https://github.com/ava-labs/teleporter/tree/validator-manager/contracts/validator-manager) branch define the Validator Manager used to manage Subnet-only Validators, as defined in [ACP-77](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/77-reinventing-subnets). `ValidatorManager.sol` is the top-level abstract contract that provides the basic functionality. The other contracts are related as follows:
-
-
-<Mermaid chart={`classDiagram
-    class ValidatorManager {
-        initializeValidatorSet()
-        completeValidatorRegistration()
-        completeEndValidation()
-        
-    }
-    <<Abstract>> ValidatorManager
-    class PoSValidatorManager {
-        initializeEndValidation()
-        completeDelegatorRegistration()
-        initializeEndDelegation()
-        completeEndDelegation()
-    }
-    <<Abstract>> PoSValidatorManager
-    class ERC20TokenStakingManager {
-        initializeValidatorRegistration()
-        initializeDelegatorRegistration()
-    }
-    class NativeTokenStakingManager {
-        initializeValidatorRegistration() payable
-        initializeDelegatorRegistration() payable
-    }
-    class PoAValidatorManager {
-        initializeValidatorRegistration()
-        initializeEndValidation()
-    }
-
-    ValidatorManager <|-- PoSValidatorManager
-    ValidatorManager <|-- PoAValidatorManager
-    PoSValidatorManager <|-- ERC20TokenStakingManager
-    PoSValidatorManager <|-- NativeTokenStakingManager
-`} />
-## Deploying
-
-Three concrete `ValidatorManager` contracts are provided - `PoAValidatorManager`, `NativeTokenStakingManager`, and `ERC20TokenStakingManager`. `NativeTokenStakingManager`, and `ERC20TokenStakingManager` implement `PoSValidatorManager`, which itself implements `ValidatorManager`. These are implemented as [upgradeable](https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable) contracts. There are numerous [guides](https://blog.chain.link/upgradable-smart-contracts/) for deploying upgradeable smart contracts, but the general steps are as follows:
-<Steps>
-<Step>
-Deploy the implementation contract
-</Step>
-<Step>
-Deploy the proxy contract
-</Step>
-<Step>
-Call the implementation contract's `initialize` function
-  - Each flavor of `ValidatorManager` requires different settings. For example, `ValidatorManagerSettings` specifies the churn parameters, while `PoSValidatorManagerSettings` specifies the staking and rewards parameters.
-</Step>
-<Step>
-Initialize the Validator set by calling `initializeValidatorSet`
-  - When a Subnet is first created on the P-Chain, it must be explicitly converted to a Subnet-only Validator compatible Subnet via [`ConvertSubnetTx`](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/77-reinventing-subnets#setting-a-subnet-manager). The resulting `SubnetConversionMessage` Warp message is provided in the call to `initializeValidatorSet` to specify the starting Validator set in the `ValidatorManager`. Regardless of the implementation, these initial Validators are treated as PoA and are not eligible for staking rewards.
-</Step>
-</Steps>
-### PoAValidatorManager
-
-Proof-of-Authority Validator management is provided via `PoAValidatorManager`, which restricts modification of the Validator set to an owner address. After deploying `PoAValidatorManager.sol` and a proxy, the `initialize` function takes the owner address, in addition to standard `ValidatorManagerSettings`.
-
-### PoSValidatorManager
-
-Proof-of-Stake Validator management is provided by the abstract contract `PoSValidatorManager`, which has two concrete implementations: `NativeTokenStakingManager` and `ERC20TokenStakingManager`. In addition to basic Validator management provided in `ValidatorManager`, `PoSValidatorManager` supports uptime-based Validation rewards, as well as Delegation to a Validator. This [state transition diagram](https://github.com/ava-labs/teleporter/blob/validator-manager/contracts/validator-manager/StateTransition.md) illustrates the relationship between Validators and Delegators.
-
-#### NativeTokenStakingManager
-
-`NativeTokenStakingManager` allows permissionless addition and removal of Validators that post the Subnet's native token as stake. Staking rewards are minted via the Native Minter Precompile, which is configured with a set of addresses with minting privileges. As such, the address that `NativeTokenStakingManager` is deployed to must be added as an admin to the precompile. This can be done by either calling the precompile's `setAdmin` method from an admin address, or setting the address in the Native Minter precompile settings in the chain's genesis (`config.contractNativeMinterConfig.adminAddresses`). There are a couple of methods to get this address: one is to calculate the resulting deployed address based on the deployer's address and account nonce: `keccak256(rlp.encode(address, nonce))`. The second method involves manually placing the `NativeTokenStakingManager` bytecode at a particular address in the genesis, then setting that address as an admin.
-
-```
-{
-    "config" : {
-        ...
-        "contractNativeMinterConfig": {
-            "blockTimestamp": 0,
-            "adminAddresses": [
-                "0xffffffffffffffffffffffffffffffffffffffff"
-            ]
-        }
-    },
-    "alloc": {
-        "0xffffffffffffffffffffffffffffffffffffffff": {
-            "balance": "0x0",
-            "code": "<NativeTokenStakingManagerByteCode>",
-            "nonce": 1
-        }
-    }
-}
-```
-
-#### ERC20TokenStakingManager
-`ERC20TokenStakingManager` allows permissionless addition and removal of Validators that post the an ERC20 token as stake. The ERC20 is specified in the call to `initialize`, and must implement [`IERC20Mintable`](https://github.com/ava-labs/teleporter/blob/validator-manager/contracts/validator-manager/interfaces/IERC20Mintable.sol). Care should be taken to enforce that only authorized users are able to call `mint`.
-
-### Convert PoA to PoS
-
-A `PoAValidatorManager` can later be converted to a `PoSValidatorManager` by upgrading the implementation contract pointed to by the proxy. After performing the upgrade, the `PoSValidatorManager` contract should be initialized by calling `initialize` as described above. The Validator set contained in the `PoAValidatorManager` will be tracked by the `PoSValidatorManager` after the upgrade, but will not be eligible to earn staking rewards, nor are they able to be delegated to.
-
-## Usage
-### Register a Validator
-Validator registration is initiated with a call to `initializeValidatorRegistration`. Churn limitations are checked - only a certain (configurable) percentage of the total weight is allowed to be added or removed in a (configurable) period of time. The `ValidatorManager` then constructs a [`RegisterSubnetValidatorMessage`](https://github.com/ava-labs/teleporter/blob/validator-manager/contracts/validator-manager/MessageSpec.md#registersubnetvalidatormessage) Warp message to be sent to the P-Chain. Each Validator registration request includes all of the information needed to identify the Validator and its stake weight, as well as an `expiry` timestamp before which the `RegisterSubnetValidatorMessage` must be delivered to the P-Chain. If the Validator is not registered on the P-Chain before the `expiry`, then the Validator may be removed from the contract state by calling `completeEndValidation`.
-
-The `RegisterSubnetValidatorMessage` is delivered to the P-Chain as the Warp message payload of a [`RegisterSubnetValidatorTx`](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/77-reinventing-subnets#registersubnetvalidatortx). Please see the transaction [specification](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/77-reinventing-subnets#step-2-issue-a-registersubnetvalidatortx-on-the-p-chain) for validity requirements. The P-Chain then signs a [`SubnetValidatorRegistrationMessage`](https://github.com/ava-labs/teleporter/blob/validator-manager/contracts/validator-manager/MessageSpec.md#subnetvalidatorregistrationmessage) Warp message indicating that the specified Validator was successfully registered on the P-Chain.
-
-The `SubnetValidatorRegistrationMessage` is delivered to the `ValidatorManager` via a call to `completeValidatorRegistration`. For PoS Validator Managers, staking rewards begin accruing at this time.
-
-### Remove a Validator
-Validator exit is initiated with a call to `initializeEndValidation` on the `ValidatorManager` , For `PoSValidatorManagers` a [`ValidationUptimeMessage`](https://github.com/ava-labs/teleporter/blob/validator-manager/contracts/validator-manager/MessageSpec.md#validationuptimemessage) Warp message may optionally be provided in order to calculate the staking rewards; otherwise the latest received uptime will be used (see [(PoS only) Submit and Uptime Proof](#pos-only-submit-an-uptime-proof)). This proof may be requested directly from the Subnet Validators, which will provide it in a `ValidationUptimeMessage` Warp message. If the uptime is not sufficient to earn Validation rewards, the call to `initializeEndValidation` will fail. `forceInitializeEndValidation` acts the same as `initializeEndValidation`, but bypasses the uptime-based rewards check. Once `initializeEndValidation` or `forceInitializeEndValidation` is called, staking rewards cease accruing for `PoSValidatorManagers`. 
-
-The `ValidatorManager` contructs a [`SetSubnetValidatorWeightMessage`](https://github.com/ava-labs/teleporter/blob/validator-manager/contracts/validator-manager/MessageSpec.md#setsubnetvalidatorweightmessage) Warp message with the weight set to `0`. This is delivered to the P-Chain as the payload of a [`SetSubnetValidatorWeightTx`](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/77-reinventing-subnets#setsubnetvalidatorweighttx). The P-Chain acknowledges Validator exit by signing a `SubnetValidatorRegistrationMessage` with `valid=0`, which is delivered to the `ValidatorManager` by calling `completeEndValidation`. The Validation is removed from the contract's state, and for `PoSValidatorManagers`, staking rewards are disbursed and stake is returned.
-
-#### Disable a Validator Directly on the P-Chain
-
-ACP-77 also provides a method to disable a Validator without interacting with the Subnet directly. The P-Chain transaction [`DisableValidatorTx`](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/77-reinventing-subnets#disablevalidatortx) disables the Validator on the P-Chain. The disabled Validator's weight will still count towards the Subnet's total weight. 
-
-Disabled Subnet Validators can re-activate at any time by increasing their balance with an `IncreaseBalanceTx`. Anyone can call `IncreaseBalanceTx` for any Validator on the P-Chain. A disabled Validator can only be totally removed from the Validator set by a call to `initializeEndValidation`.
-
-### (PoS only) Register a Delegator
-
-`PoSValidatorManager` supports Delegation to an active Validator as a way for users to earn staking rewards without having to validate the chain. Delegators pay a configurable percentage fee on any earned staking rewards to the host Validator. A Delegator may be registered by calling `initializeDelegatorRegistration` and providing an amount to stake. The Delegator will be registered as long as churn restrictions are not violated. The Delegator is reflected on the P-Chain by adjusting the Validator's registered weight via a [`SetSubnetValidatorWeightTx`](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/77-reinventing-subnets#setsubnetvalidatorweighttx). The weight change acknowledgement is delivered to the `PoSValidatorManager` via a [`SubnetValidatorWeightUpdateMessage`](https://github.com/ava-labs/teleporter/blob/validator-manager/contracts/validator-manager/MessageSpec.md#subnetvalidatorweightupdatemessage), which is provided by calling `completeDelegatorRegistration`.
-
-> The P-Chain is only willing to sign a `SubnetValidatorWeightUpdateMessage` for an active Validator. Once Validator exit has been initiated (via a call to `initializeEndValidation`), the `PoSValidatorManager` must assume that the Validator has been deactivated on the P-Chain, and will therefore not sign any further weight updates. Therefore, it is invalid to _initiate_ adding or removing a Delegator when the Validator is in this state, though it _may be_ valid to _complete_ an already initiated Delegator action, depending on the order of delivery to the P-Chain. If the Delegator weight change was submitted (and a Warp signature on the acknowledgement retrieved) before the Validator was removed, then the Delegator action may be completed. Otherwise, the acknowledgement of the Validation end must first be delivered before completing the Delegator action. 
-
-### (PoS only) Remove a Delegator
-
-Delegators removal may be initiated by calling `initializeEndDelegation`, as long as churn restrictions are not violated. Similar to `initializeEndValidation`, an uptime proof may be provided to be used to determine Delegator rewards eligibility. If no proof is provided, the latest known uptime will be used (see [(PoS only) Submit and Uptime Proof](#pos-only-submit-an-uptime-proof)). The Validator's weight is updated on the P-Chain by the same mechanism used to register a Delegator. The `SubnetValidatorWeightUpdateMessage` from the P-Chain is delivered to the `PoSValidatorManager` in the call to `completeEndDelegation`.
-
-### (PoS only) Submit an Uptime Proof
-
-The [rewards calculater](https://github.com/ava-labs/teleporter/blob/validator-manager/contracts/validator-manager/interfaces/IRewardCalculator.sol) is a function of uptime seconds since the Validator's start time. In addition to doing so in the calls to `initializeEndValidation` and `initializeEndDelegation` as described above, uptime proofs may also be supplied by calling `submitUptimeProof`. Unlike `initializeEndValidation` and `initializeEndDelegation`, `submitUptimeProof` may be called by anyone, decreasing the likelihood of a Validation or Delegation not being able to claim rewards that it deserved based on its actual uptime.
-
-### (PoS only) Collect Staking Rewards
-#### Validation Rewards
-
-Validation rewards are distributed in the call to `completeEndValidation`.
-
-#### Delegation Rewards
-
-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.
-
-<Quiz quizId="210" />
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/04-staking/04-register-validators.mdx b/content/course/l1-tokenomics/04-staking/04-register-validators.mdx
deleted file mode 100644
index 5fa76658..00000000
--- a/content/course/l1-tokenomics/04-staking/04-register-validators.mdx
+++ /dev/null
@@ -1,130 +0,0 @@
----
-title: Registering PoS Validators
-description: Learn how validators are registered on the Avalanche network post-etna.
-updated: 2024-10-14
-authors: [owenwahlgren]
-icon: Terminal
----
-
-> How does it all work? I mean *actually* work.
-
-### Sending Warp Messages
-
-On the EVM, a warp message is simply an event log with `messageID = sha256(messagePayload)` Nothing is ever actually “sent” anywhere, which trips people up when first learning how Warp Messaging works.
-
-The log event emitted is from the Warp precompile address (`0x0200000000000000000000000000000000000005`) The topic of the message will be `0x56600c567728a800c0aa927500f831cb451df66a7af570eb4df4dfbf4674887d` which is the output of 
-```bash
-cast keccak "SendWarpMessage(address,bytes32,bytes)"
-```
-
-To find a specific warp messageID, one must know the block number or block hash to retrieve the logs, or be monitoring all events, looking for and indexing messages. 
-
-When a block is [accepted](https://github.com/ava-labs/coreth/blob/7242ae2d235593d2bb14e2496b6ed102aab14c3d/precompile/contracts/warp/config.go#L130) by the network, a precompile hook is called, and the EVM saves the warp message to a local database. The validator node will then be willing to sign any messages in that database upon request, typically via an `AppRequest` message over the p2p network.
-
-### Receiving Warp Messages
-
-On the EVM, any smart contract can call the precompile
-
-which returns the warp message and verifies the attached signature. But what is `index`? Where does it get the warp message from?  The answer is, you!  When you send a tx to any contract that eventually calls `getVerifiedWarpMessage`, you **must** pass in the signed warp message as a “predicate”.  It’s called an AccessList, and typically this is an optional field that can be used by the EVM to pre-fetch storage slots that will be accessed, for efficiency and reducing gas costs. But Warp cleverly (ab)uses this feature of the EVM to verify the signature of the warp message, and then make the warp message available during the transactions lifetime, by calling `getVerifiedWarpMessage`. You can pass multiple warp messages which is where the `index` comes in.  (All of this is abstracted away by Teleporter for EVM to EVM comms)
-
-Details: [Warp README](https://github.com/ava-labs/coreth/blob/7242ae2d235593d2bb14e2496b6ed102aab14c3d/precompile/contracts/warp/README.md)
-
-### Teleporter
-
-[Teleporter](https://github.com/ava-labs/teleporter) is a set of smart contracts that implements a rich messaging protocol on top of the Warp Messaging primitive, allowing for verified message passing between EVM chains. 
-
-<Callout>
-**Only (currently) supports EVM→EVM comms. Not used for EVM→P-Chain**
-</Callout>
-
-### Relayer
-
-[Relayer](https://github.com/ava-labs/awm-relayer/blob/main/relayer/README.md) is an off-chain program that listens for warp messages on a source chain, and delivers them to a destination chain.  Messages can choose to be relayed by anyone, or by only privileged relayers. Messages can also pay fees to incentivize relayers and cover gas costs.
-
-## Registering ValidatorManager
-
-ACP-77 introduces L1-only Validators, that stake no AVAX, and do not validate the X/C chains. They must connect to the Primary Network and track the P-Chain, and also validate their own chain, and pay a small continuous fee in AVAX to the network.
-
-User submits EVM tx to smart contract [NativeTokenStakingManager.sol](https://github.com/ava-labs/teleporter/blob/acp-77-updates/contracts/validator-manager/NativeTokenStakingManager.sol)
-
-```solidity
-function initializeValidatorRegistration(
-        ValidatorRegistrationInput calldata registrationInput,
-        uint16 delegationFeeBips,
-        uint64 minStakeDuration) payable returns (bytes32 validationID)
-```
-Notably, this function will:
-
-- Lock the native tokens in the contract
-- `validationID`: bytes32 hash of an encoded `RegisterSubnetValidatorMessage`
-- `messageID`: bytes32 hash of the warp message
-- Store some data in the contract:
-
-
-```solidity
-$._pendingRegisterValidationMessages[validationID] = registerSubnetValidatorMessage;
-$._registeredValidators[input.nodeID] = validationID;
-bytes32 messageID = WARP_MESSENGER.sendWarpMessage(registerSubnetValidatorMessage);
-$._validationPeriods[validationID] = Validator({
-  status: ValidatorStatus.PendingAdded,
-  nodeID: input.nodeID,
-  startingWeight: weight,
-  messageNonce: 0,
-  weight: weight,
-  startedAt: 0, // The validation period only starts once the registration is acknowledged.
-  endedAt: 0
-});
-```
-
-- Emit `ValidationPeriodCreated(validationID, nodeID, messageID, weight, registrationExpiry)`
-- The `sendWarpMessage` precompile will emit a log with `sender`, `messageID`, `message`
-
-At this point, we have submitted a transaction on the blockchain (C-Chain or L1, wherever the staking contract is deployed). All that has happened is we have stored some state in our contract and emitted some events. No changes to validators has occurred.
-
-<Callout>
-Nothing else will happen UNLESS an off-chain actor continues the process.
-</Callout>
-
-
-In our case, someone must be running a relayer that is configured with our staking contract as the source and the P-Chain as the destination.
-
-<Callout>
-At the moment, the relayer does not support the P-Chain, so messages must be signed and sent manually. The relayer will be updated soon to support the P-Chain.
-</Callout>
-
-
-So, to sign and send the message ourselves, we can use the Signature Aggregator server in the relayer project. This will use the p2p layer of the Avalanche network to connect to validators and send `AppRequest` messages to request each validator to sign a message.
-```bash
-curl --location 'http://localhost:8080/aggregate-signatures' \
---json '{"message": "<hex encoded unsigned message bytes retrieved from the logs>"}'
-```
-This will give us an aggregated BLS signature from at least 67% of the stake weighted validator set. Now we need to `POST` this to the P-Chain via the `RegisterSubnetValidatorTx` tx.
-
-The P-Chain, if it accepts the tx, will “send” a Warp Message `SubnetValidatorRegistration` which acknowledges the change. Note that nothing is actually “sent”, instead the validator node will be willing to sign the unsigned message upon request.
-
-So the next step is to use the Signature Aggregator service again, and provide the unsigned `SubnetValidatorRegistration` warp message, which the service will then ask validators to sign.
-
-<Callout>
-If your Validator Manager contract is on your L1 (instead of C-Chain), as an optimization, you only need to ask 67% of the stake weighted validators of your L1, not the entire P-Chain validator set.
-</Callout>
-
-
-Once an aggregate BLS signature is created, we need to submit the signed message to the C-Chain (or L1) by calling a function on the `ValidatorManager` contract.
-
-```solidity
-function completeValidatorRegistration(uint32 messageIndex)
-```
-
-Remember, this involves calling the function via `eth_sendTransaction` and encoding the signed warp message into the `AccessList`. (If you encode an array of 1 warp message, then `messageIndex` would be 0)
-
-The function will adjust the state in the contract, including these bits:
-```solidity
-delete $._pendingRegisterValidationMessages[validationID];
-$._validationPeriods[validationID].status = ValidatorStatus.Active;
-$._validationPeriods[validationID].startedAt = uint64(block.timestamp);
-```
-And that’s it!
-
-<Callout>
-This doc is a WIP and we will eventually cover all the flows and add some diagrams.
-</Callout>
diff --git a/content/course/l1-tokenomics/05-transaction-fees/01-introduction.mdx b/content/course/l1-tokenomics/05-transaction-fees/01-introduction.mdx
deleted file mode 100644
index 24264901..00000000
--- a/content/course/l1-tokenomics/05-transaction-fees/01-introduction.mdx
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title: Introduction
-description: Learn about blockchain transaction fees.
-updated: 2024-09-03
-authors: [0xstt]
-icon: Book
----
-
-### Background
-When creating an Avalanche L1 we cannot only configure our custom native token, but also how the transaction fees (also known as gas fees) are determined. This allows Avalanche L1s to define the desired or maximal throughput of the blockchain differently.
-
-![](/course-images/multi-chain-architecture/subnet-fee-comparison.png)
-
-In the context of the EVM, gas is a unit that measures the computational effort required to execute specific operations. Each operation performed by a contract or transaction on an EVM chain consumes a certain number of gas units based on its complexity. Operations that require more computational resources cost more gas. The EVM calculates the required gas units automatically, and developers are encouraged to optimize their contract code to reduce gas consumption.
-```bash
-Transaction Cost = Gas Units * Gas Price
-```
-For EVM based Avalanche L1s, gas payment can be configured to better suit the use case of the L1. This means the L1 can design and decide whether the gas fees are burned, paid to incentivize validators, or used for any other custom behavior.
-
-### Gas Price and Gas Limit
-Each transaction specifies the gas price and gas limit:
-
-**Gas Price**: The gas price is the amount of the Avalanche L1's native token that the sender is **willing to spend per unit of gas**, typically denoted in gwei (1 native token = 1,000,000,000 gwei).
-
-**Gas Limit**: The gas limit is the **maximum amount** of gas the sender is willing to use for the transaction. It was introduced to prevent infinite loops in contract execution.
-
-In a Turing-complete language like Solidity (the main programming language in the EVM), it is possible to write a contract with an infinite loop, either accidentally or intentionally. While an infinite loop might be a nuisance in traditional computing, it could cause significant issues in a decentralized blockchain by causing the network to hang as it attempts to process a never-ending transaction. The gas limit prevents this by halting execution once the gas consumed reaches the limit.
-
-If a transaction exceeds the gas limit, it fails, but the fee amounting to the gas limit is still paid by the sender.
\ 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
deleted file mode 100644
index 9e24335c..00000000
--- a/content/course/l1-tokenomics/05-transaction-fees/02-transaction-fee-configuration.mdx
+++ /dev/null
@@ -1,75 +0,0 @@
----
-title: Transaction Fee Configuration
-description: Configure the transaction fee for an Avalanche L1
-updated: 2024-09-03
-authors: [0xstt]
-icon: Book
----
-
-## Configuration Format
-
-The fees are configured in the `chainConfig` in the `feeConfig` field:
-
-```json
-{
-  "config": {
-    // ...
-    "feeConfig": { // [!code highlight]
-      "gasLimit": 15000000,
-      "minBaseFee": 25000000000,
-      "targetGas": 15000000,
-      "baseFeeChangeDenominator": 36,
-      "minBlockGasCost": 0,
-      "maxBlockGasCost": 1000000,
-      "targetBlockRate": 2,
-      "blockGasCostStep": 200000
-    },
-    "allowFeeRecipients": false
-  },
-  "alloc": {
-    // ...
-  },
-  // ...
-    
-  "gasLimit": 0xe4e1c0,
-  // ...
-}
-```
-
-## Gas Configuration Parameters
-
-### `gasLimit`
-
-Sets the maximum amount of gas consumed per block. This restriction caps the computational capacity of a single block and thereby limits the maximum gas usage allowed for any single transaction. For reference, the C-Chain value is set to 15,000,000.
-
-You might notice that the `gasLimit` field appears twice. This is because Avalanche introduced its own fee configuration under the `feeConfig` key while maintaining compatibility with the standard EVM configuration. Ensure that both fields have the same decimal and hexadecimal equivalent values.
-
-### `targetBlockRate`
-
-Specifies the target rate of block production in seconds. For instance, a target of 2 aims to produce a block every 2 seconds. If blocks are produced faster than this rate, it signals that more blocks are being issued to the network than anticipated, leading to an increase in base fees. For C-Chain, this value is set to 2.
-
-### `minBaseFee`
-
-Establishes a lower bound on the EIP-1559 base fee for a block. This minimum base fee effectively sets the minimum gas price for any transaction included in that block.
-
-### `targetGas`
-
-Indicates the targeted amount of gas (including block gas cost) to be consumed within a rolling 10-second window. The dynamic fee algorithm adjusts the base fee proportionally based on how actual network activity compares to this target. If network activity exceeds the `targetGas`, the base fee is increased accordingly.
-
-### `baseFeeChangeDenominator`
-
-Determines how much to adjust the base fee based on the difference between actual and target utilization. A larger denominator results in a slower-changing base fee, while a smaller denominator allows for quicker adjustments. For C-Chain, this value is set to 36, meaning the base fee changes by a factor of 1/36 of the parent block's base fee.
-
-### `minBlockGasCost`
-
-Sets the minimum amount of gas charged for the production of a block. In the C-Chain, this value is set to 0.
-
-### `maxBlockGasCost`
-
-Specifies the maximum amount of gas charged for the production of a block.
-
-### `blockGasCostStep`
-
-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/05-transaction-fees/03-dynamic-fee-configuration.mdx b/content/course/l1-tokenomics/05-transaction-fees/03-dynamic-fee-configuration.mdx
deleted file mode 100644
index 871bf0e5..00000000
--- a/content/course/l1-tokenomics/05-transaction-fees/03-dynamic-fee-configuration.mdx
+++ /dev/null
@@ -1,123 +0,0 @@
----
-title: Dynamic Fee Configuration
-description: Dynamically configure transaction fees on the Avalanche network.
-updated: 2024-09-03
-authors: [0xstt]
-icon: Book
----
-
-### Configuring Dynamic Fees​
-You can configure the parameters of the dynamic fee algorithm on chain using the `FeeConfigManager`. In order to activate this feature, you will need to provide the `FeeConfigManager` in the genesis:
-
-```json
-{
-  "config": {
-    "feeManagerConfig": {
-      "blockTimestamp": 0,
-      "adminAddresses": ["0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC"]
-    }
-  }
-}
-```
-
-The precompile implements the `FeeManager` interface which includes the same `AllowList` interface used by `ContractNativeMinter`, `TxAllowList`, etc.
-
-The Stateful Precompile contract powering the `FeeConfigManager` adheres to the following Solidity interface at `0x0200000000000000000000000000000000000003` (you can load this interface and interact directly in Remix).
-
-
-```solidity
-//SPDX-License-Identifier: MIT
-pragma solidity ^0.8.0;
-import "./IAllowList.sol";
- 
-interface IFeeManager is IAllowList {
-  struct FeeConfig {
-    uint256 gasLimit;
-    uint256 targetBlockRate;
-    uint256 minBaseFee;
-    uint256 targetGas;
-    uint256 baseFeeChangeDenominator;
-    uint256 minBlockGasCost;
-    uint256 maxBlockGasCost;
-    uint256 blockGasCostStep;
-  }
-  event FeeConfigChanged(
-    address indexed sender,
-    FeeConfig oldFeeConfig,
-    FeeConfig newFeeConfig
-  );
- 
-  // Set fee config fields to contract storage
-  function setFeeConfig(
-    uint256 gasLimit,
-    uint256 targetBlockRate,
-    uint256 minBaseFee,
-    uint256 targetGas,
-    uint256 baseFeeChangeDenominator,
-    uint256 minBlockGasCost,
-    uint256 maxBlockGasCost,
-    uint256 blockGasCostStep
-  ) external;
- 
-  // Get fee config from the contract storage
-  function getFeeConfig()
-    external
-    view
-    returns (
-      uint256 gasLimit,
-      uint256 targetBlockRate,
-      uint256 minBaseFee,
-      uint256 targetGas,
-      uint256 baseFeeChangeDenominator,
-      uint256 minBlockGasCost,
-      uint256 maxBlockGasCost,
-      uint256 blockGasCostStep
-    );
- 
-  // Get the last block number changed the fee config from the contract storage
-  function getFeeConfigLastChangedAt()
-    external
-    view
-    returns (uint256 blockNumber);
-}
-``` 
-
-`FeeConfigManager` precompile uses `IAllowList` interface directly, meaning that it uses the same AllowList interface functions like `readAllowList` and `setAdmin`, `setManager`, `setEnabled`, `setNone`.
-
-In addition to the AllowList interface, the `FeeConfigManager` adds the following capabilities:
-
-- `getFeeConfig`: retrieves the current dynamic fee config
-- `getFeeConfigLastChangedAt`: retrieves the timestamp of the last block where the fee config was updated
-- `setFeeConfig`: sets the dynamic fee config on chain (see here for details on the fee config parameters). This function can only be called by an Admin, Manager or Enabled address.
-- `FeeConfigChanged`: an event that is emitted when the fee config is updated. Topics include the sender, the old fee config, and the new fee config.
-
-You can also get the fee configuration at a block with the `eth_feeConfig` RPC method.
-
-### Initial Fee Config Configuration​
-It's possible to enable this precompile with an initial configuration to activate its effect on activation timestamp. This provides a way to define your fee structure to take effect at the activation.
-
-To use the initial configuration, you need to specify the fee config in `initialFeeConfig` field in your genesis or upgrade file:
-
-```json
-{
-  "config": {
-    "feeManagerConfig": {
-      "blockTimestamp": 0,
-      "adminAddresses": ["0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC"],
-      "initialFeeConfig": {
-        "gasLimit": 15000000,
-        "minBaseFee": 25000000000,
-        "targetGas": 15000000,
-        "baseFeeChangeDenominator": 36,
-        "minBlockGasCost": 0,
-        "maxBlockGasCost": 1000000,
-        "targetBlockRate": 2,
-        "blockGasCostStep": 200000
-      }
-    }
-  }
-}
-```
-
-This will set the fee config to the values specified in the `initialFeeConfig` field.
-
diff --git a/content/course/l1-tokenomics/05-transaction-fees/04-fee-distribution.mdx b/content/course/l1-tokenomics/05-transaction-fees/04-fee-distribution.mdx
deleted file mode 100644
index 0755bab7..00000000
--- a/content/course/l1-tokenomics/05-transaction-fees/04-fee-distribution.mdx
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title: Fee Distribution
-description: Customize fee distribution on an Avalanche L1
-updated: 2024-09-03
-authors: [0xstt]
-icon: Book
----
-import { Callout } from 'fumadocs-ui/components/callout';
-
-### Setting a Custom Fee Recipient​
-
-By default, all fees are burned (sent to the black hole address with `"allowFeeRecipients": false`). However, it is possible to enable block producers to set a fee recipient (who will get compensated for blocks they produce).
-
-To enable this feature, you'll need to add the following to your genesis file (under the "config" key):
-
-```json
-{
-  "config": {
-    "allowFeeRecipients": true
-  }
-}
-```
-
-### Fee Recipient Address​
-With `allowFeeRecipients` enabled, your validators can specify their addresses to collect fees. They need to update their EVM chain config with the following to specify where the fee should be sent to.
-
-```json
-{
-  "feeRecipient": "<YOUR 0x-ADDRESS>"
-}
-```
-<Callout>
-If `allowFeeRecipients` feature is enabled on the Avalanche L1, but a validator doesn't specify a `feeRecipient`, the fees will be burned in blocks it produces.
-</Callout>
-This mechanism can be also activated as a precompile. See [Changing Fee Reward Mechanisms](https://docs.avax.network/avalanche-l1s/upgrade/customize-avalanche-l1#changing-fee-reward-mechanisms) in Avalanche docs for more details
diff --git a/content/course/l1-tokenomics/06-distribution/01-initial-allocation.mdx b/content/course/l1-tokenomics/06-distribution/01-initial-allocation.mdx
deleted file mode 100644
index 8d6e86fa..00000000
--- a/content/course/l1-tokenomics/06-distribution/01-initial-allocation.mdx
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title: Initial Allocation
-description: Considerations for the initial token allocation on an Avalanche L1
-updated: 2024-09-03
-authors: [0xstt]
-icon: Book
----
-
-The creator of an Avalanche L1 can pre-allocate native tokens during the chain genesis event. This **initial token allocation** refers to the distribution of tokens or digital assets when a new blockchain network is launched, which is a crucial aspect of the network's design.
-
-> **Note:** Initial token allocation determines how tokens are distributed among stakeholders and participants.
-
-### Key Considerations for Initial Token Allocation
-
-There are several factors to consider when allocating tokens:
-
-#### Founders and Development Team
-
-A portion of the initial token supply is often allocated to the founders and the development team as a reward for their efforts in creating the blockchain protocol. This serves as an incentive for continued development and network maintenance.
-
-#### Early Investors and Backers
-
-Another portion of the token supply may be allocated to early investors and backers who provided funding or support during the project's early stages. These entities take on early risk and are rewarded with tokens that may increase in value as the network grows.
-
-#### Community
-
-A significant portion of tokens may be allocated to the community through mechanisms such as token sales, airdrops, or other distribution methods. This ensures widespread ownership and participation in the network, fostering decentralization and security.
-
-#### Reserve
-
-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/02-vesting-schedules.mdx b/content/course/l1-tokenomics/06-distribution/02-vesting-schedules.mdx
deleted file mode 100644
index 6d8d4b51..00000000
--- a/content/course/l1-tokenomics/06-distribution/02-vesting-schedules.mdx
+++ /dev/null
@@ -1,96 +0,0 @@
----
-title: Vesting Schedules
-description: Learn about vesting schedules and how to implement them in Solidity.
-updated: 2024-10-08
-authors: [owenwahlgren]
-icon: Book
----
-
-**Vesting schedules** are mechanisms used in blockchain projects to release tokens to team members, investors, or other stakeholders over a specified period. This approach helps align incentives, prevent immediate sell-offs, and promote long-term commitment to the project.
-
----
-
-## Understanding Vesting Schedules
-
-A vesting schedule dictates how and when tokens are released to a recipient. Common elements include:
-
-- **Cliff Period**: An initial period during which no tokens are vested.
-- **Vesting Period**: The total duration over which tokens are gradually released.
-- **Release Interval**: The frequency at which tokens are released (e.g., monthly, quarterly).
-- **Total Allocation**: The total number of tokens to be vested.
-
-### Types of Vesting Schedules
-
-1. **Linear Vesting**: Tokens are released uniformly over the vesting period.
-2. **Graded Vesting**: Tokens vest in portions at different intervals.
-3. **Cliff Vesting**: All or a significant portion of tokens vest after the cliff period.
-
----
-
-## Implementing Vesting Schedules in Solidity
-
-Smart contracts can automate vesting schedules, ensuring transparency and trustlessness. Below is an example of a simple Solidity contract implementing a linear vesting schedule.
-
-### Example Solidity Contract
-
-```solidity
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.0;
-
-contract TokenVesting {
-    address public beneficiary;
-    uint256 public start;
-    uint256 public duration;
-    uint256 public cliff;
-    uint256 public totalTokens;
-    uint256 public released;
-
-    IERC20 public token;
-
-    constructor(
-        address _token,
-        address _beneficiary,
-        uint256 _start,
-        uint256 _cliffDuration,
-        uint256 _duration,
-        uint256 _totalTokens
-    ) {
-        require(_beneficiary != address(0), "Invalid beneficiary");
-        require(_cliffDuration <= _duration, "Cliff longer than duration");
-        require(_duration > 0, "Duration must be > 0");
-
-        token = IERC20(_token);
-        beneficiary = _beneficiary;
-        start = _start;
-        cliff = _start + _cliffDuration;
-        duration = _duration;
-        totalTokens = _totalTokens;
-    }
-
-    function release() public {
-        require(block.timestamp >= cliff, "Cliff period not reached");
-        uint256 unreleased = releasableAmount();
-        require(unreleased > 0, "No tokens to release");
-
-        released += unreleased;
-        token.transfer(beneficiary, unreleased);
-    }
-
-    function releasableAmount() public view returns (uint256) {
-        return vestedAmount() - released;
-    }
-
-    function vestedAmount() public view returns (uint256) {
-        if (block.timestamp < cliff) {
-            return 0;
-        } else if (block.timestamp >= start + duration) {
-            return totalTokens;
-        } else {
-            return (totalTokens * (block.timestamp - start)) / duration;
-        }
-    }
-}
-
-interface IERC20 {
-    function transfer(address recipient, uint256 amount) external returns (bool);
-}
\ 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
deleted file mode 100644
index 5588cb29..00000000
--- a/content/course/l1-tokenomics/06-distribution/03-bonding-curves.mdx
+++ /dev/null
@@ -1,167 +0,0 @@
----
-title: Bonding Curves
-description: Learn about bonding curves and their role in token economics.
-updated: 2024-10-08
-authors: [owenwahlgren]
-icon: Book
----
-
-**Bonding curves** are mathematical formulas used in blockchain and token economics to define the relationship between a token's price and its supply. They provide a mechanism for automated price discovery and liquidity, enabling decentralized issuance and trading of tokens without relying on traditional market makers or exchanges.
-
----
-
-## Understanding Bonding Curves
-
-A bonding curve is a continuous token model where the price of a token is determined by a predefined mathematical function based on the total supply in circulation. As more tokens are purchased and the supply increases, the price per token rises according to the curve. Conversely, selling tokens decreases the supply and lowers the price.
-
-### Key Concepts
-
-- **Automated Market Maker (AMM)**: A system that provides liquidity and facilitates trading by automatically adjusting prices based on supply and demand.
-- **Price Function**: A mathematical formula that defines how the token price changes with supply.
-- **Liquidity Pool**: A reserve of tokens used to facilitate buying and selling without requiring counterparties.
-
----
-
-## How Bonding Curves Work
-
-### Price Functions
-
-The bonding curve relies on a price function `P(S)`, where:
-
-- `P` is the price per token.
-- `S` is the current supply of tokens.
-
-Common price functions include linear, exponential, and sigmoid curves.
-
-#### Linear Bonding Curve
-
-A simple linear function:
-
-```
-P(S) = a * S + b
-```
-
-- `a` and `b` are constants defining the slope and intercept.
-
-#### Exponential Bonding Curve
-
-An exponential function:
-
-```
-P(S) = e^(k * S)
-```
-
-- `e` is the base of the natural logarithm.
-- `k` is a constant determining the rate of price increase.
-
-### Buying and Selling Tokens
-
-- **Buying Tokens**: To purchase tokens, a user pays an amount calculated by integrating the price function over the desired increase in supply.
-- **Selling Tokens**: To sell tokens, a user receives an amount calculated by integrating the price function over the desired decrease in supply.
-
----
-
-## Applications of Bonding Curves
-
-### Token Launch Mechanisms
-
-Bonding curves enable projects to launch tokens without initial liquidity or listing on exchanges.
-
-- **Continuous Token Issuance**: Tokens can be minted on-demand as users buy them.
-- **Fair Price Discovery**: Prices adjust automatically based on demand.
-
-### Decentralized Finance (DeFi)
-
-Used in AMMs and liquidity pools to facilitate decentralized trading.
-
-- **Uniswap**: Utilizes bonding curves for token swaps.
-- **Balancer**: Manages portfolios using bonding curves.
-
-### Fundraising and DAOs
-
-Facilitate fundraising by allowing investors to buy tokens that represent shares or voting rights.
-
-- **Continuous Organizations**: Organizations that continuously raise funds through token sales governed by bonding curves.
-- **DAO Membership**: Tokens purchased via bonding curves grant access and voting power.
-
----
-
-## Implementing Bonding Curves in Smart Contracts
-
-### Solidity Example
-
-Below is a simplified example of implementing a linear bonding curve in Solidity.
-
-```solidity
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.0;
-
-contract BondingCurve {
-    uint256 public totalSupply;
-    uint256 public constant a = 1e18; // Slope
-    uint256 public constant b = 1e18; // Intercept
-    mapping(address => uint256) public balances;
-
-    function buy() external payable {
-        uint256 tokensToMint = calculateTokensToMint(msg.value);
-        balances[msg.sender] += tokensToMint;
-        totalSupply += tokensToMint;
-    }
-
-    function sell(uint256 tokenAmount) external {
-        require(balances[msg.sender] >= tokenAmount, "Insufficient balance");
-        uint256 ethToReturn = calculateEthToReturn(tokenAmount);
-        balances[msg.sender] -= tokenAmount;
-        totalSupply -= tokenAmount;
-        payable(msg.sender).transfer(ethToReturn);
-    }
-
-    function calculatePrice(uint256 supply) public pure returns (uint256) {
-        return a * supply + b;
-    }
-
-    function calculateTokensToMint(uint256 ethAmount) public view returns (uint256) {
-        // Simplified calculation for demonstration purposes
-        uint256 tokens = ethAmount / calculatePrice(totalSupply);
-        return tokens;
-    }
-
-    function calculateEthToReturn(uint256 tokenAmount) public view returns (uint256) {
-        // Simplified calculation for demonstration purposes
-        uint256 ethAmount = tokenAmount * calculatePrice(totalSupply);
-        return ethAmount;
-    }
-}
-```
-
-Explanation
-
-- **`buy()`:** Users send ETH to buy tokens. The number of tokens minted is calculated based on the bonding curve.
-- **`sell()`:** Users can sell their tokens back for ETH. The amount of ETH returned is calculated based on the current supply.
-- **`calculatePrice()`:** Determines the price per token based on the total supply.
-
-<Callout>This is a simplified example and not suitable for production. Proper handling of floating-point arithmetic and security considerations is necessary.</Callout>
-
-### Considerations and Risks
-
-**Price Volatility**
-
-- **Speculation**: Prices can become volatile due to speculative trading.
-- **Market Manipulation**: Large trades may influence prices significantly.
-
-**Smart Contract Risks**
-
-- **Security Vulnerabilities**: Bugs in the contract can lead to loss of funds.
-- **Complexity**: Implementing accurate bonding curves requires careful mathematical and technical design.
-
-**Liquidity Concerns**
-
-- **Slippage**: Large trades may experience significant price slippage.
-- **Liquidity Pools**: Adequate reserves are necessary to handle buy and sell orders.
-
-## Conclusion
-
-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.
-<Quiz quizId="213"/>
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/06-distribution/04-airdrop.mdx b/content/course/l1-tokenomics/06-distribution/04-airdrop.mdx
deleted file mode 100644
index 141b0acb..00000000
--- a/content/course/l1-tokenomics/06-distribution/04-airdrop.mdx
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: Airdrops
-description: Learn about token airdrops and Core's airdrop service in the Avalanche ecosystem.
-updated: 2024-10-08
-authors: [owenwahlgren]
-icon: Book
----
-
-**Token airdrops** are a popular method in the blockchain ecosystem for distributing tokens to users, promoting projects, and incentivizing community engagement. In the Avalanche network, airdrops can help bootstrap new projects, reward loyal participants, and increase the distribution of tokens to a wider audience.
-
----
-
-## Understanding Airdrops
-
-Airdrops involve sending tokens directly to users' wallets, typically for free or in exchange for simple tasks like participating in network activities, holding a specific token, or interacting with a smart contract. They serve multiple purposes:
-
-- **Marketing and Promotion**: Raise awareness about a new project or token.
-- **User Acquisition**: Attract new users to a platform or service.
-- **Community Rewards**: Reward loyal users and early adopters.
-- **Decentralization**: Distribute tokens widely to enhance network decentralization.
-
----
-
-## Core Wallet's Airdrop Tool
-
-[Core](https://core.app/), Avalanche's native ecosystem wallet and portfolio, has integrated a new promotions and airdrop tool developed by Ava Labs. This tool leverages on-chain data sources for seamless token distribution, allowing any builder to strategically reward their loyal community members.
-
-### Key Features
-
-- **On-Chain Data Integration**: Utilizes indexed on-chain data to identify and reward true users based on their interactions with contracts.
-- **User-Friendly Interface**: Provides a straightforward, free method to use on-chain data for airdrops and promotions.
-- **Custom Queries**: Allows builders to locate community members who have interacted with their contracts using the query builder.
-- **Manual Address Addition**: Enables manual addition or upload of addresses for token distribution.
-
-### How It Works
-
-Ava Labs indexes on-chain data, enabling Core's airdrop tool to quickly analyze contract-level activity. Daily aggregation of C-Chain token balances is conducted at the close of each day (UTC time), collecting balances of native tokens, ERC20, and ERC721 tokens. Users can leverage this data to pinpoint addresses that meet specific criteria based on token activity.
-
-At launch, the tool supports Avalanche C-Chain and a subset of ERC20 tokens, with more tokens to be added in the future.
-
-#### Query Builder
-
-- **Filter Options**: Filter based on holding duration, current holdings, minimum holding duration, or customized date ranges.
-- **Multiple Queries**: Conduct multiple queries in a single search to refine the target audience.
-
-#### Airdrop Distribution
-
-Airdrops are distributed through contracts deployed on-chain. Core's airdrop tool leverages a deployed version of ThirdWeb's audited Airdrop contract and Ava Labs’ internal security team. At launch, airdrops will be distributed evenly among all selected wallets.
-
----
-
-## Benefits of Using Core's Airdrop Tool
-
-- **Efficient Distribution**: Streamlines token distribution and community engagement with its intuitive interface.
-- **Cost-Free**: Provides a free method for builders to conduct airdrops and promotions.
-- **Strategic Rewards**: Allows for targeted airdrops based on specific on-chain activities.
-- **Security**: Utilizes audited contracts and security measures to protect token distributions.
-
----
-
-## Real-World Example: Core Memecoin Month
-
-To showcase the power of the new airdrop tool, Core rewarded all participants from their **Core Memecoin Month**, which ran from April 1 to May 6. Participants received an evenly distributed reward in the same memecoin they used during the event. For example, if a participant qualified by following instructions during COQ’s memecoin week, they were airdropped COQ coins.
-
----
-
-## Considerations
-
-- **Regulatory Compliance**: Ensure that airdrops comply with relevant laws and regulations in your jurisdiction.
-- **User Privacy**: Be mindful of user privacy and data protection when handling wallet addresses.
-- **Security Best Practices**: Utilize audited contracts and follow security best practices to protect against vulnerabilities.
-
----
-
-## Conclusion
-
-Airdrops are a valuable tool for projects in the Avalanche ecosystem to engage with their community, distribute tokens, and promote network growth. Core's new airdrop tool simplifies this process by leveraging on-chain data and providing an intuitive interface for builders and developers.
-
-By utilizing Core's airdrop service, projects can efficiently and securely reward their loyal community members, fostering stronger relationships and encouraging active participation in the Avalanche network.
-
----
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/07-governance/01-introduction.mdx b/content/course/l1-tokenomics/07-governance/01-introduction.mdx
deleted file mode 100644
index 626890b5..00000000
--- a/content/course/l1-tokenomics/07-governance/01-introduction.mdx
+++ /dev/null
@@ -1,52 +0,0 @@
----
-title: Introduction
-description: An overview of governance use cases in Avalanche Layer 1 tokenomics, focusing on token-based voting and permissioning mechanisms.
-updated: 2024-09-03
-authors: [owenwahlgren]
-icon: Book
----
-
-Governance in Avalanche Layer 1 networks center around two fundamental concepts: **token-based voting** and **permissioning through precompiles**. These mechanisms empower the community to manage critical aspects of network functionality and access control. This chapter explores various governance models within the Avalanche ecosystem, including Decentralized Autonomous Organizations (DAOs), quadratic voting, and real-world governance use cases.
-
-### Key Aspects of Governance in Avalanche
-
-#### Token-Based Voting
-
-Token holders of a Layer 1 can play a pivotal role in the governance of the network. They have the authority to vote on proposals that can affect both technical parameters and broader policy decisions. This system ensures that individuals with a stake in the network have a direct influence over its future development.
-
-#### Permissioning Through Precompiles
-
-Governance on Avalanche L1 networks also involves managing precompiles, specifically precompiles with the [AllowList interface](https://docs.avax.network/avalanche-l1s/upgrade/customize-avalanche-l1#allowlist-interface). Precompiles are specialized smart contracts that provide functionalities not available through standard contracts. The AllowList interface is a part of multiple precompiles and can govern who can deploy contracts or send transactions on the network among other functionality. Through governance, the community can vote to add or remove addresses from the AllowList, controlling who has permission to perform specific actions on the network.
-
-### Examples of Governance Use Cases for an Avalanche L1
-
-1. **AllowList Precompile Governance**
-
-   - **Adding or Removing Addresses**
-
-   A common governance activity involves proposals to modify the AllowList for a specific precompile (ie [NativeTokenMinter](https://docs.avax.network/avalanche-l1s/upgrade/customize-avalanche-l1#minting-native-coins)). These proposals may focus on adding or removing addresses, thereby determining who is authorized to interact with the precompile, for example deploying contracts or sending transactions on specific L1s. Token holders can vote on these proposals to ensure that only trusted entities are granted these permissions.
-
-2. **DAOs and L1 Governance**
-
-   - **Decentralized Autonomous Organizations (DAOs)**
-
-   In the Avalanche ecosystem, DAOs can govern specific L1s by making critical decisions on upgrades, permissioning, and operational rules. These organizations typically use token-based voting to reach consensus and effectively manage their resources.
-
-3. **Quadratic Voting**
-
-   - **Promoting Fair Decision-Making**
-
-   Quadratic voting could be employed in a Layer 1's governance to promote more democratic decision-making. This method allocates voting power more equitably among participants, allowing for nuanced decisions. It helps balance the influence between larger and smaller token holders, ensuring that the governance process is fair and representative.
-
-### Importance of Governance in Avalanche L1 Tokenomics
-
-**Permission and Access Control**  
-  Governance over precompiles with the AllowList interface is crucial for decentralizing control over key network functions. It ensures that only community-approved entities can access sensitive parts of the network, enhancing security and trust.
-
-**Balancing Influence**  
-  Mechanisms such as quadratic voting help balance power between large and small token holders. This leads to fairer decision-making processes and fosters a more inclusive community.
-
-**Community-Driven Development**  
-  Token-based governance empowers the community to propose and vote on changes that directly influence the network’s future. This includes decisions related to L1 management, technical upgrades, and the addition or removal of participants.
-
-In the following sections, we will delve deeper into these governance models and examine how they function in practice within Avalanche L1 networks.
\ 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
deleted file mode 100644
index be187803..00000000
--- a/content/course/l1-tokenomics/07-governance/02-governance-models.mdx
+++ /dev/null
@@ -1,166 +0,0 @@
----
-title: Governance Models
-description: Learn about different governance models in blockchain networks.
-updated: 2024-10-08
-authors: [owenwahlgren]
-icon: Book
----
-
-In blockchain networks like Avalanche and other EVM-compatible platforms, governance models are essential for guiding how decisions are made, who holds the authority, and how changes are implemented within the system. Effective governance ensures that the network evolves in a manner that reflects the community’s interests while promoting sustainability, security, and innovation.
-
-## Understanding Governance Models
-
-Governance models can be broadly categorized into three types:
-
-### 1. On-Chain Governance
-
-On-chain governance involves decision-making processes encoded directly into the blockchain protocol. Participants use the network’s native tokens to vote on proposals, and outcomes are automatically enforced by smart contracts.
-
-**Advantages**:
-- Transparency
-- Automation
-- Immutability
-
-**Disadvantages**:
-- Potential for low voter participation
-- Risk of governance attacks if tokens are concentrated
-
-### 2. Off-Chain Governance
-
-Off-chain governance relies on discussions and decisions made outside the blockchain, often through forums, social media, or community meetings. While final implementations may involve on-chain actions, deliberation and consensus-building occur off-chain.
-
-**Advantages**:
-- Flexibility
-- Ability to consider qualitative factors
-
-**Disadvantages**:
-- Less transparency
-- Potential for slower decision-making
-
-### 3. Hybrid Governance
-
-Hybrid governance combines on-chain and off-chain elements, aiming to balance the advantages of both models. Initial discussions and proposal formulations happen off-chain, while voting and implementation are conducted on-chain.
-
-**Advantages**:
-- Improved flexibility
-- Enhanced efficiency
-
-**Disadvantages**:
-- Complexity in coordination
-- Potential disconnect between off-chain discussions and on-chain actions
-
-## Key Components of Governance Models
-
-Effective governance models comprise several key components:
-
-### 1. Proposal Mechanism
-
-A structured process for submitting and discussing proposals is essential.
-
-- **Proposal Submission**: Guidelines for who can submit proposals and how they should be formatted.
-- **Discussion Period**: Allocated time for the community to debate and provide feedback.
-- **Amendments**: Allowing modifications based on community input before voting.
-
-### 2. Voting System
-
-The method by which votes are cast and counted significantly impacts the governance model’s effectiveness.
-
-- **Token-Based Voting**: Votes are weighted based on the number of tokens held.
-- **Quadratic Voting**: Voting power increases quadratically with the number of tokens, promoting fairness.
-- **Delegated Voting**: Token holders can delegate their voting power to representatives.
-
-
-### 3. Execution and Enforcement
-
-Ensuring that approved proposals are implemented correctly is crucial.
-
-- **Automatic Execution**: Smart contracts automatically enforce decisions without human intervention.
-- **Manual Execution**: Designated entities carry out decisions, which may introduce delays or risks.
-
-## Governance Models in the Avalanche Ecosystem
-
-Avalanche supports flexible governance models that can be customized for different Layer 1 (L1) chains and projects.
-
-### L1-Specific Governance
-
-Each L1 can implement its own governance model tailored to its needs.
-
-- **DeFi L1**: Might prioritize rapid, on-chain governance to adapt quickly to market changes.
-- **Enterprise L1**: Might opt for a hybrid model to incorporate regulatory compliance considerations.
-
-### DAO-Based Governance
-
-Decentralized Autonomous Organizations (DAOs) on Avalanche often adopt on-chain governance models with token-based or quadratic voting systems.
-
-- **Transparency**: All decisions are recorded on the blockchain for auditing.
-- **Automation**: Leverage smart contracts to automate proposal submission, voting, and execution.
-- **Efficiency**: Enhance efficiency and trust within the community.
-
-### Permissioned Governance
-
-Some L1s may require permissioned governance models, where only authorized participants can vote or propose changes.
-
-- **Private Networks**: Suitable for applications requiring compliance with specific regulations.
-- **Controlled Participation**: Ensures that only vetted members influence the network.
-
-## Factors Influencing Governance Model Choice
-
-Several factors influence the selection of a governance model:
-
-### Community Size and Diversity
-
-- **Engagement**: Larger communities may benefit from models that promote inclusivity.
-- **Power Distribution**: Models like quadratic voting help mitigate power concentration.
-
-### Regulatory Environment
-
-- **Compliance**: Networks in regulated industries may need governance structures that allow for auditing.
-- **Authority Control**: May require oversight by recognized authorities.
-
-### Network Goals and Values
-
-- **Decentralization**: Networks prioritizing decentralization might avoid models with central points of control.
-- **Security and Scalability**: The chosen model should align with the network’s primary objectives.
-
-## Challenges in Governance Models
-
-Implementing governance models comes with challenges that need addressing:
-
-### Voter Apathy
-
-- **Low Participation**: Can undermine the legitimacy of decisions.
-- **Encouraging Engagement**: Use incentives or simplify processes to boost involvement.
-
-### Governance Attacks
-
-- **Malicious Actors**: May acquire significant voting power to push harmful proposals.
-- **Mitigation Strategies**: Implement time locks, quorum requirements, and reputation systems.
-
-### Complexity and Usability
-
-- **Deterring Participation**: Complex models may discourage users.
-- **User-Friendly Design**: Ensure mechanisms are accessible to encourage broad involvement.
-
-## The Evolution of Governance Models
-
-Governance models are continually evolving to address new challenges and integrate innovative ideas.
-
-### Enhancing Participation
-
-- **Tools and Interfaces**: Develop user-friendly platforms for easier participation.
-
-### Improving Security
-
-- **Safeguards**: Implement measures against attacks to ensure robustness.
-
-### Adapting to Community Needs
-
-- **Feedback Integration**: Allow models to evolve based on community input and changing requirements.
-
-## Conclusion
-
-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.
-
-<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
deleted file mode 100644
index bf6aea20..00000000
--- a/content/course/l1-tokenomics/07-governance/03-daos.mdx
+++ /dev/null
@@ -1,51 +0,0 @@
----
-title: DAOs
-description: Learn about the role and function of DAOs in the Avalanche ecosystem.
-updated: 2024-10-07
-authors: [owenwahlgren]
-icon: Book
----
-
-In the Avalanche ecosystem and other EVM-compatible networks, Decentralized Autonomous Organizations (DAOs) are pivotal for governance. DAOs operate through smart contracts on the blockchain, enabling decentralized management without centralized leadership. They empower communities to collectively make decisions on protocol upgrades, fund allocations, and other critical governance matters.
-
-### How DAOs Function
-
-DAOs in the Avalanche network govern specific L1s or projects using token-based voting mechanisms. Members hold governance tokens granting them the right to propose initiatives and vote on various issues. The decision-making process is transparent and recorded on the blockchain, ensuring accountability and trust among participants.
-
-For example, a DAO might oversee a L1 dedicated to decentralized finance (DeFi) applications. DAO members can vote on proposals related to L1 upgrades, fee structures, or partnership integrations. By distributing governance tokens to participants, the DAO ensures that contributors have a say in the network’s direction.
-
-Please reference OpenZeppelin's Governance contracts for more information on how DAOs can be implemented: [OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/4.x/api/governance).
-### Benefits of DAOs in Governance
-
-- **Decentralization**: Eliminates the need for centralized authorities, reducing risks of single points of failure and corruption. Decision-making power is distributed among token holders, aligning actions with the community’s interests.
-- **Transparency**: All proposals, votes, and decisions are recorded on the blockchain, providing an immutable and transparent governance record. This openness fosters trust and encourages active participation.
-- **Efficiency**: Smart contracts automate many governance aspects, such as vote tallying and proposal execution. Automation reduces human error and accelerates decision-making.
-- **Inclusivity**: By allowing anyone with governance tokens to participate, DAOs promote inclusivity and democratize organizational control. Broad participation can lead to diverse perspectives and innovative solutions.
-
-### DAOs and Tokenomics
-
-DAOs significantly impact the tokenomics of Avalanche and other EVM networks. Governance tokens often have utility beyond voting rights, including staking rewards or fee reductions. This dual utility incentivizes holding and using the tokens, contributing to the network’s economic health.
-
-Additionally, DAOs can manage treasuries funded by network fees or token issuance. These funds can be allocated to development initiatives, marketing efforts, or community grants, as decided by DAO members. Financial autonomy enables DAOs to invest directly in the growth and sustainability of their networks.
-
-### Challenges and Considerations
-
-While DAOs offer numerous benefits, they also face challenges:
-
-- **Governance Participation**: Ensuring active participation can be difficult, as some token holders may be passive investors. Low voter turnout can lead to decisions not reflecting the broader community’s interests.
-- **Security Risks**: Smart contract vulnerabilities pose significant risks. Exploits or bugs in governance contracts can lead to loss of funds or manipulation of voting outcomes.
-- **Regulatory Uncertainty**: The legal status of DAOs is evolving in many jurisdictions. Regulatory actions could impact their operation and recognition, affecting functionality.
-
-### Real-World Examples in the Avalanche Ecosystem
-- **Avalanche Ambassador DAO**: A group of proven projects from the Avalanche ecosystem that want to partner with the Ambassador DAO and support the Avalanche Community. These projects can create exclusive paid bounties for ambassadors to complete. Ambassadors will get opportunities to contribute and collaborate with these projects and the projects will get access to a global network of ambassadors.
-- **DeFi Protocol DAOs**: Projects building on Avalanche establish DAOs to manage protocol parameters like interest rates, collateral requirements, and reward distributions.
-- **Community DAOs**: Focus on community initiatives, funding educational content, organizing events, and promoting Avalanche technologies. The Avalanche Ambassador DAO is an example of a community-driven initiative.
-
-### The Role of DAOs in Future Governance
-
-As the Avalanche network grows, DAOs will likely become increasingly important in governance. They offer a scalable and flexible framework for managing complex decentralized systems. By empowering communities to self-govern, DAOs contribute to the resilience, adaptability, and inclusivity of blockchain networks.
-
-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/07-governance/04-quadratic-voting.mdx b/content/course/l1-tokenomics/07-governance/04-quadratic-voting.mdx
deleted file mode 100644
index 6e49bc01..00000000
--- a/content/course/l1-tokenomics/07-governance/04-quadratic-voting.mdx
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: Quadratic Voting
-description: Enter description
-updated: 2024-10-07
-authors: [owenwahlgren]
-icon: Book
----
-
-### Quadratic Voting
-
-Quadratic voting is a governance mechanism designed to achieve a more equitable and democratic decision-making process by allowing participants to express the intensity of their preferences. In the context of the Avalanche network and other EVM-compatible platforms, quadratic voting helps balance the influence between large and small token holders, mitigating the dominance of wealthy participants and promoting fairness.
-
-#### How Quadratic Voting Works
-
-In traditional token-based voting systems, each token typically equates to one vote, which can lead to disproportionate influence by large token holders. Quadratic voting addresses this imbalance by making the cost of casting multiple votes increase quadratically. This means that the cost of an individual's votes is the square of the number of votes they cast.
-
-For example:
-
-- Casting 1 vote costs 1 credit.
-- Casting 2 votes costs 4 credits.
-- Casting 3 votes costs 9 credits.
-- Casting 4 votes costs 16 credits.
-
-This system ensures that casting a large number of votes becomes progressively more expensive, discouraging any single participant from overwhelming the voting process. It allows individuals to allocate their voting power more strategically, focusing on issues they care about most.
-
-#### Implementation in Avalanche Governance
-
-Quadratic voting can be integrated into an L1's governance models to enhance democratic participation. By adjusting the voting mechanisms in DAOs or other governance frameworks to support quadratic voting, the network can:
-
-- **Promote Inclusivity**: Smaller token holders gain a more significant voice in governance decisions, ensuring that the network's direction reflects a broader range of perspectives.
-- **Encourage Thoughtful Voting**: Participants must consider the cost of casting multiple votes, leading to more deliberate and meaningful voting behavior.
-- **Reduce Plutocracy Risks**: By limiting the disproportionate influence of large token holders, quadratic voting helps prevent the concentration of power and promotes a healthier governance ecosystem.
-
-#### Benefits of Quadratic Voting
-
-- **Fair Representation**: Balances the influence among participants, providing a fairer representation of the community's preferences.
-- **Preference Intensity**: Allows participants to express how strongly they feel about specific issues, not just whether they support or oppose them.
-- **Enhanced Collaboration**: Encourages dialogue and cooperation among stakeholders, as consensus becomes more valuable than sheer voting power.
-
-#### Challenges and Considerations
-
-While quadratic voting offers significant advantages, there are challenges to consider:
-
-- **Sybil Attacks**: Participants might attempt to create multiple identities to circumvent the quadratic cost. Implementing identity verification or staking mechanisms can mitigate this risk.
-- **Complexity**: The quadratic voting system is more complex than traditional voting methods, which may require additional education and user-friendly interfaces to ensure broad adoption.
-- **Economic Barriers**: Although quadratic costs balance influence, participants with more resources still have an advantage. Careful calibration of the cost functions and possible subsidies for smaller holders can help address this issue.
-
-#### Real-World Examples in the Avalanche Ecosystem
-
-Quadratic voting is gaining traction in decentralized governance. While its adoption in Avalanche is still emerging, projects can look to examples like:
-
-- **Gitcoin Grants**: Uses quadratic funding, a concept related to quadratic voting, to allocate funds to public goods based on community support.
-- **Democracy Earth**: An organization advocating for decentralized, blockchain-based governance systems utilizing quadratic voting to enhance democratic processes.
-
-By learning from these implementations, Avalanche projects can design governance models that incorporate quadratic voting to achieve more equitable outcomes.
-
-### The Role of Quadratic Voting in Avalanche Governance
-
-Quadratic voting represents a significant step towards more democratic and fair governance within the Avalanche ecosystem. By empowering participants to express the strength of their preferences without allowing wealth to dominate the decision-making process, quadratic voting aligns with the principles of decentralization and community-driven development.
-
-Incorporating quadratic voting into Avalanche's governance structures can:
-
-- **Strengthen Community Engagement**: Encourages broader participation by making individual votes more impactful.
-- **Improve Decision Quality**: Reflects the true intensity of community sentiments, leading to decisions that better serve the network's interests.
-- **Enhance Network Resilience**: Diversifies governance influence, reducing the risk of centralized control and increasing the network's adaptability.
-
-As an L1 continues to evolve, embracing innovative governance mechanisms like quadratic voting will be essential for fostering a vibrant, inclusive, and sustainable ecosystem.
diff --git a/content/course/l1-tokenomics/07-governance/05-governance-20.mdx b/content/course/l1-tokenomics/07-governance/05-governance-20.mdx
deleted file mode 100644
index 9b2cd76c..00000000
--- a/content/course/l1-tokenomics/07-governance/05-governance-20.mdx
+++ /dev/null
@@ -1,130 +0,0 @@
----
-title: Governance 2.0
-description: Learn about the evolution of blockchain governance models.
-updated: 2024-10-07
-authors: [owenwahlgren]
-icon: Book
----
-
-Governance 2.0 represents the evolution of blockchain governance models, aiming to address the limitations of earlier systems and enhance the efficiency, inclusivity, and adaptability of decentralized networks like Avalanche. By integrating innovative mechanisms and technologies, Governance 2.0 seeks to create more robust and responsive governance structures that better align with the needs of the community.
-
----
-
-## Key Features of Governance 2.0
-
-### Dynamic Participation Incentives
-
-Governance 2.0 models implement incentive structures that reward active engagement. This may include:
-
-- **Staking Rewards**: Earning rewards for participating in voting processes.
-- **Reputation Systems**: Recognizing valuable contributions to the network.
-- **Aligned Tokenomics**: Aligning individual incentives with the network's success.
-
-### Flexible Governance Frameworks
-
-These models prioritize adaptability, allowing governance structures to evolve as the network grows and community needs change. Modular governance components can be updated or replaced without overhauling the entire system, enabling continuous improvement.
-
-### Enhanced Transparency and Accountability
-
-Advanced smart contract capabilities provide greater transparency in decision-making processes. All proposals, votes, and outcomes are recorded on the blockchain, allowing participants to audit and verify governance activities, which fosters trust and accountability.
-
-### Improved Security Measures
-
-Governance 2.0 incorporates robust safeguards against attacks and exploits, including:
-
-- **Time-Locked Contracts**: Preventing sudden changes without community consensus.
-- **Multi-Signature Requirements**: Ensuring multiple approvals for executing decisions.
-- **On-Chain Audits**: Detecting and addressing vulnerabilities promptly.
-
-### Integration of Off-Chain Inputs
-
-By bridging on-chain governance with off-chain data and processes, Governance 2.0 allows for more informed decision-making. Oracle systems can feed relevant external information into governance proposals, enhancing the quality and relevance of decisions.
-
----
-
-## Governance 2.0 in the Avalanche Ecosystem
-
-Avalanche is at the forefront of implementing Governance 2.0 principles, leveraging its high-performance infrastructure and customizable L1s. Key developments include:
-
-### Customizable L1 Governance
-
-Avalanche allows each L1 to adopt its own Governance 2.0 model, tailoring governance mechanisms to the specific needs of its community. This flexibility enables experimentation with innovative governance features and the adoption of best practices across the ecosystem.
-
-### Advanced Voting Mechanisms
-
-The network is exploring and implementing advanced voting systems like:
-
-- **Conviction Voting**: Allowing participants to express the strength of their support.
-- **Holographic Consensus**: Balancing proposal visibility with decision-making efficiency.
-
-These mechanisms aim to improve the expressiveness and effectiveness of governance decisions.
-
-### Interoperability and Cross-Chain Governance
-
-Governance 2.0 on Avalanche supports interoperability, enabling coordinated governance across multiple L1s and chains. This interconnectedness enhances collaboration and resource sharing, strengthening the overall ecosystem.
-
----
-
-## Benefits of Governance 2.0
-
-### Increased Engagement
-
-By providing meaningful incentives and more accessible governance tools, Governance 2.0 encourages higher levels of participation from a diverse range of stakeholders. This leads to decisions that better reflect the community's collective will.
-
-### Adaptive Decision-Making
-
-The flexible nature of Governance 2.0 allows networks to adapt quickly to changing conditions. Whether responding to technological advancements, regulatory shifts, or evolving user needs, these governance models enable timely and effective responses.
-
-### Strengthened Network Resilience
-
-Enhanced security measures and dynamic governance structures reduce vulnerabilities. By mitigating risks of centralization and governance attacks, Governance 2.0 contributes to a more robust and secure network.
-
-### Alignment of Interests
-
-Integrating mechanisms that align individual incentives with the network's success fosters a cooperative environment. Participants are more likely to act in the network's best interest when their own success is directly tied to it.
-
----
-
-## Challenges and Considerations
-
-While Governance 2.0 offers significant advancements, it also presents challenges:
-
-### Complexity Management
-
-More sophisticated governance models can be complex, potentially creating barriers to understanding and participation. Simplifying user interfaces and providing educational resources are essential to ensure broad community engagement.
-
-### Regulatory Compliance
-
-As governance models become more advanced, they may face increased regulatory scrutiny. Balancing compliance with the principles of decentralization requires careful design and ongoing dialogue with regulatory bodies.
-
-### Scalability
-
-Implementing advanced governance features at scale demands efficient infrastructure. Avalanche's high-throughput capabilities position it well to address scalability concerns, but continuous optimization is necessary as the network grows.
-
----
-
-## Future Directions
-
-The evolution of Governance 2.0 is an ongoing process. Future developments may include:
-
-### Integration of Artificial Intelligence
-
-Utilizing AI to analyze proposals and predict outcomes could enhance decision-making processes, providing insights that inform more strategic governance actions.
-
-### Cross-Network Governance
-
-As interoperability between different blockchain networks increases, Governance 2.0 models may facilitate governance that spans multiple platforms, promoting broader collaboration.
-
-### Enhanced Privacy Features
-
-Balancing transparency with privacy, future governance models might incorporate zero-knowledge proofs or other cryptographic techniques to protect participant identities while ensuring accountability.
-
----
-
-## Conclusion
-
-Governance 2.0 represents a significant advancement in how decentralized networks like Avalanche manage decision-making processes. By embracing innovation, enhancing inclusivity, and prioritizing adaptability, these governance models address the shortcomings of earlier systems and set the stage for a more resilient and dynamic blockchain ecosystem.
-
-As your Layer 1 network continues to grow and evolve, implementing Governance 2.0 principles will be crucial for maintaining its competitive edge and ensuring that it meets the needs of its diverse and expanding community. Engaging with these advanced governance models allows participants to directly influence the network's trajectory and contribute to its long-term success.
-
-In the following sections, we will explore specific case studies and practical implementations of Governance 2.0 within the Avalanche ecosystem, highlighting its impact on network governance and community engagement.
\ No newline at end of file
diff --git a/content/course/l1-tokenomics/certificate.mdx b/content/course/l1-tokenomics/certificate.mdx
deleted file mode 100644
index 1c1dd067..00000000
--- a/content/course/l1-tokenomics/certificate.mdx
+++ /dev/null
@@ -1,14 +0,0 @@
----
-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/index.mdx b/content/course/l1-tokenomics/index.mdx
deleted file mode 100644
index 9614a832..00000000
--- a/content/course/l1-tokenomics/index.mdx
+++ /dev/null
@@ -1,82 +0,0 @@
----
-title: Welcome to the Course
-description: Learn about the L1 Tokenomics.
-updated: 2024-09-04
-authors: [0xstt]
-icon: Smile
----
-
-Welcome to the **L1 Tokenomics** course! This course is designed to give you a deep understanding of tokenomics, including the creation, distribution, utility, and governance of tokens within blockchain ecosystems. By the end of this course, you will have practical skills in managing tokens across multi-chain ecosystems, configuring transaction fees, and designing staking and governance models.
-
-## Course Content
-
-### Basics
-
-Learn the fundamentals of tokenomics, including native tokens, ERC-20 tokens, wrapped tokens, and how token decimals affect transactions and supply.
-
-### Native Tokens
-
-Explore how to create custom native tokens, use Avalanche’s native token minter, and integrate ERC-20 tokens as native tokens in cross-chain environments.
-
-### Multi-Chain Ecosystems
-
-Delve into interchain token transfers and cross-chain functionality, using both ERC-20 and native tokens across multiple blockchains.
-
-### Staking
-
-Understand staking tokens, liquid staking, and how to deploy staking contracts, with a focus on post-Etna upgrade features.
-
-### Transaction Fees
-
-Master transaction fee configuration, dynamic fee models, and learn how to distribute fees effectively within decentralized ecosystems.
-
-### Token Distribution
-
-Learn about initial token allocation, advanced vesting schedules, bonding curves for token pricing, and how to implement airdrops.
-
-### Governance
-
-Study governance models, DAOs, quadratic voting, and the latest innovations in governance (Governance 2.0) for decentralized decision-making.
-
----
-
-## Prerequisites
-
-Before starting this course, you should have:
-
-### Basic Understanding of Blockchain
-
-This course is for people with some blockchain knowledge. Check out this [guide](/guide/what-is-a-blockchain) to review what a blockchain is.
-
-### Avalanche
-
-This course is intended for people with knowledge about Cross-Chain communication protocols, and a solid understanding of the basic concepts of Avalanche. You should be familiar with these concepts:
-
-1. Avalanche Architecture: Be familiar with Avalanche blockchains.
-2. Cross-Chain Messages: Know how to communicate between two Avalanche blockchains with Teleporter. 
-
-If some of this is not clear, we strongly recommend taking the Avalanche Fundamentals, Multi-Chain Architecture, and Interchain Messaging courses first.
-
-### Software Development
-
-You will need a general understanding of Software Development. You won't have to write a lot of code, but you will have to be able to understand some. Therefore, we recommend:
-
-1. Solidity: Basic Knowledge, familiarity with types and interfaces. 
-2. Foundry: Familiarity with Foundry will help to deploy and interact with contracts. 
-
----
-
-## Learning Outcomes
-
-By the end of this course, you will:
-
-- Gain a solid grasp of token fundamentals, tokenomics models, and how to create sustainable token economies.
-- Learn how to create custom native tokens and integrate ERC-20 tokens as native tokens in multi-chain environments.
-- Understand the challenges and opportunities in cross-chain token transfers, and liquidity management.
-- Master the technical aspects of configuring transaction fees, setting up staking contracts, and designing dynamic fee models.
-- Create initial allocation plans, implement advanced vesting schedules, and manage bonding curves and airdrops.
-- Develop governance structures, including DAOs and quadratic voting models, to manage decentralized decision-making effectively.
-
----
-
-Start exploring the course content now to dive deep into the exciting world of tokenomics!
diff --git a/content/course/l1-tokenomics/meta.json b/content/course/l1-tokenomics/meta.json
deleted file mode 100644
index 9d3f642d..00000000
--- a/content/course/l1-tokenomics/meta.json
+++ /dev/null
@@ -1,24 +0,0 @@
-{
-  "title": "l1-tokenomics",
-  "root": true,
-  "pages": [
-    "index",
-    "---Basics---",
-    "...01-basics",
-    "---Advanced---",
-    "---Native Tokens---",
-    "...02-native-tokens",
-    "---Multi-Chain Ecosystems---",
-    "...03-multi-chain-ecosystems",
-    "---Staking---",
-    "...04-staking",
-    "---Transaction Fees---",
-    "...05-transaction-fees",
-    "---Token Distribution---",
-    "...06-distribution",
-    "---Governance---",
-    "...07-governance",
-    "---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
deleted file mode 100644
index 916b14c5..00000000
--- a/content/course/multi-chain-architecture/02-custom-blockchains/01-custom-blockchains.mdx
+++ /dev/null
@@ -1,52 +0,0 @@
----
-title: Custom Blockchains
-description: Quickly recap our past learnings about Avalanche Custom Blockchains.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: Book
----
-
-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 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.
-- A Custom Network can validate multiple blockchains.
-- A validator may participate in multiple Custom Networks.
-
-## The Primary Network
-
-Avalanche's three main blockchains form the Primary Network:
-
-- Platform Chain (P-Chain)
-- Contract Chain (C-Chain)
-- Exchange Chain (X-Chain)
-
-These blockchains are validated and secured by all Avalanche validators, which collectively form a special Avalanche L1 known as the Primary Network.
-
-<Callout type="info">By definition, all validators participating in custom blockchain Avalanche L1s must also validate the Avalanche Primary Network.</Callout>
-
-## Independence and Scalability
-
-Custom blockchains and their associated Avalanche L1s operate independently:
-
-- They specify their own execution logic.
-- They determine their own fee structures.
-- They maintain their own state.
-- They facilitate their own networking.
-- They provide their own security.
-
-This independence ensures that custom blockchains don't share execution threads, storage, or networking with other custom blockchain networks or the Primary Network. As a result, the Avalanche network can:
-
-- Scale up easily
-- Enable lower latency
-- Achieve higher transactions per second (TPS)
-- Offer lower transaction costs
-
-By leveraging custom blockchains and custom blockchain networks, Avalanche creates a flexible and scalable ecosystem that can adapt to a wide range of use cases and requirements.
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
deleted file mode 100644
index f3529c28..00000000
--- a/content/course/multi-chain-architecture/02-custom-blockchains/02-benefits-of-custom-blockchains.mdx
+++ /dev/null
@@ -1,55 +0,0 @@
----
-title: Benefits of Custom Blockchains 
-description: Learn about the different benefits of using Custom Blockchains.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: BookOpen
----
-
-Custom blockchains offer a range of advantages for developers and businesses looking to create very custom & tailored solutions. 
-
-## Enhanced Compliance and Access Control
-
-While the C-Chain operates as an open and permissionless network, custom blockchains provide more granular control over user access and permissions. This feature is particularly valuable for applications that need to meet specific regulatory requirements.
-
-- Authorized Access: Developers can configure custom blockchains to allow only pre-approved users to deploy contracts or initiate transactions.
-
-This level of control helps ensure compliance (KYC, AML, etc) with various financial regulations and industry-specific standards.
-
-## Customizable Tokenomics
-
-Custom blockchains offer flexibility in defining the economic model of your network. They allow for: 
-
-- Gas Token Freedom: Unlike fixed gas token systems (e.g., ETH for Ethereum), custom blockchains can use any token as their gas token.
-- Economic Isolation: Your blockchain's economics remain unaffected by gas price fluctuations on other networks, providing stability and predictability.
-
-## Privacy and Confidentiality
-
-While public blockchains offer transparency, many business scenarios require controlled visibility of transaction data. Developers building custom blockchains on Avalanche can enable: 
-
-- Selective Transparency: Private blockchains allow you to limit transaction visibility to authorized participants.
-- Data Protection: Implement transaction encryption to safeguard sensitive information.
-- Granular Access: Control which data is visible to which participants, supporting "need-to-know" access models.
-
-## Virtual Machine Flexibility
-
-The ability to choose or create custom Virtual Machines (VMs) offers unprecedented flexibility. Avalanche custom blockchains allow for developers to have: 
-
-- Multiple VM Support: Unlike single-VM networks like Bitcoin or Ethereum, Avalanche Avalanche L1s can host multiple blockchain instances with different VMs.
-- Ease of Use: Leverage existing VMs like the subnetEVM or create entirely new custom VMs using our SDKs to suit your specific needs.
-- Network Effects: This flexible architecture creates network effects both within individual blockchains and across different Avalanche L1s and blockchains.
-
-## Scalability and Performance
-
-Custom blockchains can be optimized for specific use cases, leading to improved scalability and performance. Launching a custom blockhain gives you: 
-
-- Optimized Resource Allocation: Dedicate computational resources specifically to your blockchain, avoiding competition with other applications.
-
-## Interoperability
-
-Custom blockchains, especially within the Avalanche ecosystem, can be designed with interoperability in mind and can enable: 
-
-- 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
deleted file mode 100644
index a6039f30..00000000
--- a/content/course/multi-chain-architecture/02-custom-blockchains/03-custom-blockchains-vs-layer-2.mdx
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Avalanche L1s vs Layer 2
-description: Comparing different blockchain scaling approaches.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: BookOpen
----
-
-Layer 2 blockchain solutions, such as rollups, are another innovation in the blockchain landscape. Layer 2s aim to enhance the scalability and performance of the Ethereum network. Rollups essentially perform computations off-chain and submit the resultant state changes to the base layer, thereby reducing the computational load on the main Ethereum chain.
-
-While both Avalanche Custom Blockchains and Layer 2 rollups strive to improve blockchain scalability and performance, they use different methods and each have their unique advantages and trade-offs. 
-
-## Decentralization and Security
-
-Avalanche Custom Blockchains are part of the base layer itself. Each blockchain in Avalanche maintains its security, hence a compromise in one blockchain doesn't necessarily impact the others. On the other hand, rollups delegate security to the Ethereum mainnet. As long as the mainnet remains secure, so does the Layer 2 solution, given the rollup performs properly. However, a security breach on the mainnet can potentially affect all Layer 2 solutions.
-
-## Interoperability and Flexibility
-
-Avalanche's multi-chain structure offers great interoperability and flexibility, as each custom blockchain network can define its own rules and validate multiple blockchains of different virtual machines. This means Avalanche can cater to a vast array of use cases. Conversely, Layer 2 solutions are primarily designed to augment the Ethereum mainnet and might not offer the same 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/01-avalanche-starter-kit.mdx b/content/course/multi-chain-architecture/03-avalanche-starter-kit/01-avalanche-starter-kit.mdx
deleted file mode 100644
index c3500541..00000000
--- a/content/course/multi-chain-architecture/03-avalanche-starter-kit/01-avalanche-starter-kit.mdx
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Avalanche Starter Kit
-description: Learn about the basics of Avalanche.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Book
----
-
-To make easier your journey through this course, we have prepared a Starter Kit repo consisting of everything you will need to start developing your own custom blockchains on Avalanche. This repo will provide a self-contained environment with Avalanche-CLI, and Foundry so you can follow the course without the need of installing anything else other than launching the environment.
-
-# What You Will Learn
-
-In this section, you will go through the following topics:
-
-- How to launch your own Codespace
-- Create your own Avalanche Interchain Messaging enabled custom blockchain
-- Foundry configuration
-
-At the end of this section, you will have your environment ready to follow with the Cross-Chain development with Avalanche Interchain Messaging. 
diff --git a/content/course/multi-chain-architecture/03-avalanche-starter-kit/02-set-up.mdx b/content/course/multi-chain-architecture/03-avalanche-starter-kit/02-set-up.mdx
deleted file mode 100644
index 3b4c35c3..00000000
--- a/content/course/multi-chain-architecture/03-avalanche-starter-kit/02-set-up.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Set Up Avalanche Starter Kit
-description: Learn about the basics of Avalanche.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-import SetUp from "@/content/common/avalanche-starter-kit/set-up.mdx";
-
-<SetUp />
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/03-avalanche-starter-kit/03-create-blockchain.mdx b/content/course/multi-chain-architecture/03-avalanche-starter-kit/03-create-blockchain.mdx
deleted file mode 100644
index 43eb6bb1..00000000
--- a/content/course/multi-chain-architecture/03-avalanche-starter-kit/03-create-blockchain.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Create Blockchain
-description: Deploy a new Avalanche L1 on local network.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-import CreateDefaultBlockchain from "@/content/common/avalanche-starter-kit/create-default-blockchain.mdx";
-
-<CreateDefaultBlockchain/>
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/03-avalanche-starter-kit/04-add-blockchain-to-wallet.mdx b/content/course/multi-chain-architecture/03-avalanche-starter-kit/04-add-blockchain-to-wallet.mdx
deleted file mode 100644
index bad01593..00000000
--- a/content/course/multi-chain-architecture/03-avalanche-starter-kit/04-add-blockchain-to-wallet.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Add Blockchain to Wallet
-description: Add the newly created Avalanche L1 to Core.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-import AddBlockchainToWallet from "@/content/common/core-wallet/add-blockchain-to-wallet.mdx";
-
-<AddBlockchainToWallet/>
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/03-avalanche-starter-kit/05-add-ewoq-account.mdx b/content/course/multi-chain-architecture/03-avalanche-starter-kit/05-add-ewoq-account.mdx
deleted file mode 100644
index 46b95f75..00000000
--- a/content/course/multi-chain-architecture/03-avalanche-starter-kit/05-add-ewoq-account.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Import EWOQ Account
-description: Import the private keys of EWOQ account to Core.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-import ImportEWOQAccount from "@/content/common/core-wallet/import-ewoq-account.mdx";
-
-<ImportEWOQAccount/>
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/03-avalanche-starter-kit/06-networks.mdx b/content/course/multi-chain-architecture/03-avalanche-starter-kit/06-networks.mdx
deleted file mode 100644
index 768a1d18..00000000
--- a/content/course/multi-chain-architecture/03-avalanche-starter-kit/06-networks.mdx
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Different Types of Networks
-description: Learn about different types of networks.
-updated: 2024-05-31
-authors: [martineckardt]
-icon: Terminal
----
-
-import Networks from "@/content/common/avalanche-starter-kit/networks.mdx";
-
-You just deployed and interacted with your first local network. But what does that mean? You can interact with your network, but you will notice that no one else can. Therefore, we have to understand what different Networks are in Avalanche.
-
-<Networks />
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
deleted file mode 100644
index c734a718..00000000
--- a/content/course/multi-chain-architecture/03-avalanche-starter-kit/07-pause-and-resume.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-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/01-independent-tokenomics.mdx b/content/course/multi-chain-architecture/04-independent-tokenomics/01-independent-tokenomics.mdx
deleted file mode 100644
index cef47f71..00000000
--- a/content/course/multi-chain-architecture/04-independent-tokenomics/01-independent-tokenomics.mdx
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Independent Tokenomics
-description: Quickly recap our past learnings about Avalanche Custom Blockchains.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: Book
----
-
-Avalanche Custom Blockchains offer multiple ways to implement independent tokenomics. This gives developers more control and can enable new business model that would not be economically feasible on single-chain systems.
-
-The customizations include:
-
-- **Native Token:** Every Avalanche L1 has their own native token used for paying transaction fees. 
-- **Transaction Fees:** We can configure how the transaction fees should be calculated.   
-- **Initial Native Token Allocation:** We can specify how the inital token supply is distributed.
-- **Native Token Minting Rights:** We can specify if and who can mint more native tokens.
-- **Staking Token:** If our Avalanche L1 allows public and permissionless validation, we can define our logic how a node can become a validator.
-
-You will learn about all these topics and get hands-on experience how you can configure the tokenomics of your own custom blockchain.
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
deleted file mode 100644
index 8709b2d8..00000000
--- a/content/course/multi-chain-architecture/04-independent-tokenomics/02-transaction-fees.mdx
+++ /dev/null
@@ -1,12 +0,0 @@
----
-title: Transaction Fees
-description: Let's recap our knowledge on transaction fees in blockchains.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: BookOpen
----
-
-import TransactionFees from '@/content/common/multi-chain-architecture/transaction-fees.mdx';
-
-<TransactionFees />
-<Quiz quizId="403"/>
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/04-independent-tokenomics/03-custom-native-token.mdx b/content/course/multi-chain-architecture/04-independent-tokenomics/03-custom-native-token.mdx
deleted file mode 100644
index e7efd5c9..00000000
--- a/content/course/multi-chain-architecture/04-independent-tokenomics/03-custom-native-token.mdx
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title: Custom Native Token
-description: Learn about custom native token of your Avalanche L1 blockchain.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: BookOpen
----
-
-Every Avalanche L1 blockchain has their own native token used for paying for transactions (gas). This isolates the fee to use the blockchain from any activity on another chains in the ecosystem.
-
-For example, if there is high usage of the primary network, it does not affect the fees on another Avalanche L1.
-
-![](/course-images/multi-chain-architecture/gas-comparison.png)
-
-Having their own blockchain with a custom native token in the Avalanche network can open up a wide range of new use cases for companies, ranging from financial institutions to gaming platforms. By having control over their gas token, these companies can revolutionize the blockchain landscape and enable innovative applications.
-
-Firstly, for financial institutions, having their blockchain with a custom native token can facilitate cheaper transactions compared to traditional banking systems. This flexibility can enable real-time payments, cross-border transactions, and micropayments, fostering financial inclusion and innovation.
-
-For gaming platforms, having their blockchain with a custom native token can revolutionize in-game economies and user experiences. They can design their tokenomics to incentivize gameplay, reward loyal players, and monetize virtual assets.
-
-## Valueless Native Token
-
-Many web3 startups want to provide a gas free experience, especially if their target group is not web3 native and used to paying for each action they take. Deploying on a chain with no control over the gas token, the only option they have is sponsoring the transaction fees. This makes it very hard for many business models to be profitable.
-
-Let's take a simple web3 game where users issue on average 20 transactions a month, each costing on average $0.20 (very optimistic). This means the dApp would have to sponsor $4 of transaction fee per user per month and also be prepared to sponsor a multiple of that in times of increased activity or a price increase of the native token.  
-
-Having control over the native token of their own blockchain allows companies to make it valueless, essentially providing a free Web2-like experience on their blockchain. This approach lowers the entry barriers for users, encourages adoption, and facilitates mass adoption of blockchain technology.
-
-Companies can leverage this to attract users from traditional platforms by offering familiar experiences without the costs and complexities associated with blockchain transactions. 
-
-## Tying the Native Token Value to an existing Token
-
-Some developers may also opt for tying the value of their native token to an existing token. One popular choice for this would be a stablecoin like USDC. This way they still preserve the isolated fees and protect agains price increases of the native token, but avoid issuing their own token. 
-
-This can be achieved by hard-coding that a native token can only be received by depositing the tied asset into a smart contract. If the native token then changes hand (for example by the user issuing a transaction and the fee for that being redistributed to the validators) the new owner can redeem the tied asset.
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/04-independent-tokenomics/04-configure-native-token.mdx b/content/course/multi-chain-architecture/04-independent-tokenomics/04-configure-native-token.mdx
deleted file mode 100644
index 40bda791..00000000
--- a/content/course/multi-chain-architecture/04-independent-tokenomics/04-configure-native-token.mdx
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: Configure Native Token
-description: Learn about how to configure your native token.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: Terminal
----
-
-Let's create a new Avalanche L1 and spend some more attention on how we can configure our native token. So let's run again `avalanche blockchain create myblockchain2`. We will pick again `Subnet-EVM` as our Virtual Machine. However, this time we will not use the default settings:
-
-```bash
-? Do you want to use default values for the Blockchain configuration?: 
-    I want to use defaults for a test environment
-    I want to use defaults for a production environment
-  ▸ I don't want to use default values
-    Explain the difference
-```
-
-Choose to use the `latest version` of Subnet-EVM and pick a ChainID different from your first subnet (e.g. 8888). 
-
-Next you can select a custom token symbol.
-
-Now, we have configured our own token. In the next step we will look at the inital token allocation.
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/04-independent-tokenomics/05-native-token-allocation.mdx b/content/course/multi-chain-architecture/04-independent-tokenomics/05-native-token-allocation.mdx
deleted file mode 100644
index 2e4f7d74..00000000
--- a/content/course/multi-chain-architecture/04-independent-tokenomics/05-native-token-allocation.mdx
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: Native Token Allocation
-description: Initial token allocation of a blockchain refers to the distribution of native tokens when a new blockchain network is launched.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: BookOpen
----
-
-The creator of an Avalanche L1 can pre-allocate the native tokens during the chain genesis event. The initial token allocation of a blockchain refers to the distribution of tokens or digital assets when a new blockchain network is launched.
-
-This allocation is a critical aspect of the network's design, as it determines how tokens are distributed among various stakeholders and participants.
-
-There are several considerations that go into the initial token allocation:
-
-- **Founders and Development Team:** Often, a portion of the initial token supply is allocated to the founders and development team as a reward for their efforts in creating the blockchain protocol. This allocation serves as an incentive for them to continue developing and maintaining the network.
-- **Early Investors and Backers:** Another portion of the token supply may be allocated to early investors and backers who provided funding or support during the project's early stages. These individuals or entities take on early risk and are rewarded with tokens that may increase in value as the network grows.
-- **Community:** A significant portion of tokens may be allocated to the community through mechanisms such as a token sale, airdrops, or other distribution methods. This ensures widespread ownership and participation in the network, fostering decentralization and security.
-- **Reserve:** 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 decentralized autonomous organization (DAO) or a designated entity responsible for allocating funds in the best interest of the network.
-
-Overall, the initial token allocation of a blockchain is a complex and crucial aspect of its design, shaping the network's distribution of ownership, governance, and incentives from the very beginning.
-
-Transparent and equitable token allocation mechanisms are essential for fostering trust and confidence in the network among its stakeholders.
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/04-independent-tokenomics/06-configure-token-allocation.mdx b/content/course/multi-chain-architecture/04-independent-tokenomics/06-configure-token-allocation.mdx
deleted file mode 100644
index 7e624b67..00000000
--- a/content/course/multi-chain-architecture/04-independent-tokenomics/06-configure-token-allocation.mdx
+++ /dev/null
@@ -1,41 +0,0 @@
----
-title: Configure Native Token Allocation
-description: Learn how to configure your blockchain native token allocation.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: Terminal
----
-
-Alright, so let's set the initial token allocation. When prompted select **Define a custom allocation**.
-
-```bash
-? How should the initial token allocation be structured?: 
-    Allocate 1m tokens to a new account
-    Allocate 1m to the ewoq account 0x8db...2FC (Only recommended for testing, not recommended for production)
-  ▸ Define a custom allocation (Recommended for production)
-```
-
-Drop 1000 of your native token to these addresses:
-- 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-- 0xF0f06058ca7B6e46E2B238F6d34A604DB1E2612f
-- 0x321f6B73b6dFdE5C73731C39Fd9C89c7788D5EBc
-
-It should look something like this:
-
-```bash
-✔ Customize your airdrop
-Address to airdrop to: 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
-Amount to airdrop (in TOK units): 1000
-✔ Yes
-Address to airdrop to: 0xF0f06058ca7B6e46E2B238F6d34A604DB1E2612f
-Amount to airdrop (in TOK units): 1000
-✔ Yes
-Address to airdrop to: 0x321f6B73b6dFdE5C73731C39Fd9C89c7788D5EBc
-Amount to airdrop (in TOK units): 1000
-Use the arrow keys to navigate: ↓ ↑ → ← 
-? Would you like to airdrop more tokens?: 
-  ▸ No
-    Yes
-```
-
-Each of these addresses will have 1000 TOK in their account at the start of the network.
\ 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
deleted file mode 100644
index 654c5b75..00000000
--- a/content/course/multi-chain-architecture/04-independent-tokenomics/07-native-token-minting-rights.mdx
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Native Token Minting Rights
-description: Learn how to manage the native token minting rights.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: BookOpen
----
-
-Many chains have a hard-capped supply for their gas token. The Avalanche C-Chain uses AVAX as their gas token and there will only ever be 720m AVAX. This may not be optimal for enterprise use cases, especially if they want to **create an experience with a valueless gas token**.
-
-Therefore, they have the option to mint more native tokens at any time. This can be done through the **Native Minter Precompile**. If a community running an Avalanche L1 wants to hard-cap the native token, that is perfectly doable as well. They just keep the native minter capabilities deactivated (which is the default).
-
-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.
-
-<Quiz quizId="410"/>
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/04-independent-tokenomics/08-activate-native-minter.mdx b/content/course/multi-chain-architecture/04-independent-tokenomics/08-activate-native-minter.mdx
deleted file mode 100644
index 888458cd..00000000
--- a/content/course/multi-chain-architecture/04-independent-tokenomics/08-activate-native-minter.mdx
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: Activating Native Minter Precompile
-description: Learn how to activate the native minter precompile.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: Terminal
----
-
-When prompted if you want to allow minting of new natie tokens, select **Yes**.
-
-```
-? Allow minting of new native tokens?: 
-    No, I want the supply of the native tokens be hard-capped
-  ▸ Yes, I want to be able to mint additional the native tokens (Native Minter Precompile ON)
-```
-
-Let's add an address as an admin for our native token minting:
-
-```
-? Configure the addresses that are allowed to mint native tokens: 
-  ▸ Add an address for a role to the allow list
-    Preview Allow List
-    Confirm Allow List
-    Cancel
-```
-
-First you will be asked what role the address should have. Select `Admin` here:
-
-```
-? What role should the address have?: 
-  ▸ Admin
-    Manager
-    Enabled
-    Explain the difference
-    Cancel
-```
-
-Now enter this address and confirm with enter: `0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC`
-
-Feel free to add more addresses here. Note that every address added here is an Admin. After setting all the admin addresses, go to `Confirm Allow List` and press enter.
-
-```
-? Configure the addresses that are allowed to mint native tokens: 
-    Add an address for a role to the allow list
-    Remove address from the allow list
-    Preview Allow List
-  ▸ Confirm Allow List
-    Cancel
-```
-
-You will be shown a preview of the allowlist. Confirm with `Yes`.
-
-```
-+---------+--------------------------------------------+
-| Admins  | 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC |
-+---------+--------------------------------------------+
-| Manager |                                            |
-+---------+--------------------------------------------+
-| Enabled |                                            |
-+---------+--------------------------------------------+
-
-Use the arrow keys to navigate: ↓ ↑ → ← 
-? Confirm?: 
-  ▸ Yes
-    No, keep editing
- ```
diff --git a/content/course/multi-chain-architecture/04-independent-tokenomics/09-transaction-fees.mdx b/content/course/multi-chain-architecture/04-independent-tokenomics/09-transaction-fees.mdx
deleted file mode 100644
index e173a32f..00000000
--- a/content/course/multi-chain-architecture/04-independent-tokenomics/09-transaction-fees.mdx
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title: Transaction Fees
-description: Learn about L1 blockchain gas fees.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: BookOpen
----
-
-When creating an Avalanche L1 we cannot only configure our custom native token, but also how the transaction fees (also known as gas fees) are determined. This allows Avalanche L1s to define the desired or maximal throughput of the blockchain differently.
-
-![](/course-images/multi-chain-architecture/subnet-fee-comparison.png)
-
-To adjust the fee dynamics we have the following parameter:
-
-**Gas Limit:** The total amount of gas that can be used in a single block. This impacts how much computation happens in one block. The value represents the maximum amount of gas a single transaction can use (which would result in a single transaction block).
-
-**Target Block Rate:** The network aims to produce a new block in targetBlockRate seconds. This value is in seconds. If the network starts producing faster than this, base fees are increased accordingly. Otherwise, if the network starts producing slower than this, base fees are decreased accordingly.
-
-**Min. Base Fee:** The minimum base fee that can be used by a transaction and the cost to do native token transfers. No matter how simple a transaction is, it will cost at least the minimum base fee.
-
-**Target Gas:** The targeted amount of gas (including block gas cost) to consume within a rolling 10s window.
-
-**Base Fee Change Denominator:** The transaction base fee changes with demand of the block space. If the parent block used more gas than its target, the base fee should increase. Otherwise, if the parent block used less gas than its target, the base fee should decrease by the amount. There is a formula behind this that would go beyond the scope of this section, but setting this value to a larger value means that the base fee will change more gradually. Setting it to a smaller value will make the base fee change more rapidly.
-
-**Min. Block Gas Cost:** Minimum gas cost a block should cover.
-
-**Max. Block Gas cost:** Maximum gas cost a block should cover.
-
-**Block Gas Cost Step:** This value determines the block gas change rate depending on the targetBlockRate. If the parent block is produced at the targetBlockRate, the block gas cost will stay the same. If the parent block is produced at a slower rate, the block gas cost will decrease.
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/04-independent-tokenomics/10-configure-transaction-fees.mdx b/content/course/multi-chain-architecture/04-independent-tokenomics/10-configure-transaction-fees.mdx
deleted file mode 100644
index 2957d85e..00000000
--- a/content/course/multi-chain-architecture/04-independent-tokenomics/10-configure-transaction-fees.mdx
+++ /dev/null
@@ -1,68 +0,0 @@
----
-title: Configure Transaction Fees
-description: Learn how to configure your blockchain gas fees.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: Terminal
----
-
-Alright, let's get to configuring our gas fees. When prompted select **Customize fee config**.
-
-```
-? How should the transaction fees be configured on your Blockchain?: 
-    Low block size    / Low Throughput    12 mil gas per block
-    Medium block size / Medium Throughput 15 mil gas per block (C-Chain's setting)
-    High block size   / High Throughput   20 mil gas per block
-  ▸ Customize fee config
-    Explain the difference
-```
-
-Let's assume we are creating an enterprise blockchain with very few computationally intensive transactions. Our goal is:
-
-- Allow very computationally expensive operations. The gas limit of the C-Chain is set to 8,000,000 gwei. Let's pick a number higher than that.
-- Target producing one block every 10 seconds
-- The same minimum transaction base fee as the C-Chain (25000000000wei = 25 gwei)
-- Only slowly adjust the fee. The base fee change denominator of the C-Chain is 36.
-- Have every block cost at least 500,000 gwei and at most 1,000,000 gwei
-- Adjust the block gas cost same as the C-Chain (value 200000)
-- When completely configured it should look something like this:
-
-```
-✔ Customize fee config
-Customizing fee config
-Set gas limit: 15000000
-Set target block rate: 10
-Set min base fee: 25000000000
-Set target gas: 15000000
-Set base fee change denominator: 50
-Set min block gas cost: 500000
-Set max block gas cost: 1000000
-✔ Set block gas cost step: 200000
-```
-
-Next you will be asked if you would like the fees to be dynamic:
-
-```
-? Do you want dynamic fees on your blockchain?: 
-  ▸ No, I prefer to have constant gas prices
-    Yes, I would like my blockchain to have dynamic fees
-    Explain the difference
-```
-
-Next you will be asked if the fees should be changeable without a network upgrade:
-
-```
-? Should transaction fees be adjustable without a network upgrade?: 
-  ▸ No, use the transaction fee configuration set in the genesis block
-    Yes, allow adjustment of the transaction fee configuration as needed. Recommended for production (Fee Manager Precompile ON)
-    Explain the difference
-```
-
-As a last question you will be asked if the fees should be burned:
-
-```
-? Do you want the transaction fees to be burned (sent to a blackhole address)? All transaction fees on Avalanche are burned by default: 
-  ▸ Yes, I want the transaction fees to be burned
-    No, I want to customize accumulated transaction fees distribution (Reward Manager Precompile ON)
-    Explain the difference
-```
diff --git a/content/course/multi-chain-architecture/04-independent-tokenomics/11-staking-token.mdx b/content/course/multi-chain-architecture/04-independent-tokenomics/11-staking-token.mdx
deleted file mode 100644
index 0f64c1b8..00000000
--- a/content/course/multi-chain-architecture/04-independent-tokenomics/11-staking-token.mdx
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Staking Token
-description: Learn about staking tokens in blockchain networks.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: BookOpen
----
-
-In many networks, such as Ethereum, the same token is used for staking and paying for gas. In the Avalanche network staking tokens and gas tokens can be separated, since they fullfil different purposes within the blockchain ecosystem.
-
-Staking tokens are used for securing public permissionless Avalanche L1s through a proof-of-stake (PoS) consensus mechanism. Holders of staking tokens can run validators and participate in the consensus process by staking a certain amount of tokens as collateral.
-
-Validators propose and validate new blocks of your L1 blockchain. Staking tokens play a crucial role in maintaining network security and incentivizing their participation.
-
-Not all Avalanche L1s are public and permissionless. Many enterprises choose a Proof-of-Authority setup, where the validators are selected by the enterprise. These blockchains do not have a staking token.
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/05-interoperability/01-interoperability.mdx b/content/course/multi-chain-architecture/05-interoperability/01-interoperability.mdx
deleted file mode 100644
index dc4b9685..00000000
--- a/content/course/multi-chain-architecture/05-interoperability/01-interoperability.mdx
+++ /dev/null
@@ -1,33 +0,0 @@
----
-title: Interoperability
-description: Learn about interoperability in the Avalanche ecosystem
-updated: 2024-08-26
-authors: [owenwahlgren]
-icon: Book
----
-
-## What is Interoperability?
-Interoperability refers to the ability of different blockchain networks to communicate, share data, and interact with each other seamlessly. This capability allows assets, information, and functionalities to move between separate blockchain ecosystems without the need for intermediaries.
-
-## Bootstrapping Problems for New Blockchains
-New blockchain networks face many challenges when they are first starting out, particularly in gaining adoption, achieving network effects, and building a robust ecosystem. Some common bootstrapping issues include:
-
-### Lack of Liquidity
-Liquidity is essential for any blockchain, especially if it involves tokens or other financial instruments. Without liquidity, users and developers may be hesitant to engage with the platform.
-
-By enabling cross-chain asset transfers, interoperability can inject liquidity from established blockchains into a new network. For instance, a new Avalanche Layer 1 blockchain can integrate with decentralized finance (DeFi) protocols on other chains, bringing in liquidity and users.
-### Limited Integration Support
-Attracting developers to build on a new blockchain is challenging, especially when there are more established platforms with robust tooling and large communities.
-
-Interoperability can provide developers with the ability to create cross-chain applications. This allows developers to leverage tools and communities from other blockchains, reducing the friction involved in developing on a new Layer 1 blockchain.
-
-For example, a developer may need to access data from a blockchain oracle service (such as Chainlink Price Feeds) that is not yet available on the new blockchain. By using interoperability, the developer can access the oracle data from another blockchain and integrate it directly into their application.
-
-Another example could be integration with existing stablecoin providers, such as USDC or DAI.
-
-Typically, these types of integrations would be a lengthy and expensive process. The developer would need to convince the provider to integrate onto their blockchain, or build custom bridges and oracles to connect the new blockchain with the external service. Interoperability simplifies this process by providing standardized mechanisms for cross-chain communication and asset transfers that allows developers to leverage existing implementations on other blockchains.
-
-### Lack of On-Ramps
-A new blockchain may lack direct on-ramp services (like exchanges or fiat gateways) due to its early-stage development. Users would need to buy a cryptocurrency supported by the new blockchain, but if few exchanges support it, this can be a significant barrier.
-
-Interoperability allows users to transfer assets from more established blockchains (like Ethereum) to the new blockchain. For instance, a user could buy Ethereum (ETH) on an exchange, and then use a cross-chain bridge to move those assets onto the new blockchain, where they can be swapped for the native token.
\ 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
deleted file mode 100644
index 95aaed99..00000000
--- a/content/course/multi-chain-architecture/05-interoperability/02-interoperability-use-cases.mdx
+++ /dev/null
@@ -1,63 +0,0 @@
----
-title: Interoperability Use Cases
-description: Learn about the use cases for interoperability on Avalanche
-updated: 2024-08-26
-authors: [owenwahlgren]
-icon: BookOpen
----
-
-Interoperability is a critical aspect of blockchain technology, enabling seamless interactions across different blockchain networks without relying on intermediaries. On Avalanche, interoperability facilitates various use cases, enhancing user experience and expanding the ecosystem’s capabilities. Below are some key use cases:
-
-## 1. Cross-Chain Token Transfers
-
-Tokens are widely used for transactions and value storage across multiple blockchains. With interoperability on Avalanche, users can transfer tokens (such as USDC) from one Layer 1 (L1) blockchain to another without interacting with centralized exchanges or third parties. 
-
-- **Seamless Transfers**: Move tokens across different chains (e.g., Ethereum, Avalanche, Binance Smart Chain) with minimal fees and fast transaction times.
-- **Liquidity Access**: Leverage liquidity from various networks to engage in DeFi activities, trading, or payments on Avalanche.
-- **Decentralization**: Avoid reliance on centralized platforms, maintaining control over assets during the transfer process.
-
-## 2. Decentralized Data Feeds (Chainlink Price Feeds)
-
-Chainlink provides decentralized oracle networks that deliver reliable and tamper-proof price feeds for various assets. Through interoperability on Avalanche, smart contracts can access these price feeds without the need for third-party intermediaries.
-
-- **Accurate Pricing**: Utilize real-time price data from Chainlink to power DeFi applications, such as lending platforms, derivatives, and automated market makers (AMMs).
-- **Trustless Integration**: Obtain price feeds directly from Chainlink’s decentralized oracles, ensuring data integrity and reducing dependency on centralized data providers.
-- **Cross-Chain Applications**: Implement cross-chain financial applications on Avalanche that rely on accurate and consistent price feeds across multiple networks.
-
-## 3. Cross-Chain Token Swaps
-
-Interoperability allows for direct token swaps between different blockchain networks. Users can swap tokens on Avalanche with tokens on other chains without the need for centralized exchanges or custodians.
-
-- **Decentralized Exchange**: Swap assets in a trustless environment, reducing counterparty risk and ensuring security.
-- **Multi-Chain Access**: Access tokens from various ecosystems (e.g., Ethereum ERC-20 tokens) and bring them to Avalanche for use in DeFi, gaming, or other applications.
-- **Lower Costs**: Avoid high fees associated with cross-chain transfers on centralized platforms, taking advantage of Avalanche’s low-cost and high-speed transactions.
-
-## 4. Cross-Chain NFTs
-
-With interoperability, non-fungible tokens (NFTs) can be transferred across different blockchain networks. This enables creators and users to move NFTs from one platform to another, expanding the potential for cross-chain collaborations and marketplaces.
-
-- **Broad Exposure**: NFTs minted on one blockchain (e.g., Ethereum) can be showcased and traded on Avalanche, reaching a wider audience.
-- **Enhanced Utility**: Use NFTs across multiple platforms and applications, including gaming, art, and virtual worlds, without being confined to a single blockchain.
-- **Ownership Preservation**: Maintain ownership and provenance of NFTs across chains, ensuring authenticity and traceability.
-
-## 5. Interoperable DeFi Protocols
-
-DeFi protocols on Avalanche can interact with protocols on other chains, enabling cross-chain lending, borrowing, and liquidity provision. This interoperability expands the utility and user base of DeFi applications on Avalanche.
-
-- **Cross-Chain Yield Farming**: Participate in yield farming opportunities across multiple chains, maximizing returns on assets.
-- **Cross-Chain Collateralization**: Use assets from other blockchains as collateral on Avalanche-based lending platforms, increasing flexibility and access to capital.
-- **Composability**: Build DeFi applications that leverage the strengths of multiple blockchain networks, creating innovative financial products and services.
-
-## 6. Cross-Chain Governance
-
-Interoperability enables decentralized governance processes that span multiple blockchains. Projects can implement governance models where decisions made on one chain can influence or be enacted on another.
-
-- **Unified Governance**: Govern multi-chain protocols from a single platform, streamlining decision-making processes.
-- **Decentralized Voting**: Enable cross-chain voting mechanisms that allow token holders on different blockchains to participate in governance decisions.
-- **Enhanced Participation**: Increase community engagement by allowing governance participation across multiple ecosystems, leading to more diverse and representative decision-making.
-
-## 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
deleted file mode 100644
index ef2c1ece..00000000
--- a/content/course/multi-chain-architecture/05-interoperability/03-icm-and-icm-protocol.mdx
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title: Interchain Messaging & the Interchain Messaging Protocol
-description: Learn how Avalanche achieves interoperability with ICM and the ICM Protocol
-updated: 2024-08-26
-authors: [owenwahlgren]
-icon: Book
----
-
-Avalanche is designed to be a highly interoperable blockchain platform, enabling seamless communication and asset transfers across different blockchains. Two key technologies that power this interoperability on Avalanche are **Interchain Messaging** and the **Interchain Messaging Protocol**. These mechanisms are integral to Avalanche’s mission of creating a unified and connected blockchain ecosystem.
-
-## Interchain Messaging (ICM)
-
-**ICM** is Avalanche's mechanism for facilitating the rapid transfer of assets between different L1s within the Avalanche network. It functions as a cross-chain bridge, allowing assets to be moved between different blockchains or L1s efficiently and securely.
-
-### How ICM Works
-
-ICM operates by locking an asset on the source chain and minting an equivalent representation on the destination chain. This ensures that the total supply of the asset remains consistent across all chains. The process involves:
-
-1. **Asset Locking**: When an asset needs to be transferred, it is locked on the source chain through a smart contract. This prevents the asset from being used or transferred elsewhere.
-
-2. **Minting on Destination**: Once the asset is locked, an equivalent token is minted on the destination chain, representing the original asset.
-
-3. **Validation**: The transfer is validated by a decentralized network of validators, ensuring that the process is secure and trustworthy.
-
-4. **Unlocking/Reversing the Transfer**: If the asset needs to be moved back, the reverse process occurs where the minted token is burned on the destination chain, and the original asset is unlocked on the source chain.
-
-### Benefits
-
-- **Speed**: Transfers using ICM are rapid, enabling near-instantaneous asset movements across chains.
-- **Security**: The locking and minting process ensures that assets are always accounted for, minimizing the risk of loss or double-spending.
-- **Flexibility**: ICM supports a wide range of assets, making it versatile for various use cases.
-
-## Interchain Messaging Protocol
-
-**Avalanche Interchain Messaging Protocol** is a communication protocol that allows different blockchains within the Avalanche network to exchange messages and data without relying on third-party intermediaries. AWM enables smart contracts on different chains to interact with each other directly, facilitating complex cross-chain operations.
-
-### How the ICM Protocol Works
-
-The ICM Protocol leverages Avalanche’s unique consensus mechanism to securely and efficiently transmit messages across different blockchains. The process involves:
-
-1. **Message Creation**: A smart contract on the source chain creates a message containing the data or instructions to be sent to the destination chain.
-
-2. **Message Signing and Validation**: The message is signed and validated by a set of validators to ensure its integrity and authenticity.
-
-3. **Message Transmission**: The validated message is transmitted across the network to the destination chain.
-
-4. **Message Execution**: Upon receiving the message, the destination chain executes the instructions or processes the data as specified in the message.
-
-### Benefits
-
-- **Decentralization**: AWM eliminates the need for centralized intermediaries, preserving the decentralized nature of the Avalanche network.
-- **Efficiency**: The protocol is designed to be efficient, enabling fast and secure message transmission across chains.
-- **Scalability**: AWM supports a large number of cross-chain interactions, making it suitable for complex multi-chain applications.
-
-## 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/05-interoperability/04-activating-interchain-messaging.mdx b/content/course/multi-chain-architecture/05-interoperability/04-activating-interchain-messaging.mdx
deleted file mode 100644
index 148c3be8..00000000
--- a/content/course/multi-chain-architecture/05-interoperability/04-activating-interchain-messaging.mdx
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Activating Interchain Messaging
-description: Learn how to activate Interchain Messaging on your blockchain create with Avalanche CLI
-updated: 2024-06-28
-authors: [usmaneth]
-icon: Terminal
----
-
-Avalanche offers native interoperability between all Avalanche L1s. You will be asked if you want to connect your blockchain with other blockchains or the C-Chain. Select the first option to enable your blockchain to interoperate with other blockchains and the C-Chain. You can simply activate it by selecting `Yes`.
-
-```
-? Do you want to connect your blockchain with other blockchains or the C-Chain?: 
-  ▸ Yes, I want to enable my blockchain to interoperate with other blockchains and the C-Chain
-    No, I want to run my blockchain isolated
-    Explain the difference
-```
-
-This will result in the warp precompile being activated and the Interchain Messaging contracts to be deployed to your Avalanche L1. Furthermore, if you deploy it on a local network, Avalanche CLI will also run a relayer for you. You will can learn more about how the interoperability work in the course Avalanche Interchain Messaging.
\ 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
deleted file mode 100644
index 16dd7f03..00000000
--- a/content/course/multi-chain-architecture/06-permissioning-users/01-permissioning.mdx
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Permissioning
-description: Learn about different ways of permissioning your Avalanche L1 blockchain.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: Book
----
-
-Permissioning your Avalanche L1 is an optional feature of having your own L1 blockchain. There may be many reasons why a blockchain creator may want to permission their network including these:
-
-- **Privacy and Confidentiality:** In industries where data privacy is crucial, such as finance or healthcare, permissioned blockchains allow only authorized parties to access sensitive information. This ensures that confidential data remains protected from unauthorized access.
-- **Regulatory Compliance:** Many industries are subject to strict regulatory requirements regarding data handling and security. Permissioned blockchains enable organizations to implement necessary controls to ensure compliance with regulatory standards without compromising the integrity of the blockchain.
-- **Cost-efficiency:** Restricting the usage of a blockchain to certain use cases may make it more cost efficient. Blockchain operators may be able to avoid transaction fee spikes caused events such as NFT drops by imposing restrictions.
-
-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.
-
-<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
deleted file mode 100644
index c9692e1a..00000000
--- a/content/course/multi-chain-architecture/06-permissioning-users/02-compliance.mdx
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title: Compliance
-description: Learn how you can configure compliance for your Avalanche L1.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: BookOpen
----
-
-For institutions, reputational damage and legal complications could arise if their blockchain systems were inadvertently used for criminal activities.
-
-Regulatory bodies might impose penalties on such institutions if they were to fail to create sufficient controls to prevent these activities.
-
-Most institutions have nuanced compliance requirements. Therefore, many institutions need flexible blockchains that can meet these needs. 
-
-## Interacting with Criminal Actors
-
-In permissionless systems, the counterparty on a trade is unknown. If a user performs a swap on a decentralized exchange on a permissionless blockchain, such as Ethereum or the Avalanche C-Chain, the origin of funds that are received are mostly unknown. 
-
-To solve this problem, each Avalanche L1 can restrict who can interact with the blockchain. Only a whitelist of accounts can issue transactions. One could build a blockchain where only accounts that went through a KYC process are permitted.
-
-## Interacting with Illegal Services
-
-An additional risk to consider is that businesses may operate within an environment prone to illicit activities, or they may inadvertently become involved in such actions. In a permissionless system, any individual has the capability to deploy any contract, regardless of its compliance with the legal framework.
-
-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.
-
-<Quiz quizId="407"/>
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/06-permissioning-users/03-activate-permissioning.mdx b/content/course/multi-chain-architecture/06-permissioning-users/03-activate-permissioning.mdx
deleted file mode 100644
index bf02e82b..00000000
--- a/content/course/multi-chain-architecture/06-permissioning-users/03-activate-permissioning.mdx
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title: Activate Permissioning
-description: TBD
-updated: 2024-06-28
-authors: [martineckardt]
-icon: Terminal
----
-
-To enable permissioning, select `No` when prompted to allow anyone to issue transactions to your blockchain.
-
-```
-? Do you want to enable anyone to issue transactions and deploy smart contracts to your blockchain?: 
-    Yes
-  ▸ No
-    Explain the difference
-```
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/06-permissioning-users/04-tx-allowlist.mdx b/content/course/multi-chain-architecture/06-permissioning-users/04-tx-allowlist.mdx
deleted file mode 100644
index f453fcff..00000000
--- a/content/course/multi-chain-architecture/06-permissioning-users/04-tx-allowlist.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Transaction Allowlist
-description: TBD
-updated: 2024-06-28
-authors: [usmaneth]
-icon: BookOpen
----
-
-import TxAllowList from "@/content/common/evm-precompiles/transaction-allowlist.mdx";
-
-<TxAllowList />
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/06-permissioning-users/05-activate-tx-allowlist.mdx b/content/course/multi-chain-architecture/06-permissioning-users/05-activate-tx-allowlist.mdx
deleted file mode 100644
index 104dba51..00000000
--- a/content/course/multi-chain-architecture/06-permissioning-users/05-activate-tx-allowlist.mdx
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title: Activate Transaction Allowlist
-description: TBD
-updated: 2024-06-28
-authors: [martineckardt]
-icon: Terminal
----
-
-Avalanche L1s do not implement permissioning by default. To enable permissioning, you need to activate the transaction allowlist. This allows only approved addresses to issue transactions on your blockchain. Therefore, select `No` when prompted to allow anyone to issue transactions to your blockchain.
-
-```
-? Do you want to enable anyone to issue transactions to your blockchain?: 
-    Yes, I want anyone to be able to issue transactions on my blockchain
-  ▸ No, I want only approved addresses to issue transactions on my blockchain (Transaction Allow List ON)
-    Explain the difference
-```
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/06-permissioning-users/06-contract-deployer-allowlist.mdx b/content/course/multi-chain-architecture/06-permissioning-users/06-contract-deployer-allowlist.mdx
deleted file mode 100644
index b50479e8..00000000
--- a/content/course/multi-chain-architecture/06-permissioning-users/06-contract-deployer-allowlist.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Contract Deployer Allowlist
-description: TBD
-updated: 2024-06-28
-authors: [martineckardt]
-icon: BookOpen
----
-
-import ContractDeployerAllowlist from "@/content/common/evm-precompiles/contract-deployer-allowlist.mdx";
-
-<ContractDeployerAllowlist />
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/06-permissioning-users/07-activate-contract-deployer-allowlist.mdx b/content/course/multi-chain-architecture/06-permissioning-users/07-activate-contract-deployer-allowlist.mdx
deleted file mode 100644
index 4179a9fb..00000000
--- a/content/course/multi-chain-architecture/06-permissioning-users/07-activate-contract-deployer-allowlist.mdx
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: Activate Contract Deployer Allowlist
-description: TBD
-updated: 2024-06-28
-authors: [martineckardt]
-icon: Terminal
----
-
-```
-? Do you want to enable anyone to deploy smart contracts on your blockchain?: 
-    Yes, I want anyone to be able to deploy smart contracts on my blockchain
-  ▸ No, I want only approved addresses to deploy smart contracts on my blockchain (Smart Contract Deployer Allow List ON)
-    Explain the difference
-```
\ 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
deleted file mode 100644
index 9ea56954..00000000
--- a/content/course/multi-chain-architecture/07-permissioning-validators/01-permissioning-validators.mdx
+++ /dev/null
@@ -1,32 +0,0 @@
----
-title: Permissioning Validators
-description: Learn about different ways of permissioning your Avalanche L1 blockchain.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: Book
----
-
-The ability to control a blockchain's validator set has many benefits that can significantly enhance the efficiency, security, and governance of the network. It allows blockchain participants to have greater influence over the consensus process and decision-making, leading to a more robust and adaptable ecosystem. There are two ways to structure the validator set:
-
-- **Permissionless Validation:** Anyone can participate in the validation process and be rewarded in tokens to cover their costs for the hardware and running the validator. In Avalanche, we call Avalanche L1s that take this approach Elastic Avalanche L1s.
-- **Permissioned Validation:** Only whitelisted validators can validate the Avalanche L1. A permissioned Avalanche L1 can be turned into a Elastic Avalanche L1 at any time, but not the other way round.
-
-There are many reasons why the creators might want a permissioned validator set for their Avalanche L1. 
-
-## Enterprises and Corporations: 
-
-Large enterprises and corporations often require blockchain solutions for their internal operations or specific industry use cases. A permissioned validator set allows them to control who can participate in the network and validate transactions. This is particularly relevant in industries with strict regulatory requirements, where entities need to ensure compliance and data privacy.
-
-## Consortiums and Industry Associations: 
-
-Consortiums or industry associations comprising multiple organizations with shared interests can benefit from a permissioned validator set. These entities often collaborate on initiatives requiring a distributed ledger, such as supply chain management, healthcare data sharing, or financial transactions. By establishing a permissioned validator set, the consortium can ensure that trusted participants from within the consortium validate the transactions.
-
-## Government Agencies: 
-
-Government entities may find value in launching a blockchain with a permissioned validator set to manage critical infrastructure, public services, or regulatory processes. They can select validators from trusted institutions or stakeholders to maintain control over the network while ensuring compliance with legal and governance requirements. Examples include land registry systems, voting platforms, or identity management solutions.
-
-## 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.
-
-<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
deleted file mode 100644
index c0f42444..00000000
--- a/content/course/multi-chain-architecture/07-permissioning-validators/02-private-blockchains.mdx
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Private Blockchains
-description: Learn about different ways of permissioning your Avalanche L1 blockchain.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: BookOpen
----
-
-On a public blockchain, every transaction and change to the blockchain's state is visible to all. Anyone with internet access can see the transaction data. Block Explorers are one way to conveniently access the data on a chain. Although the identities of participants are often pseudonymous, the transaction data itself is open for anyone to see.
-
-However, there are many instances, especially in business or enterprise settings, where such transparency isn't desirable. A company might be conducting a high-value transaction that it doesn't want competitors or others in the market to see. There might also be legal or regulatory reasons for needing to keep transaction data private.
-
-In a private, permissioned blockchain, the visibility of transactions is limited to a select group of individuals or entities. This way, sensitive data isn't exposed. Only those who have been granted the necessary permissions can view the transaction data, and these permissions can be tightly controlled and monitored by network administrators.
-
-Further, transactions in a private blockchain can be encrypted, adding an extra layer of security. Even within the network, details about specific transactions can be hidden from certain participants, based on their level of permission. This allows for a much higher degree of confidentiality, as specific data can be revealed only on a need-to-know basis.
-
-In summary, privacy in the context of private, permissioned blockchains isn't just about restricting who can join. It's about having granular control over who can see what data, and when. It's about providing a secure, confidential environment where sensitive transactions can occur without the risk of exposure to unintended parties.
-
-This has made private, permissioned blockchains an attractive option for businesses and organizations dealing with sensitive data, high-value transactions, or strict confidentiality requirements.
-
-## Private Blockchains
-
-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.
-
-<Quiz quizId="409"/>
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/07-permissioning-validators/03-case-study-intain-markets.mdx b/content/course/multi-chain-architecture/07-permissioning-validators/03-case-study-intain-markets.mdx
deleted file mode 100644
index 550a6ec2..00000000
--- a/content/course/multi-chain-architecture/07-permissioning-validators/03-case-study-intain-markets.mdx
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Intain Markets Case Study 
-description: Learn about Intain's permissioned Avalanche L1.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: Microscope
----
-
-Intain operates a structured finance platform. It has **IntainMARKETS**, a marketplace for tokenized asset-backed securities built as an Avalanche L1.
-
-The digital marketplace automates and integrates functions of key stakeholders in structured finance, including issuer, verification agent, underwriter, rating agency, servicer, trustee, and investor.
-
-Rather than replacing trust intermediaries, it integrates them onto a single platform  to enable digital issuance and investment with a complete on-chain workflow. All parties work together in a transparent but private environment.
-
-<YouTube id="gNhmxIYj9ME" />
-
-## Permissioned Validators and Tokenomics
-
-The **IntainMARKETS L1** also uses other ways to adhere to regulatory requirements. It has U.S-hosted infrastructure, which allows data to reside domestically, while validators chosen by network participants must also be verified U.S. entities and individuals. The Avalanche L1 economics are not dependent on any public token, and transaction costs are independent from those of the Avalanche C-Chain and other Avalanche L1s.
-
-Further Readings: [Intain Launch Announcement](https://medium.com/avalancheavax/intain-launches-avalanche-subnet-to-usher-in-new-era-for-multi-trillion-dollar-securitized-877c7cc1031f)
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/07-permissioning-validators/04-elastic-subnets.mdx b/content/course/multi-chain-architecture/07-permissioning-validators/04-elastic-subnets.mdx
deleted file mode 100644
index 215ad88b..00000000
--- a/content/course/multi-chain-architecture/07-permissioning-validators/04-elastic-subnets.mdx
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Elastic Avalanche L1s
-description: Learn about Avalanche Elastic Avalanche L1s.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: BookOpen
----
-
-The Elastic Avalanche L1s feature empowers Avalanche L1 creators with an unprecedented ability: activating Proof-of-Stake validation and uptime-based rewards using their own tokens on their own Avalanche L1. For the first time, anyone can become a validator of an Avalanche L1 by simply staking its token on the Platform Chain, or P-Chain.
-
-When an Avalanche L1 enables Elastic Validation, it undergoes a one-time transformation, resulting in an Elastic Avalanche L1. Here's the catch - this process locks the Avalanche L1 from future modifications, and the creator relinquishes their control keys.
-
-To enable Elastic Validation, creators need to specify an Avalanche Native Token (ANT) that validators will stake and receive as rewards. They also have to establish a set of parameters to dictate the staking mechanics.
-
-Turning on Elastic Validation is purely optional and lies at the discretion of the creator. Creators who prefer to have more control over a Avalanche L1's validator set can retain the default configuration, which designates specific nodes as validators.
-
-You can use Avalanche Native Tokens from the X-Chain as stakeable tokens on Elastic Avalanche L1s or ERC-20s as ANTs, which can be used as stakeable and rewardable assets on Elastic Avalanche L1s.
-
-Avalanche L1 creators can remove a validator before the end of its staking period. If the Avalanche L1 is already Elastic, an Avalanche L1 creator can also remove validators added before token-based staking was enabled.
-
-These features give creators more control and options for configuring their Avalanche L1s, providing a more versatile and dynamic blockchain ecosystem. 
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/08-customizability/00-intro.mdx b/content/course/multi-chain-architecture/08-customizability/00-intro.mdx
deleted file mode 100644
index cdb5d4d0..00000000
--- a/content/course/multi-chain-architecture/08-customizability/00-intro.mdx
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Introduction to VM Customization
-description: Learn about customizing Virtual Machines.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Book
----
-
-For some use cases, it may be necessary to use a customized VM instead of the EVM. This is the case if an application cannot be built on a regular EVM on the C-Chain, or if it would result in transaction fee costs too high to be economical for its users or creators.
-
-Depending on a builder's needs, Avalanche allows for different VM customizations:
-
-![](/course-images/avalanche-fundamentals/32.png)
-
-Customizing the EVM on the Ethereum network is difficult, requiring a wide consensus that the proposed change is mutually beneficial for all network participants. This can make customizations for unique use cases challenging, if not impossible. Additionally, Ethereum doesn't give users the option to add different chains. 
-
-In Avalanche, every Avalanche L1 has autonomy over their Virtual Machines. Their creators can customize VMs to fit their unique requirements. This is one of the biggest advantages of multi-chain systems. 
-
-In this section, we will see the three way to customize Virtual Machines at a high level. In later courses, we will dive deeper and learn how to actually customize each. 
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/08-customizability/01-configuration.mdx b/content/course/multi-chain-architecture/08-customizability/01-configuration.mdx
deleted file mode 100644
index ae36e837..00000000
--- a/content/course/multi-chain-architecture/08-customizability/01-configuration.mdx
+++ /dev/null
@@ -1,78 +0,0 @@
----
-title: VM Configuration
-description: Learn about customizing Virtual Machines.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-When building a VM, it is possible to define certain parameters that can change the behavior of the VM. In our soda dispenser analogy these may be the products and prices offered by the dispenser. We might want to have two dispenser blockchains that offer different products and prices. If the VM is built in a way that it has parameters for the products and prices, it can be easily reused for different use items.
-
-![](/course-images/avalanche-fundamentals/33.png)
-
-This is a massive advantage over one-chain-fits-all systems, where the parameters have to be a compromise between all network participants. In Avalanche it is possible to have different blockchain with the same VM, but different parameters. 
-
-Using VM Configuration we can easily create EVM-chains for different use cases such as trading an cheap gaming NFT or valuable Real estate on chain. These blockchains may differ in fees (low fees for cheap NFTs, high fees for valuable goods) and security levels (low security for cheap NFTs, high security for valuable goods). 
-
-Examples of the configurable parameters of the subnetEVM include:
-
-**trxAllowList:** Define a whitelist of accounts that restrict which account's transactions are accepted by the VM.
-
-**contractDeployerAllowlist:** Defined a whitelist of accounts that restricts which account can deploy contracts on the blockchain
-
-Using these parameters we VM can adapt the VM to our requirements without writing a single line of code. This is by far the easiest, but also least flexible way to customize a VM to one's requirements.
-
-```json
-{
-  "config": {
-    "chainId": 99999,
-    "homesteadBlock": 0,
-    "eip150Block": 0,
-    "eip150Hash": "0x2086799aeebeae135c246c65021c82b4e15a2c451340993aacfd2751886514f0",
-    "eip155Block": 0,
-    "eip158Block": 0,
-    "byzantiumBlock": 0,
-    "constantinopleBlock": 0,
-    "petersburgBlock": 0,
-    "istanbulBlock": 0,
-    "muirGlacierBlock": 0,
-    "subnetEVMTimestamp": 0,
-    "feeConfig": {
-      "gasLimit": 20000000,
-      "minBaseFee": 1000000000,
-      "targetGas": 100000000,
-      "baseFeeChangeDenominator": 48,
-      "minBlockGasCost": 0,
-      "maxBlockGasCost": 10000000,
-      "targetBlockRate": 2,
-      "blockGasCostStep": 500000
-    },
-    "contractDeployerAllowListConfig": {
-      "blockTimestamp": 0,
-      "adminAddresses": [
-        "0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC"
-      ]
-    }
-  },
-  "alloc": {
-    "8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC": {
-      "balance": "0x52B7D2DCC80CD2E4000000"
-    },
-    "0x0Fa8EA536Be85F32724D57A37758761B86416123": {
-      "balance": "0x52B7D2DCC80CD2E4000000"
-    }
-  },
-  "nonce": "0x0",
-  "timestamp": "0x0",
-  "extraData": "0x00",
-  "gasLimit": "0x1312D00",
-  "difficulty": "0x0",
-  "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
-  "coinbase": "0x0000000000000000000000000000000000000000",
-  "number": "0x0",
-  "gasUsed": "0x0",
-  "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000"
-}
-```
-
-You can find more examples of Genesis files [here](https://github.com/ava-labs/subnet-evm/tree/master/tests/precompile/genesis).
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/08-customizability/02-modification.mdx b/content/course/multi-chain-architecture/08-customizability/02-modification.mdx
deleted file mode 100644
index eecce253..00000000
--- a/content/course/multi-chain-architecture/08-customizability/02-modification.mdx
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: VM Modification
-description: Learn about modifying Virtual Machines.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-The next more powerful way to customize a VM is VM Modification. To meet our requirements, we can modify and extend our existing VM. In our soda dispenser analogy, we might want to customize our soda dispenser to accept card payments. Our current soda dispenser machine simply does not have this feature. Instead of reinventing the wheel and building a new dispenser with the new feature from the ground up, we simply extend the existing VM using a plugin.
-
-![](/course-images/avalanche-fundamentals/34.png)
-
-In Avalanche, creating modified VMs is straightforward. The subnetEVM for instance can be customized through the development of plugins as well as precompiles.
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/08-customizability/03-creation.mdx b/content/course/multi-chain-architecture/08-customizability/03-creation.mdx
deleted file mode 100644
index 73a2ba9b..00000000
--- a/content/course/multi-chain-architecture/08-customizability/03-creation.mdx
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title: VM Creation
-description: Learn about creating Virtual Machines.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: BookOpen
----
-
-For some use cases it might be necessary to create entirely new VMs. 
-
-In our analogy this would be the case if we require completely different features, let's say we want to build a car VM. There is simply no way we can configure or extend a soda dispenser to turn it into a car. Instead we have to build a new VM from ground up. These newly created VMs can cater to much more specialized use cases and therefore this enables completely new blockchain applications not possible before. 
-
-VM Creation is by far the most complex way, but also the most powerful way to customize a VM. It requires a deep understanding of the blockchain space and software development skill. There might be certain basic elements in most VMs, such as the notion of transaction, accounts and authentication. Therefore, Avalanche provides some SDKs, such as the HyperSDK, to make the creation of VMs in languages like Go and Rust easier. 
-
-When creating a VM, there are two very distinct design patterns, that greatly vary in their intended use case.
-
-## Special Purpose VMs
-
-Special Purpose VMs are highly optimized for a specific use case. The only allow a very limited set of operations closely knit to its use case. A popular example for this would be the VM of the Bitcoin blockchain. The operations are much more limited than the ones of the Ethereum Virtual Machines, hence it only allows transactions related to the transfer of BTC.
-
-## General Purpose
-
-General Purpose VMs introduce another layer - commonly know as Smart Contracts or Programs - that can be submitted to the VM and enable user of the chain to interact with these. This way it allows its users to introduce their own logic to the VM. The most common General Purpose VM is the Ethereum Virtual Machine (EVM). However, some Avalanche L1s creators might want to create a VM that utilizes another language, such as Move, instead of Solidity as it’s smart contract language.
-
-![](/course-images/avalanche-fundamentals/35.png)
-
-One of the EVM's key features is its capability to execution of smart contracts in a deterministic and trustless manner, ensuring that the outcome of their execution is predictable and verifiable by all network participants. Developers can create decentralized applications and deploy them on the Ethereum blockchain. 
-
-This enables a wide range of use cases including decentralized finance (DeFi), tokenization, supply chain management, and more. The EVM's flexibility, security, and compatibility have made it a fundamental component of the Ethereum ecosystem, powering a vibrant and rapidly evolving ecosystem of decentralized applications and services.
\ No newline at end of file
diff --git a/content/course/multi-chain-architecture/certificate.mdx b/content/course/multi-chain-architecture/certificate.mdx
deleted file mode 100644
index bfeb6036..00000000
--- a/content/course/multi-chain-architecture/certificate.mdx
+++ /dev/null
@@ -1,14 +0,0 @@
----
-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/index.mdx b/content/course/multi-chain-architecture/index.mdx
deleted file mode 100644
index 16127c01..00000000
--- a/content/course/multi-chain-architecture/index.mdx
+++ /dev/null
@@ -1,34 +0,0 @@
----
-title: Welcome to the Course
-description: Learn about the Multi-Chain Architecture.
-updated: 2024-06-28
-authors: [usmaneth]
-icon: Smile
----
-
-Are you ready to dive deeper into the fascinating world of Avalanche? This course will equip you with a comprehensive understanding of the Avalanche's Multi Blockchain architecture, along with the practical skills required to create and manage custom blockchains.
-
-Ideal for people familiar with the basics of Avalanche, this course will unlock the potential of creating custom blockchains. We will explore the various components and key concepts of the Custom Blockchain architecture, empowering you to fully leverage its benefits.
-
-Throughout this course, you will gain hands-on experience by utilizing the Avalanche Command Line Interface (Avalanche CLI) to create your own custom blockchains and run them locally. You will explore different variations and configurations to learn the versatility and advantages of custom blockchains. Additionally, you will interact with the local instances using the Core Wallet, further enhancing your practical skills.
-
-Let's get started exploring the power of Avalanche Custom Blockchains.
-
-## Presentation
-
-Below you can find a recording of a presentation about the Multi-Chain Architecture of Avalanche.
-
-<YouTube id="Yy7_ZiBWXWQ"/>
-
-## Prerequisites
-
-This course is for people who understand the Avalanche basics. If you are not familiar with Avalanche Consensus, Virtual Machines, blockchains in Avalanche, or Avalanche Custom Blockchains, we strongly recommend taking our [Avalanche Fundamentals](/course/avalanche-fundamentals) course first.
-
-## Learning Outcomes
-
-In this course you will learn:
-
-- The benefits of Avalanche Custom Blockchains
-- How to use Avalanche CLI to create and run custom blockchains locally
-- How to interact with Avalanche L1s using Core Wallet
-
diff --git a/content/course/multi-chain-architecture/meta.json b/content/course/multi-chain-architecture/meta.json
deleted file mode 100644
index de559ed4..00000000
--- a/content/course/multi-chain-architecture/meta.json
+++ /dev/null
@@ -1,23 +0,0 @@
-{
-  "title": "subnet-architecture",
-  "root": true,
-  "pages": [
-    "index",
-    "---Custom Blockchains---",
-    "...02-custom-blockchains",
-    "---Avalanche Starter Kit---",
-    "...03-avalanche-starter-kit",
-    "---Independent Tokenomics---",
-    "...04-independent-tokenomics",
-    "---Interoperability---",
-    "...05-interoperability",
-    "---Permissioning Users---",
-    "...06-permissioning-users",
-    "---Permissioning Validators---",
-    "...07-permissioning-validators",
-    "---Customizability---",
-    "...08-customizability",
-    "---Conclusion---",
-    "certificate"
-  ]
-}
diff --git a/content/course/teleporter-chainlink-vrf/index.mdx b/content/course/teleporter-chainlink-vrf/index.mdx
deleted file mode 100644
index 64b4c0db..00000000
--- a/content/course/teleporter-chainlink-vrf/index.mdx
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Welcome to the Course
-description: Learn about using Chainlink VRF with Avalanche Interchain Messaging.
-updated: 2024-05-31
-authors: [ashucoder9]
-icon: Smile
----
-
-Welcome to the ...
-
-## Prerequisites
-
-TBD
-
-## Learning Outcomes
-
-By the end of this course, you will:
-
-- ...
-
-You can evaluate your own understanding of the material through quizzes and claim a certificate for successful completion at the end.
\ No newline at end of file
diff --git a/content/course/teleporter-chainlink-vrf/meta.json b/content/course/teleporter-chainlink-vrf/meta.json
deleted file mode 100644
index 728a2157..00000000
--- a/content/course/teleporter-chainlink-vrf/meta.json
+++ /dev/null
@@ -1,8 +0,0 @@
-{
-  "title": "avalanche-fundamentals",
-  "root": true,
-  "pages": [
-    "index",
-    "---Chainlink VRF with ---"
-  ]
-}
diff --git a/content/courses.tsx b/content/courses.tsx
deleted file mode 100644
index 23b0bc7f..00000000
--- a/content/courses.tsx
+++ /dev/null
@@ -1,166 +0,0 @@
-
-import { ArrowLeftRight, Coins, MailIcon, SquareCode, SquareIcon, SquareStackIcon, TerminalIcon, Triangle, HexagonIcon } from 'lucide-react';
-
-export type Course = {
-    name: string;
-    description: string;
-    slug: string;
-    icon: any;
-    status: "featured" | "normal" | "hidden";
-    duration?: string;
-    languages: string[];
-    tools: string[];
-    instructors: string[];
-};
-
-const officialCourses: Course[] = [
-    {
-        name: "Blockchain Fundamentals",
-        description: "Gain a comprehensive understanding of fundamental blockchain concepts, including how they work, and key components",
-        slug: "blockchain-fundamentals",
-        icon: <SquareIcon />,
-        status: "normal",
-        duration: "1 hour",
-        languages: [],
-        tools: [],
-        instructors: ["Martin Eckardt", "Ash"]
-    },
-    {
-        name: "Avalanche Fundamentals",
-        description: "Get a high level overview of Avalanche Consensus, L1s and VMs",
-        slug: "avalanche-fundamentals",
-        icon: <Triangle />,
-        status: "featured",
-        duration: "1 hour",
-        languages: [],
-        tools: ["AvaCloud"],
-        instructors: ["Martin Eckardt", "Ash"]
-    },
-    {
-        name: "Multi-Chain Architecture",
-        description: "Dive deeper into the Multi-Chain Architecture and deploy your own Blockchain",
-        slug: "multi-chain-architecture",
-        icon: <SquareStackIcon />,
-        status: "featured",
-        duration: "1.5 hours",
-        languages: [],
-        tools: ["Avalanche-CLI"],
-        instructors: ["Martin Eckardt", "Ash", "Owen Wahlgren"] // + Usman
-    },
-    {
-        name:"Avalanche Interchain Messaging",
-        description:"Utilize Avalanche Interchain Messaging to build cross-chain dApps in the Avalanche network",
-        slug:"interchain-messaging",
-        icon: <MailIcon />,
-        status: "featured",
-        duration: "3 hours",
-        tools: ["Avalanche-CLI"],
-        languages: ["Solidity"],
-        instructors: ["Martin Eckardt", "Andrea Vargas", "Ash"] // + Usman
-    },
-    {
-        name:"Interchain Token Transfer",
-        description:"Deploy Avalanche Interchain Token Transfer to transfer assets between Avalanche blockchains",
-        slug:"interchain-token-transfer",
-        icon: <ArrowLeftRight />,
-        status: "featured",
-        duration: "2.5 hours",
-        tools: ["ICM", "Foundry"],
-        languages: ["Solidity"],
-        instructors: ["Martin Eckardt", "Andrea Vargas", "Ash", "Owen Wahlgren", "Sarp"]
-    },
-    {
-        name:"Customizing the EVM",
-        description:"Learn how to customize the EVM and add your own custom precompiles",
-        slug:"customizing-evm",
-        icon: <SquareCode />,
-        duration: "4 hours",
-        status: "featured",
-        tools: ["Avalanche-CLI"],
-        languages: ["Go"],
-        instructors: ["Martin Eckardt", "Ash"] // + Usman
-    },
-    {
-       name:"Layer 1 Tokenomics",
-       description:"Learn how to design and deploy tokenomics for your Avalanche L1",
-       slug:"l1-tokenomics",
-       icon: <Coins />,
-       duration: "2 hours",
-       status: "featured",
-       tools: ["Avalanche-CLI", "ICM"],
-       languages: ["Solidity"],
-       instructors: ["Sarp", "Owen Wahlgren"]
-   },
-   {
-        name:"AvaCloud APIs",
-        description:"Learn how to leverage AvaCloud APIs to build web apps on Avalanche",
-        slug:"avacloudapis",
-        icon: <SquareCode />,
-        duration: "1 hour",
-        status: "featured",
-        tools: ["AvaCloudSDK", "AvaCloud API"],
-        languages: ["Typescript"],
-        instructors: ["Owen Wahlgren"]
-    },
-    {
-        name:"HyperSDK",
-        description:"Learn how to build a high-performance blockchain using HyperSDK",
-        slug:"hypersdk",
-        icon: <TerminalIcon />,
-        duration: "1 hour",
-        status: "hidden",
-        tools: ["HyperSDK"],
-        languages: ["Go", "Typescript"],
-        instructors: ["Aaron Buchwald", "Ilya", "Rodrigo Villar", "Martin Eckardt", "Owen Wahlgren"]
-    },
-    {
-        name:"Chainlink on your L1 via ICM",
-        description:"Utilize Interchain Messaging to make Chainlink services available on any blockchain in the Avalanche Network",
-        slug:"icm-chainlink",
-        icon: <HexagonIcon />,
-        status: "featured",
-        duration: "2.5 hours",
-        tools: ["ICM", "Chainlink VRF"],
-        languages: ["Solidity"],
-        instructors: ["Martin Eckardt", "Andrea Vargas", "Ash"]
-    }
-    /*,
-    {
-        name:"HyperSDK",
-        description:"Learn to build customized Virtual Machines using our SDK",
-        slug:"hypersdk",
-        icon: Blocks,
-        duration: "4 hours",
-        tools: ["Avalanche-CLI"],
-        languages: ["Go"]
-     },*/
-];
-
-const ecosystemCourses: Course[] = [
-    /*{
-        name:"Run a Gogopool Minipool",
-        description:"A Minipool represents a validator that is jointly funded equally by AVAX borrowed from liquid stakers and AVAX contribution from the minipool operator. Thanks to Minipool design architecture, users can become validators on the Avalanche network with nearly half the usual AVAX requirement.",
-        slug:"gogopool-minipool",
-        icon: Blocks,
-        duration: "2 hours",
-        tools: ["Avalanche-CLI"],
-        languages: ["Go"]
-   },
-   {
-        name:"Use Safe on an Avalanche Chain",
-        description:"Secure your multi-sig wallet with Safe on a Avalanche L1.",
-        slug:"safe-on-an-avalanche-chain",
-        icon: Blocks,
-        duration: "4 hours",
-        tools: ["Avalanche-CLI"],
-        languages: ["Go"]
-   }*/
-];
-
-export default {
-    official: officialCourses.filter((course) =>  ["normal", "featured"].includes(course.status)),
-    official_featured: officialCourses.filter((course) => course.status === "featured"),
-    ecosystem: ecosystemCourses,
-};
-
-
diff --git a/content/guide/deploy-a-dapp-on-c-chain-with-foundry.mdx b/content/guide/deploy-a-dapp-on-c-chain-with-foundry.mdx
deleted file mode 100644
index 7f5baea0..00000000
--- a/content/guide/deploy-a-dapp-on-c-chain-with-foundry.mdx
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: Deploy a DApp on the C-Chain with Foundry
-description: This guide shows how to deploy and interact with smart contracts using foundry on a local Avalanche Network and the Fuji C-Chain.
-date: 2024-05-26
-authors: [ashngmi, martin_eckardt]
-topics: [solidity, foundry, Avalanche Starter Kit]
----
-
-Foundry toolchain is a smart contract development toolchain written in Rust. It manages your dependencies, compiles your project, runs tests, deploys, and lets you interact with the chain from the command-line.
-
-# Recommended Knowledge
-
-- Basic understanding of Solidity and Avalanche.
-- You are familiar with Avalanche Smart Contract Quickstart.
-- Basic understanding of the Avalanche's architecture
-
-# Run Avalanche Starter Kit
-
-import SetUp from "@/content/common/avalanche-starter-kit/set-up.mdx";
-
-<SetUp />
-
-# Create a Smart Contract
-
-Create a new Solidity file in the `src` directory of your project. For example, `src/MyContract.sol`.
-
-```solidity
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.0;
-
-contract MyContract {
-    uint256 public myNumber;
-
-    function setNumber(uint256 _num) public {
-        myNumber = _num;
-    }
-}
-```
-
-# Create Deployment Address
-
-You can create a new wallet with the case command:
-
-```bash
-cast wallet new
-```
-
-# Fund Your Account
-
-Go the the faucet and fund the address with Fuji AVAX. You can use the code `avalanche-academy`:
-
-[Avalanche Testnet Faucet](https://core.app/tools/testnet-faucet/?subnet=c&token=c)
-
-# Deploy the Smart Contract
-
-With foundry's `forge` command, you can deploy your smart contract to the Fuji C-Chain.
-
-```shell
-forge create --rpc-url fuji-c --private-key <private-key> src/MyContract.sol:MyContract
-```
-
diff --git a/content/guide/etna-changes.mdx b/content/guide/etna-changes.mdx
deleted file mode 100644
index eda400ba..00000000
--- a/content/guide/etna-changes.mdx
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: What to Expect After the Etna Upgrade
-description: This guide outlines the operational impact on existing network participants expected from the activation of the AvalancheGo "Etna" upgrade.
-date: 2024-08-23
-authors: [meagfitzgerald]
-topics: [Avalanche Network Upgrade, Etna Upgrade, Validators, Layer 1, L1]
-comments: true
----
-
-This guide outlines the operational impact on existing network participants expected from the activation of the AvalancheGo "Etna" upgrade.
-
-## Vocabulary, New and Old
-
-- **L1**: An Avalanche Layer 1 Network. An L1 is a sovereign network that has its own dynamic set of validators, rules for network participation, and defines its own validator rewards incentives.
-- **L1-validator**: A validator that only validates an Avalanche layer 1 blockchain. These validators are not required to stake 2000 AVAX, or validate the Avalanche Primary Network. They instead pay a continuous fee in order to participate in L1 validation.
-- **ACP-77**: The Avalanche Community Proposal that outlines a new framework for creating low-cost, independent blockchains that can _easily_ interoperate with each other. You can read the full proposal [here](https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/77-reinventing-subnets/README.md).
-- **The Primary Network**: The Avalanche X,P, and C-Chains, a.k.a. the 3 primary blockchains that most validators currently sync on Avalanche Mainnet.
-
-## What is Changing?
-
-### Subnets Are Now Called L1s
-
-Avalanche Subnets are being rebranded as Avalanche L1s. Unlike layer 2 blockchains, layer 1 blockchains operate independently without relying on other systems for their core functions.
-They manage their own consensus mechanisms, transaction processing, and security protocols directly within their own networks.
-
-Subnets have always operated this way, scaling Avalanche's network _horizontally_ instead of compounding dependencies by requiring chains to roll down to other networks.
-
-### For Validators
-
-L1 validators will no longer be required to sync the Primary Network’s X or C-Chain, drastically reducing the cost of operating a validator.
-
-L1 validators will no longer be required to stake 2000 AVAX. Instead they will pay a substantially cheaper continuous fee calculated based on the number of L1 validators. The AVAX-denominated fee is a nominal amount per second and provides significant cost-savings for L1 validators.
-
-### For New L1s
-
-The ownership of validator set management will be moved from the P-Chain to individual L1 _ValidatorManager_ smart contracts.
-
-- Essentially, validators will be managed by the L1s themselves instead of the P-Chain.
-
-Sovereign L1s can easily be launched on Avalanche with a dynamic set of validators whose staking logic is defined and enforced by a _ValidatorManager_ smart contract deployed by the L1 creator. The smart contract deployed can enforce any network rules the creator desires, including but not limited to:
-
-- A permissionless proof-of-stake blockchain where network participation is not controlled by any centralized authority
-- A permissioned proof-of-authority blockchain where the validator set is controlled by a consortium or centralized authority
-
-If the L1 is permissionless, the validator earns staking rewards by staking the asset specified by the L1; If the L1 is permissioned, the validator is controlled by a party specified by the L1 Owner and does not earn any rewards.
-
-### For Existing L1s
-
-Existing Avalanche Subnets _that wish_ to remove the 2000 AVAX per validator requirement will need to convert their Subnet’s control from a _P-Chain Owner Key_ to a _ValidatorManager_ smart contract via the workflow outlined in ACP-77.
-
-- A detailed guide on how to convert existing L1s will be released prior to Testnet activation.
-
-Existing L1s do not need to be converted if their validators continue to stake 2000 AVAX and validate the Primary Network.
-
-## What is Staying the Same?
-
-### For Validators
-
-If you want to earn staking rewards for validating the Avalanche Primary Network, you will still need to stake 2000 AVAX per validator.
-
-Existing validators can continue operating as they have before, and do not require any action. Updating to the latest release of AvalancheGo will not affect their operation.
-
-### For L1s
-
-Existing Avalanche L1s are not required to convert their pre-Etna validators to L1-only-validators; they will continue to operate as before.
-
-All L1s will still be able to interoperate using Avalanche Warp Messaging (Avalanche ICM) and Teleporter (Avalanche ICM Contracts), regardless of how or when they were created.
-
-## What Technical Changes Will be Included?
-
-While driven by ACP-77, this upgrade will include many other feature additions outlined thoroughly in the following Avalanche Community Protocols:
-
-**[ACP-77](https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/77-reinventing-subnets/README.md)**: Outlines a new validator management framework for Avalanche L1s, creating low-cost, natively-interoperable blockchains.
-
-**[ACP-103](https://github.com/avalanche-foundation/ACPs/pull/103)**: Introduces a dynamic fee mechanism to the X-Chain and the P-Chain, previewing a future transition to a multidimensional fee mechanism.
-
-**[ACP-118](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/118-warp-signature-request)**: Proposes a standard `AppRequest` payload format type, simplifying potential AWM signature aggregation implementations.
-
-**[ACP-125](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/125-basefee-reduction)**: Reduces the minimum base fee on the Avalanche C-Chain from 25 nAVAX to 1 nAVAX.
-
-**[ACP-131](https://github.com/avalanche-foundation/ACPs/pull/131)**: Brings the EVM opcodes introduced by the Cancun Upgrade to the Avalanche C-Chain and Subnet-EVM.
diff --git a/content/guide/etna-upgrade-motivation.mdx b/content/guide/etna-upgrade-motivation.mdx
deleted file mode 100644
index a4818aee..00000000
--- a/content/guide/etna-upgrade-motivation.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Motivation behind Avalanche9000 
-description: Learn about the largest network upgrade of Avalanche, that will lower the barrier to launch a blockchain and enable permissionless validation of L1s.
-date: 2024-08-15
-authors: [martin_eckardt, owenwahlgren]
-topics: [Avalanche]
----
-
-import EtnaUpgradeMotivation from '@/content/common/multi-chain-architecture/etna-upgrade-motivation.mdx';
-
-<EtnaUpgradeMotivation />
diff --git a/content/guide/install-avalanche-cli.mdx b/content/guide/install-avalanche-cli.mdx
deleted file mode 100644
index 0f484563..00000000
--- a/content/guide/install-avalanche-cli.mdx
+++ /dev/null
@@ -1,60 +0,0 @@
----
-title: Install Avalanche CLI
-description: Avalanche CLI is a command line tool for accessing Avalanche, specializing in developing and testing subnets.
-date: 2024-05-26
-authors: [martin_eckardt]
-topics: [Avalanche CLI]
----
-
-Avalanche CLI is a command line tool that gives developers access to everything Avalanche. This release specializes in helping developers develop and test subnets. This guide shows you how to install Avalanche CLI on your machine.
-
-## Compatibility
-
-Avalanche-CLI runs on Linux and Mac. Windows is currently not supported.
-
-## Instructions
-
-To download a binary for the latest release, run:
-
-```shell
-curl -sSfL https://raw.githubusercontent.com/ava-labs/avalanche-cli/main/scripts/install.sh | sh -s
-```
-
-The script installs the binary inside the `~/bin` directory. If the directory doesn't exist,
-it will be created.
-
-## Adding Avalanche-CLI to Your PATH
-
-To call the `avalanche` binary from anywhere, you'll need to add it to your system path. If you installed
-the binary into the default location, you can run the following snippet to add it to your path.
-
-```shell
-export PATH=~/bin:$PATH
-```
-
-To add it to your path permanently, add an export command to your shell initialization script. If
-you run `bash`, use `.bashrc`. If you run `zsh`, use `.zshrc`.
-
-For example:
-
-```shell
-export PATH=~/bin:$PATH >> .bashrc
-```
-
-## Checking Your Installation
-
-You can test your installation by running `avalanche --version`. The tool should print the running version.
-
-## Updating
-
-To update your installation, you need to delete your current binary and download the latest version
-using the preceding steps.
-
-## Building from Source
-
-The source code is available in this [GitHub repository](https://github.com/ava-labs/avalanche-cli).
-
-After you've cloned the repository, checkout the tag you'd like to run. You can compile the code by
-running `./scripts/build.sh` from the top level directory.
-
-The build script names the binary `./bin/avalanche`.
\ No newline at end of file
diff --git a/content/guide/l1-economics.mdx b/content/guide/l1-economics.mdx
deleted file mode 100644
index 6972e919..00000000
--- a/content/guide/l1-economics.mdx
+++ /dev/null
@@ -1,49 +0,0 @@
----
-title: "Economics of L1 Blockchains: Deploying on Public Permissionless Chains vs. Your Custom L1 Blockchain"
-description: Discover the economic factors that influence the decision to deploy blockchain applications on public permissionless blockchains like Ethereum versus creating your own custom Layer 1 (L1) blockchain on Avalanche. This article explores the impact of transaction fees, validator incentives, and decentralization models, offering insights for developers to determine when launching a dedicated L1 makes sense. Ideal for developers and blockchain enthusiasts looking to optimize cost efficiency and user experience in decentralized applications.
-date: 2024-08-30
-authors: [martin_eckardt]
-topics: [L1, Tokenomics]
-comments: true
----
-
-When considering the deployment of a blockchain application, developers often face a critical decision: Should the application be launched on an existing public permissionless blockchain like Ethereum, or should it operate on a specialized Layer 1 (L1) blockchain? The answer to this question depends on various factors, with transaction fees being among the most significant. Understanding the economic implications of each option is essential for making an informed choice that aligns with your project's goals and long-term success.
-
-## Understanding Transaction Fees on Public Permissionless Blockchains
-
-Public permissionless blockchains like Ethereum or Avalanche's C-Chain have an inherent structure where users pay transaction fees — commonly known as gas fees — in a token that holds real value (e.g., ETH or AVAX). These fees compensate the network validators for securing and processing transactions on the blockchain. The fee is determined by supply and demand dynamics, with users bidding on the limited block space available to include their transactions.
-
-The challenge with this model is that gas fees can fluctuate wildly based on network activity. During periods of high demand—such as NFT drops, DeFi protocol launches, or bull markets—transaction fees can spike to levels that deter users from interacting with your application. For applications with many low-value transactions, these high fees can become prohibitive, leading to decreased user adoption and engagement. This is particularly problematic if your users are not even aware that they are interacting with a blockchain, as is often the case with mainstream applications.
-
-To mitigate this, developers might implement gas sponsoring and account abstraction, where the application absorbs the cost of the transaction fees. However, this introduces a continuous cost for every interaction, which can become unsustainable, especially if the underlying asset's value (e.g., AVAX) increases significantly. For instance, if AVAX appreciates from $20 to $60, your gas sponsoring costs could triple, drastically altering your application’s economics.
-
-## The Case for Launching a Custom L1 Blockchain
-
-When considering the deployment of a blockchain application, the option to spin up your own L1 blockchain on Avalanche offers a compelling alternative. With your own L1, you have complete control over the transaction fee structure. This flexibility is invaluable, especially for applications with a high volume of low-value transactions. By setting transaction fees according to your specific economic model, you can ensure that fees remain low, predictable, and aligned with your users' needs.
-
-For example, in a gaming application where users frequently make micro-transactions, high transaction fees on a public blockchain could be a significant barrier to user retention. By deploying your own L1, you can minimize or even eliminate these fees, thereby enhancing the user experience and driving higher engagement. This is particularly relevant for applications that target mainstream audiences, where a seamless and cost-effective user experience is paramount.
-
-## Decentralization Considerations
-
-When launching your own L1, it's crucial to consider how you will secure and govern the network. Some use cases might opt for a Proof of Authority (PoA) model with a permissioned validator set, where validators are pre-approved and known entities. This approach offers a higher degree of control but at the expense of decentralization.
-
-On the other hand, if you choose a permissionless validator set using Proof of Stake (PoS), you need to ensure that your transaction fee structure sufficiently compensates the independent validators for their running costs and provides additional incentives. This is essential for maintaining a healthy and secure network, as validators need to be motivated to participate and uphold the integrity of the blockchain. Striking the right balance between validator incentives and user costs is key to the long-term success of your custom L1.
-
-## When Does a Custom L1 Make Sense?
-
-Deciding whether to deploy on a public blockchain or create your own L1 is ultimately about determining your breakeven point. Here are some key considerations:
-
-#### Transaction Volume and Value
-If your application processes a high volume of low-value transactions, a custom L1 may be more cost-effective in the long run. Conversely, if your application handles only a few high-value transactions, the cost savings may not justify the complexity of running a separate L1.
-  
-#### Fee Stability
-On a public blockchain, you are at the mercy of network-wide fee fluctuations. With a custom L1, you can ensure fee stability, which is crucial for budgeting and long-term planning.
-
-#### Infrastructure Costs
-The primary cost of running an L1 is the infrastructure required to support the validator set. Once you establish an appropriate number of validators based on your security requirements, the operational costs become mostly fixed. These costs are independent of the number and complexity of the transactions processed on your chain, providing predictable financial outlays as your application scales.
-
-## Conclusion
-
-Launching a blockchain application on a public permissionless blockchain or spinning up your own L1 on Avalanche is a decision that depends heavily on your application's transaction profile and economic model. If you anticipate high transaction volumes with low individual values, a custom L1 could offer significant economical advantages in terms of fee management and user adoption. However, for applications with fewer, high-value transactions, the convenience and existing infrastructure of a public blockchain might be more appropriate.
-
-Ultimately, the decision should be driven by a careful analysis of your transaction patterns, user experience goals, and the potential for fee volatility in public networks. By weighing these factors, you can make an informed decision that aligns with your application's long-term success.
\ No newline at end of file
diff --git a/content/guide/subnet-vs-l1-validators.mdx b/content/guide/subnet-vs-l1-validators.mdx
deleted file mode 100644
index b129d233..00000000
--- a/content/guide/subnet-vs-l1-validators.mdx
+++ /dev/null
@@ -1,57 +0,0 @@
----
-title: Subnet & L1 Validators, What's the Difference?
-description: This guide defines the difference between Subnet and L1 validators, differentiating the roles and responsibilities of each.
-date: 2024-12-04
-authors: [meagfitzgerald]
-topics: [Avalanche Network Upgrade, Etna Upgrade, Validators, Layer 1, L1, L1 Validators, Subnet Validators]
-comments: true
----
-
-The Etna Upgrade introduced L1s to the Avalanche network, providing an enhanced sovereign network design to the original Subnet model. 
-
-**L1 validators**, introduced with ACP-77, represent a departure from this model, enabling the creation of sovereign L1 networks with minimal dependency on the Primary Network. 
-Unlike Subnet validators, L1 validators do not stake AVAX but instead pay a dynamic monthly fee, initially set at approximately 1.3 AVAX. 
-They are exempt from validating the Primary Network, reducing their resource requirements and making L1 validation more accessible. 
-This approach fosters economic inclusivity and sovereignty, allowing developers to define custom validation logic via smart contracts and operate independent networks without staking the Primary Network.  
-
-## Primary Network Validators
-
-Primary Network validators are responsible for processing transactions, securing the network, and participating in consensus and governance decisions. They must stake a minimum of 2,000 AVAX and validate all three primary network chains: the X, P, and C-Chain. 
-These validators earn rewards in exchange for enhancing the security of the network. Their role is crucial for the seamless operation of the broader Avalanche ecosystem. 
-
-As far as it relates to ACP-77 and the Etna Upgrade, the requirements for Primary Network validation **are not changing** with the Etna Upgrade. 
-
-## Subnet Validators
-
-Subnet validators are essentially Primary Network validators with additional permissions. They must:
-
-- Stake 2,000 AVAX on the Primary Network
-- Specify an "end time" for their validation period
-- Sync and validate the Primary Network (X, P, and C-Chains)
-- Sync and validate a specific Subnet 
-
-For context, the creation of a Subnet involves issuing a `CreateSubnetTx` on the P-Chain, assigning an Owner Key to manage its validator set. 
-After this, the holder(s) of the Owner Key can add and remove validators from the Subnet's validator set using the P-Chain transactions `AddSubnetValidatorTx` and `RemoveSubnetValidatorTx`. 
-These transactions were created pre-Etna for Subnet management and are still valid post-Etna.
-
-## L1 Validators
-
-L1 validators are a new addition to the Avalanche ecosystem, introduced with ACP-77 and the Etna Upgrade. A Subnet can be converted 
-by the Owner to a sovereign L1 with `ConvertSubnetToL1Tx`, a new P-Chain transaction introduced in this upgrade. This transaction revokes the authority to add and remove Subnet validators from the original Owner Key, and sets the validator
-set management to the `address` specified. After a successful `ConvertSubnetToL1Tx`, `AddSubnetValidatorTx` is permanently disabled, and any validator set additions must be coordinated through a `RegisterL1ValidatorTx` (also introduced in ACP-77) which can only add **L1 validators**. 
-
-L1 validators are required to:
-- Pay a continuous dynamic fee, initially set at approximately 1.33 AVAX per month
-- Sync and validate a specific L1
-- Sync the latest P-Chain state
-
-Syncing the P-Chain state is required for basic L1 functionality. It enables the L1 to track its validator weights so that it can perform consensus and validate ICM messages from other L1s, including the P-Chain.
-
-L1 validators do not need to:
-- Stake 2,000 AVAX
-- Validate or participate in consensus on the Primary Network (X, P, and C-Chains)
-
-Unless removed by the Owner Key, any Subnet validator added to the network before `ConvertSubnetToL1Tx` will continue to validate the network until its "end time" is reached.
-
-Once a Subnet has been converted to an L1, Subnet validators can no longer be added. After a previous Subnet validator is removed or its "end time" is reached, a validator with
-the same NodeID can be re-added as an L1 validator to the network with `RegisterL1ValidatorTx`, the same as any other L1 validator who wishes to join the network.
diff --git a/content/guide/telegram-miniapps-thirdweb.mdx b/content/guide/telegram-miniapps-thirdweb.mdx
deleted file mode 100644
index 9ab1bc89..00000000
--- a/content/guide/telegram-miniapps-thirdweb.mdx
+++ /dev/null
@@ -1,200 +0,0 @@
----
-title: Create a Telegram Mini-App using ThirdWeb SDK
-description: This guide shows how to build a Telegram Mini-App using the ThirdWeb SDK on the Avalanche Fuji Network.
-date: 2024-09-04
-authors: [owenwahlgren]
-topics: [solidity, typescript, Telegram, ThirdWeb]
----
-import { Step, Steps } from 'fumadocs-ui/components/steps';
-
-Telegram Mini-Apps are a new way to build and deploy applications and games embedded in the Telegram platform. They are built using ThirdWeb, a platform that allows developers to connect and utilize both external and in-app wallets on the Avalanche network.
-
-Learn more about [ThirdWeb](https://thirdweb.com/).
-## Recommended Knowledge
-
-- Basic understanding of Solidity and Typescript.
-- Basic understanding of Telegram Bots and the Telegram API.
-- Basic understanding of the Avalanche Fuji Testnet.
-
-## Getting started
-
-<Steps>
-<Step>
-Create a template from the [ThirdWeb Telegram Mini-App Starter Kit](https://github.com/ava-labs/telegram-webapp-avalanche) by clicking the `Use this template` button on the top right.
-
-![](/guide-images/telegram-miniapp/use-template.png)
-
-**IMPORTANT!!** mark "Include all branches", otherwise Github pages deployment will not work.
-
-![](/guide-images/telegram-miniapp/include-branches.png)
-
-</Step>
-<Step>
-Clone the new repository & install the dependencies
-```bash
-git clone <new-repo-url>
-cd <new repo>
-yarn install
-```
-</Step>
-
-<Step>
-Get the `clientID` from a ThirdWeb account on the [ThirdWeb Dashboard](https://thirdweb.com/dashboard)
-</Step>
-
-<Step>
-Create a `.env` file in the root of the project and add the `clientID` from the previous step:
-```bash
-VITE_THIRDWEB_CLIENT_ID=...
-```
-</Step>
-
-<Step>
-Run the project in development mode
-```bash
-yarn dev
-```
-</Step>
-</Steps>
-
-On `git push` to the `main` branch, the project will be automatically deployed to Github Pages.
-
-Follow the section below to link a Telegram Bot to the webapp.
-
-## Integrating with Telegram Bots
-<Steps>
-<Step>
-Create a new Telegram Bot using [BotFather](https://t.me/botfather)
-<Steps>
-    <Step>
-    Type `/newbot`
-    </Step>
-    <Step>
-    Choose a name for the bot, e.g. `My Avalanche TWA`
-    </Step>
-    <Step>
-    Choose a username for the bot, e.g. `my_avalanche_twa_482765_bot`
-    </Step>
-    <Step>
-    Take note of the access token, e.g. `5712441624:AAHmiHvwrrju1F3h29rlVOZLRLnv-B8ZZZ`
-    </Step>
-    </Steps>
-</Step>
- <Step>
-    Run `yarn configbot` then follow the dialogue to link the Telegram bot with the webapp
-    </Step>
-</Steps>
-
-
-## Points of Interest
-
-
-<Accordions>
-<Accordion title="src/main.tsx">
-This is where the app is wrapped with the ThirdWeb provider
-```tsx
-ReactDOM.createRoot(document.getElementById("root") as HTMLElement).render(
-  <ThirdwebProvider>
-    <QueryClientProvider client={queryClient}>
-      <App />
-    </QueryClientProvider>
-  </ThirdwebProvider>
-);
-```
-</Accordion>
-<Accordion title="src/App.tsx">
-This is where the ThirdWeb SDK gets initialized with the `clientID` from the `.env` file and also defines the list of acceptable wallets / authorizations.
-```tsx
-export const client = createThirdwebClient({ clientId: import.meta.env.VITE_THIRDWEB_CLIENT_ID });
-
-const wallets = [
-  inAppWallet({
-    auth: {
-      options: [
-        "email",
-        "phone",
-      ],
-    },
-  }),
-  createWallet("app.core"),
-  createWallet("walletConnect")
-];
-```
-
-```tsx
-function App() {
-
-  return (
-    <StyledApp>
-      <AppContainer>
-        <FlexBoxCol>
-          <FlexBoxRow>
-            <ConnectButton client={client} wallets={wallets} chain={avalancheFuji} showAllWallets={false} />
-          </FlexBoxRow>
-          <TransferAvax />
-          <Counter />
-        </FlexBoxCol>
-      </AppContainer>
-    </StyledApp>
-  );
-}
-```
-
-</Accordion>
-<Accordion title="src/components/TransferAvax.tsx">
-The Thirdweb `TransferButton` component is used here to compose a new transfer of native tokens.
-```tsx
- <TransactionButton
-    transaction={() => {
-        const transaction = prepareTransaction({
-        to: avaxRecipient,
-        chain: avalancheFuji,
-        client: client,
-        value: toWei(avaxAmount),
-    });
-    return transaction;
-    }}
-    onTransactionConfirmed={() => { console.log("Transaction confirmed") }}
-    onError={() => { console.log("Transaction error") }}
-    >
-    Confirm Transaction
-</TransactionButton>
-
-```
-</Accordion>
-<Accordion title="src/components/Counter.tsx">
-The `TransferButton` component is used again here to facilitate contract interaction.
-```tsx
- <TransactionButton
-    transaction={() => {
-        const transaction = prepareContractCall({
-        contract,
-        method: "function increase()",
-        params: [],
-        });
-    return transaction;
-    }}
-    onTransactionConfirmed={() => { console.log("Transaction confirmed") }}
-    onError={() => { console.log("Transaction error") }}
-    >
-    Increase Count
-</TransactionButton>
-
-<TransactionButton
-    transaction={() => {
-        const transaction = prepareContractCall({
-        contract,
-        method: "function decrease()",
-        params: [],
-        });
-    return transaction;
-    }}
-    onTransactionConfirmed={() => { console.log("Transaction confirmed") }}
-    onError={() => { console.log("Transaction error") }}
-    >
-    Decrease Count
-</TransactionButton>
-```
-The hardcoded contract address is `0x7Ff5ca07a5FC4AA062c29E6E32d2691B48598577` which is a [simple counter contract deployed on Fuji.](https://testnet.snowtrace.io/address/0x7Ff5ca07a5FC4AA062c29E6E32d2691B48598577/contract/43113/code)
-</Accordion>
-</Accordions>
diff --git a/content/guide/use-privy-on-l1.mdx b/content/guide/use-privy-on-l1.mdx
deleted file mode 100644
index 2f441eb2..00000000
--- a/content/guide/use-privy-on-l1.mdx
+++ /dev/null
@@ -1,237 +0,0 @@
----
-title: Use Privy on Avalanche L1
-description: This guide shows how to use Social Login and Embedded Wallets with Privy on Avalanche L1.
-date: 2024-08-23
-authors: [satatocom]
-topics: [Avalanche L1, Avalanche Starter Kit, Magic Link, Social Login, Embedded Wallets]
----
-
-In this guide, you will learn how to use Privy to easily onboard your users and create transactions without the need for any Web3 wallet.
-
-## What is Privy?
-
-Privy is a simple tool to easily onboard all your users to web3, regardless of whether they already have a wallet, across mobile and desktop.
-
-## Terminology
-
-Before we dive into the guide, let's first understand the terminology.
-
-| Term | Meaning |
-| -------- | ------- |
-| Social Login | Social Login is a form of single sign-on (SSO) that allows users to log into a third-party website or app using their existing credentials from a social media platform, such as Google, X (formerly Twitter), or Apple. Instead of creating a new username and password, users can authenticate themselves through their social media accounts, streamlining the login process. |
-| Magic Link | A Magic Link is a form of passwordless authentication where users can log into an application or website by clicking a unique, time-sensitive link sent to their email address. This method eliminates the need for a traditional username and password combination, making the login process simpler and more user-friendly. |
-| Next.js  | Next.js’ Pages Router is a full-stack React framework. It’s versatile and lets you create React apps of any size—from a mostly static blog to a complex dynamic application. |
-
-## Prerequisites and Recommended Knowledge
-
-- Privy account
-- Basic understanding of EVM, and transaction data
-- Basic understanding of frontend development
-
-## Preparation
-
-### Create Application and Retrieve API Keys
-
-- Log in to [Privy Dashboard](https://dashboard.privy.io/)
-- Click on `New App` on the Applications page.
-- Click on the Settings button on the left pane. Under the Basic tab, you'll find the API keys.
-
-### Start a New React Project with Next.js
-
-To create a new Next.js project, run in your terminal:
-
-```bash
-npx create-next-app@latest
-```
-
-### Install Dependencies
-
-After the React project is created, we need to install some dependencies: to use Privy (its own package), to add a custom chain, to create and use an HTTP client (viem), and to include utilities (ethers).
-
-```bash
-npm install @privy-io/react-auth@latest
-npm i viem@latest
-npm i ethers@latest
-```
-
-### Define Your Avalanche L1
-
-In this guide, we are using the `Echo L1` as an example Avalanche L1. However, you can use any Avalanche L1 that has a public RPC URL. If the L1 has an explorer page, you can see better what is happening, but it is not required.
-
-```typescript
-export const echo = defineChain({
-  id: 173750,
-  name: 'Echo L1',
-  network: 'echo',
-  nativeCurrency: {
-    decimals: 18,
-    name: 'Ech',
-    symbol: 'ECH',
-  },
-  rpcUrls: {
-    default: {
-      http: ['https://subnets.avax.network/echo/testnet/rpc']
-    },
-  },
-  blockExplorers: {
-    default: {name: 'Explorer', url: 'https://subnets-test.avax.network/echo'},
-  },
-});
-```
-
-### Import Privy into Your App 
-
-After the React project is created, navigate to `page.tsx`. Inside the `Home` function, wrap your content with `PrivyProvider`.
-
-```typescript title="page.tsx"
-export default function Home() {
-
-  return (
-    <PrivyProvider
-      appId="your-privy-app-id"
-      config={{
-        appearance: {
-          theme: 'dark',
-          accentColor: '#e84242',
-          logo: 'https://your-logo-url',
-        },
-        embeddedWallets: {
-          createOnLogin: 'users-without-wallets',
-        },
-        defaultChain: echo,
-        supportedChains: [echo],
-        loginMethods: ['email', 'wallet', 'google', 'apple']
-      }}
-    >
-      { content }
-    </PrivyProvider>
-  );
-
-}
-```
-
-## Walkthrough
-
-So far in the guide, we have installed the necessary dependencies, created our Privy application, and obtained our API key. Now, we are ready to use Privy.
-
-Here is our walkthrough:
-
-- We will create a simple login flow.
-- We will create a welcome page for users who have logged in, showing their embedded wallet address and balance.
-- We will trigger a test transfer of the `ECH` token via Privy.
-
-### Login Flow
-
-To onboard your users into your application, you just need to know the following hooks:
-
-```typescript
-const { ready, authenticated } = usePrivy();
-const { login } = useLogin();
-```
-
-It's really that simple!
-
-- `ready`: Checks whether the `PrivyProvider` is `ready` to be used.
-- `authenticated`: Returns `true` if the user is `authenticated`, `false` otherwise.
-- `login`: Opens the Privy login modal and prompts the user to log in.
-
-```typescript
-<button onClick={login}>Login via Privy</button>
-```
-
-We've only added a button to trigger `login` function, and Privy handles the rest.
-
-![](/guide-images/use-privy-on-l1/1.png)
-
-When we click on the `Login via Privy` button, this modal appears.
-
-![](/guide-images/use-privy-on-l1/2.png)
-
-You can choose any login method to log in. We’ve already defined these options in the `PrivyProvider` when we wrapped our content.
-
-### Welcome Page
-
-After checking whether the user is authenticated or not, we display the following information to the user who has logged in.
-
-![](/guide-images/use-privy-on-l1/3.png)
-
-As you can see, Privy has generated an embedded wallet for our user. We’ve displayed the following properties on the screen: Privy ID, embedded wallet address, and embedded wallet balance.
-
-```typescript
-<span>{user.id}</span>
-<span>{user.wallet.address}</span>
-<span>{balance} ECH</span>
-```
-
-We’ve used the user object of Privy to retrieve the user ID and wallet address. To fetch the user’s balance, we need to create an HTTP client for our Avalanche L1, which we’ve already defined earlier.
-
-```typescript
-const client = createPublicClient({
-    chain: echo,
-    transport: http(),
-});
-// get native asset balance
-client.getBalance({
-    address: address,
-}).then(balance => {
-    setBalance(ethers.formatEther(balance));
-});
-```
-
-We can allow users to log out using the following hook:
-
-```typescript
-const { logout } = useLogout();
-```
-
-### Fund the New Wallet Using the Faucet
-
-We’ve funded the new wallet that was generated for our user with some ECH tokens from the [Echo AWM Testnet Faucet](https://test.core.app/tools/testnet-faucet/?subnet=echo&token=echo).
-
-![](/guide-images/use-privy-on-l1/4.png)
-
-After the ECH tokens were sent, our balance updated accordingly.
-
-![](/guide-images/use-privy-on-l1/5.png)
-
-### Send Test Transfer via Privy
-
-Now that we have a balance, we can send some ECH tokens to another recipient via Privy to test Privy's `sendTransaction` flow. Privy provides the following hook for this:
-
-```typescript
-const { sendTransaction } = useSendTransaction();
-```
-
-We’ve already added the following button to trigger the `transfer` function, which will, in turn, trigger the `sendTransaction` function provided by Privy.
-
-```typescript
-<button onClick={transfer}>Send Test Transfer via Privy</button>
-```
-
-We have built a simple transaction that sends some ECH tokens to another recipient.
-
-
-```typescript
-const transfer = () => {
-    if (authenticated === false || address === undefined) {
-        return;
-    }
-    let receiver = "0x..."; // receiver address
-    sendTransaction({
-        "value": ethers.parseUnits("0.01", "ether"),
-        "to": receiver, // destination address
-        "from": address, // logged in user's embedded wallet address
-    }).catch(() => {
-        // handle err 
-    });
-}
-```
-
-When we click on the `Send Test Transfer via Privy` button, this modal appears. Users can see the following details related to the transaction.
-
-![](/guide-images/use-privy-on-l1/6.png)
-![](/guide-images/use-privy-on-l1/7.png)
-
-## Conclusion
-
-What we achieved is the creation of a simple React project that integrates Privy. Our application can now easily onboard new users to our Web3 application without needing them to install a Web3 wallet extension, regardless of which chain they are on.
\ No newline at end of file
diff --git a/content/guide/what-is-a-blockchain.mdx b/content/guide/what-is-a-blockchain.mdx
deleted file mode 100644
index f23e7e38..00000000
--- a/content/guide/what-is-a-blockchain.mdx
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title: What is a blockchain?
-description: Learn how blockchains differ from centralized systems, their trade-offs, and the best use cases for their secure, transparent architecture.
-date: 2024-07-24
-authors: [martin_eckardt]
-topics: [Blockchain Basics]
----
-
-## Introduction to Different Types of Computers
-Computers are integral to our daily lives, and they come in various forms, each designed to serve specific purposes. Here's a quick overview:
-
-1. **Personal Computers (PCs)**: These are the desktops and laptops we use at home or work. They are versatile, powerful, and designed for individual use.
-2. **Cloud Computers**: These are powerful servers located in data centers around the world. They provide vast computational resources and storage, accessible via the internet. They are designed for scalability and can handle large-scale applications and data processing.
-3. **Mobile Computers**: These include smartphones and tablets. They are portable and offer the convenience of mobility, allowing us to perform computing tasks on the go.
-
-All these computers are *centralized*. This means they are controlled by a single entity or organization. For example, your PC is controlled by you, cloud computers are managed by cloud service providers, and mobile devices are typically controlled by their manufacturers and network providers. Centralization implies that these entities have the power to manage, restrict access to, or shut down these computers if needed.
-
-## Introducing the Blockchain Computer
-A **blockchain** is a new kind of computer with a unique and defining property: **decentralization**. Unlike traditional centralized computers controlled by a single entity, a blockchain operates without any central authority. This means no single entity can:
-
-- Turn it off
-- Restrict access to it
-- Interfere with the execution of the programs running on it
-
-Furthermore, the computation is transparent. Anyone can see the programs running on the blockchain and verify their correctness. This transparency ensures that the blockchain operates fairly and securely.
-
-## How Decentralization Works
-Decentralization in blockchain is achieved through a network of **validators**. These are independent entities that run the blockchain software, perform computations, and ensure the integrity of the blockchain. Here’s how it works:
-
-1. **Computation Execution**: Each validator independently performs the same computation. For example, let's consider a simple computation: `5 + 3`.
-2. **Consensus Process**: After performing the computation, validators share their results with each other. They then use a process called **consensus** to agree on the correct result. You can think of it as a election, where all validators vote on the correct answer.
-
-The consensus process ensures that all validators reach an agreement on the correct result, given that the majority is honest. This agreement is crucial for maintaining the integrity and security of the blockchain. If a validator tries to cheat or provide an incorrect result, the other validators will detect the discrepancy, and the cheating validator will be penalized.
-
-## Efficiency of Blockchain Computation
-While the decentralized nature of blockchain ensures security and integrity, it also makes it **inefficient** compared to traditional computers. Here’s why:
-
-- **Redundant Computation**: Every validator must perform the same computation independently.
-- **Consensus Overhead**: Validators need to communicate and agree on the results, which adds extra steps and time.
-
-Due to the redundancy and additional processes, performing computations on a blockchain is much more expensive than on a PC or cloud computer. For instance, while a PC can perform a simple addition in a fraction of a second with minimal cost, a blockchain requires multiple validators to do the same computation and agree on the result, leading to higher computational costs and time.
-
-So, while it's decentralized nature offers significant advantages in terms of security and resistance to control, it also comes at the cost of efficiency and higher computation expenses. As we continue to develop and optimize blockchain technology, we aim to balance these trade-offs and explore its vast potential in various applications.
-
-## Use Cases for Blockchain
-
-Blockchain technology excels in use cases where decentralization, security, and transparency are paramount, making the trade-off for reduced efficiency worthwhile. 
-
--  In *financial services*, blockchain enables secure, transparent, and tamper-proof transactions without the need for intermediaries like banks. 
-- *Supply chain management* benefits from blockchain by providing an immutable ledger that tracks the provenance and movement of goods, enhancing traceability and reducing fraud. 
-- *Voting systems* can leverage blockchain to ensure the integrity and transparency of the electoral process, making it resistant to tampering and fraud. 
-
-However, for tasks that prioritize high efficiency and speed over decentralization, such as real-time data processing or complex computational tasks, traditional centralized systems are more suitable. In these cases, the overhead of consensus mechanisms and redundant computations in blockchain would introduce unnecessary latency and cost. Thus, the decision to use blockchain should be guided by the specific needs for security, transparency, and decentralization versus the demand for efficiency and speed.
\ No newline at end of file
diff --git a/mdx-components.tsx b/mdx-components.tsx
deleted file mode 100644
index bdea67f5..00000000
--- a/mdx-components.tsx
+++ /dev/null
@@ -1,61 +0,0 @@
-import type { MDXComponents } from 'mdx/types';
-import { Accordion, Accordions } from 'fumadocs-ui/components/accordion';
-import { Callout } from 'fumadocs-ui/components/callout';
-import { Tab, Tabs } from 'fumadocs-ui/components/tabs';
-import { TypeTable } from 'fumadocs-ui/components/type-table';
-import defaultComponents from 'fumadocs-ui/mdx';
-import {
-  CodeBlock,
-  type CodeBlockProps,
-  Pre,
-} from 'fumadocs-ui/components/codeblock';
-import type { ReactNode } from 'react';
-import Quiz from '@/components/quizzes/quiz'
-import { Popup, PopupContent, PopupTrigger } from 'fumadocs-ui/twoslash/popup';
-import YouTube from '@/components/youtube';
-import Gallery from '@/components/gallery';
-import { cn } from './utils/cn';
-import dynamic from "next/dynamic";
-
-
-const Mermaid = dynamic(() => import("@/components/mermaid"), {
-  ssr: false,
-});
-
-export function useMDXComponents(components: MDXComponents): MDXComponents {
-  return {
-    ...defaultComponents,
-    Popup,
-    Mermaid,
-    PopupContent,
-    PopupTrigger,
-    pre: ({ title, className, icon, allowCopy, ...props }: CodeBlockProps) => (
-      <CodeBlock title={title} icon={icon} allowCopy={allowCopy}>
-        <Pre className={cn('max-h-[1200px]', className)} {...props} />
-      </CodeBlock>
-    ),
-    Tabs,
-    Tab,
-    Callout,
-    TypeTable,
-    Accordion,
-    Accordions,
-    YouTube,
-    Gallery,
-    Quiz,
-    InstallTabs: ({
-      items,
-      children,
-    }: {
-      items: string[];
-      children: ReactNode;
-    }) => (
-      <Tabs items={items} id="package-manager">
-        {children}
-      </Tabs>
-    ),
-    blockquote: (props) => <Callout>{props.children}</Callout>,
-    ...components,
-  };
-}
-
diff --git a/next.config.mjs b/next.config.mjs
index 0804a65c..52fd0ae5 100644
--- a/next.config.mjs
+++ b/next.config.mjs
@@ -1,7 +1,3 @@
-import createMDX from 'fumadocs-mdx/config';
-
-const withMDX = createMDX();
-
 /** @type {import('next').NextConfig} */
 const config = {
   reactStrictMode: true,
@@ -42,4 +38,4 @@ const config = {
   },
 };
 
-export default withMDX(config);
+export default config;
diff --git a/package.json b/package.json
index 1a893938..a7a88e4a 100644
--- a/package.json
+++ b/package.json
@@ -5,40 +5,17 @@
   "scripts": {
     "build": "next build",
     "dev": "next dev",
-    "start": "next build && next start",
-    "check-links": "tsx .github/linkChecker.ts"
+    "start": "next build && next start"
   },
   "dependencies": {
-    "@headlessui/react": "^2.1.2",
-    "@heroicons/react": "^2.1.5",
-    "@icons-pack/react-simple-icons": "^10.0.0",
-    "@noble/bls12-381": "^1.4.0",
-    "@vercel/analytics": "^1.3.1",
-    "@vercel/speed-insights": "^1.0.12",
-    "fumadocs-core": "12.4.2",
-    "fumadocs-mdx": "8.2.33",
-    "fumadocs-ui": "12.4.2",
-    "geist": "^1.3.1",
-    "idb": "^8.0.0",
-    "lucide-react": "^0.408.0",
-    "mermaid": "^11.3.0",
     "next": "^14.2.12",
-    "pdf-lib": "^1.17.1",
-    "posthog-js": "^1.166.1",
     "react": "^18.3.1",
-    "react-dom": "^18.3.1",
-    "tailwindcss-animate": "^1.0.7",
-    "uuid": "^10.0.0"
+    "react-dom": "^18.3.1"
   },
   "devDependencies": {
-    "@types/mdx": "^2.0.13",
     "@types/node": "20.14.10",
     "@types/react": "^18.3.3",
     "@types/react-dom": "^18.3.0",
-    "@types/uuid": "^10.0.0",
-    "autoprefixer": "^10.4.19",
-    "axios": "^1.7.7",
-    "cheerio": "^1.0.0",
     "postcss": "^8.4.39",
     "tailwindcss": "^3.4.4",
     "tsx": "^4.19.0",
diff --git a/postcss.config.js b/postcss.config.js
index 12a703d9..f0ea779a 100644
--- a/postcss.config.js
+++ b/postcss.config.js
@@ -1,6 +1,5 @@
 module.exports = {
   plugins: {
-    tailwindcss: {},
-    autoprefixer: {},
+    tailwindcss: {}
   },
 };
diff --git a/public/backup.png b/public/backup.png
deleted file mode 100644
index f8ac9956..00000000
Binary files a/public/backup.png and /dev/null differ
diff --git a/public/banner.png b/public/banner.png
deleted file mode 100644
index e5c30d8f..00000000
Binary files a/public/banner.png and /dev/null differ
diff --git a/public/certificates/AvalancheAcademy_Certificate.pdf b/public/certificates/AvalancheAcademy_Certificate.pdf
deleted file mode 100644
index 2e6f49b6..00000000
Binary files a/public/certificates/AvalancheAcademy_Certificate.pdf and /dev/null differ
diff --git a/public/common-images/avalanche-starter-kit/new-terminal.png b/public/common-images/avalanche-starter-kit/new-terminal.png
deleted file mode 100644
index d7994a50..00000000
Binary files a/public/common-images/avalanche-starter-kit/new-terminal.png and /dev/null differ
diff --git a/public/common-images/awm/relayer-delivery.png b/public/common-images/awm/relayer-delivery.png
deleted file mode 100644
index bf022e3d..00000000
Binary files a/public/common-images/awm/relayer-delivery.png and /dev/null differ
diff --git a/public/common-images/awm/relayer-pickup.png b/public/common-images/awm/relayer-pickup.png
deleted file mode 100644
index 8a1e7694..00000000
Binary files a/public/common-images/awm/relayer-pickup.png and /dev/null differ
diff --git a/public/common-images/blockchain-basics/blocks/ledger-blocks.png b/public/common-images/blockchain-basics/blocks/ledger-blocks.png
deleted file mode 100644
index 1ec038cb..00000000
Binary files a/public/common-images/blockchain-basics/blocks/ledger-blocks.png and /dev/null differ
diff --git a/public/common-images/blockchain-basics/blocks/ledger.png b/public/common-images/blockchain-basics/blocks/ledger.png
deleted file mode 100644
index c96db1b7..00000000
Binary files a/public/common-images/blockchain-basics/blocks/ledger.png and /dev/null differ
diff --git a/public/common-images/blockchain-basics/decentralized-computer/blockchain-computer.png b/public/common-images/blockchain-basics/decentralized-computer/blockchain-computer.png
deleted file mode 100644
index 9a08c8d6..00000000
Binary files a/public/common-images/blockchain-basics/decentralized-computer/blockchain-computer.png and /dev/null differ
diff --git a/public/common-images/blockchain-basics/decentralized-computer/decentralized-applications-connected.png b/public/common-images/blockchain-basics/decentralized-computer/decentralized-applications-connected.png
deleted file mode 100644
index af7d9380..00000000
Binary files a/public/common-images/blockchain-basics/decentralized-computer/decentralized-applications-connected.png and /dev/null differ
diff --git a/public/common-images/blockchain-basics/decentralized-computer/decentralized-applications.png b/public/common-images/blockchain-basics/decentralized-computer/decentralized-applications.png
deleted file mode 100644
index 04cb43cd..00000000
Binary files a/public/common-images/blockchain-basics/decentralized-computer/decentralized-applications.png and /dev/null differ
diff --git a/public/common-images/blockchain-basics/decentralized-computer/different-kinds-of-computer.png b/public/common-images/blockchain-basics/decentralized-computer/different-kinds-of-computer.png
deleted file mode 100644
index 1ef3b3e5..00000000
Binary files a/public/common-images/blockchain-basics/decentralized-computer/different-kinds-of-computer.png and /dev/null differ
diff --git a/public/common-images/blockchain-basics/payments/account-balances.png b/public/common-images/blockchain-basics/payments/account-balances.png
deleted file mode 100644
index 868e5c49..00000000
Binary files a/public/common-images/blockchain-basics/payments/account-balances.png and /dev/null differ
diff --git a/public/common-images/blockchain-basics/payments/ledger.png b/public/common-images/blockchain-basics/payments/ledger.png
deleted file mode 100644
index d7a0b7cf..00000000
Binary files a/public/common-images/blockchain-basics/payments/ledger.png and /dev/null differ
diff --git a/public/common-images/blockchain-basics/payments/transfer-invalid.png b/public/common-images/blockchain-basics/payments/transfer-invalid.png
deleted file mode 100644
index a20c6212..00000000
Binary files a/public/common-images/blockchain-basics/payments/transfer-invalid.png and /dev/null differ
diff --git a/public/common-images/blockchain-basics/payments/transfer.png b/public/common-images/blockchain-basics/payments/transfer.png
deleted file mode 100644
index dc49e90e..00000000
Binary files a/public/common-images/blockchain-basics/payments/transfer.png and /dev/null differ
diff --git a/public/common-images/chainlink-vrf/add-consumer.png b/public/common-images/chainlink-vrf/add-consumer.png
deleted file mode 100644
index 483cdfe3..00000000
Binary files a/public/common-images/chainlink-vrf/add-consumer.png and /dev/null differ
diff --git a/public/common-images/chainlink-vrf/add-funds.png b/public/common-images/chainlink-vrf/add-funds.png
deleted file mode 100644
index e87b2092..00000000
Binary files a/public/common-images/chainlink-vrf/add-funds.png and /dev/null differ
diff --git a/public/common-images/chainlink-vrf/create-subscription.png b/public/common-images/chainlink-vrf/create-subscription.png
deleted file mode 100644
index 59c270b2..00000000
Binary files a/public/common-images/chainlink-vrf/create-subscription.png and /dev/null differ
diff --git a/public/common-images/chainlink-vrf/faucet.png b/public/common-images/chainlink-vrf/faucet.png
deleted file mode 100644
index c443418b..00000000
Binary files a/public/common-images/chainlink-vrf/faucet.png and /dev/null differ
diff --git a/public/common-images/chainlink-vrf/visit-subscription-management.png b/public/common-images/chainlink-vrf/visit-subscription-management.png
deleted file mode 100644
index d02de1df..00000000
Binary files a/public/common-images/chainlink-vrf/visit-subscription-management.png and /dev/null differ
diff --git a/public/common-images/codespaces/list-codespaces.png b/public/common-images/codespaces/list-codespaces.png
deleted file mode 100644
index 5b9b4972..00000000
Binary files a/public/common-images/codespaces/list-codespaces.png and /dev/null differ
diff --git a/public/common-images/codespaces/ports-open.png b/public/common-images/codespaces/ports-open.png
deleted file mode 100644
index c8a9aee8..00000000
Binary files a/public/common-images/codespaces/ports-open.png and /dev/null differ
diff --git a/public/common-images/codespaces/ports-publish.png b/public/common-images/codespaces/ports-publish.png
deleted file mode 100644
index 74d3e402..00000000
Binary files a/public/common-images/codespaces/ports-publish.png and /dev/null differ
diff --git a/public/common-images/codespaces/specify-idle-timeout.png b/public/common-images/codespaces/specify-idle-timeout.png
deleted file mode 100644
index d8cdaa3e..00000000
Binary files a/public/common-images/codespaces/specify-idle-timeout.png and /dev/null differ
diff --git a/public/common-images/codespaces/specify-spending-limit.png b/public/common-images/codespaces/specify-spending-limit.png
deleted file mode 100644
index 29ce644e..00000000
Binary files a/public/common-images/codespaces/specify-spending-limit.png and /dev/null differ
diff --git a/public/common-images/codespaces/stop-codespace.png b/public/common-images/codespaces/stop-codespace.png
deleted file mode 100644
index 4411ab5b..00000000
Binary files a/public/common-images/codespaces/stop-codespace.png and /dev/null differ
diff --git a/public/common-images/consensus/tps-vs-ttf.png b/public/common-images/consensus/tps-vs-ttf.png
deleted file mode 100644
index b0e6b878..00000000
Binary files a/public/common-images/consensus/tps-vs-ttf.png and /dev/null differ
diff --git a/public/common-images/core-wallet/account-advanced-options.png b/public/common-images/core-wallet/account-advanced-options.png
deleted file mode 100644
index 0210516c..00000000
Binary files a/public/common-images/core-wallet/account-advanced-options.png and /dev/null differ
diff --git a/public/common-images/core-wallet/go-to-account-manager.png b/public/common-images/core-wallet/go-to-account-manager.png
deleted file mode 100644
index 270e3e96..00000000
Binary files a/public/common-images/core-wallet/go-to-account-manager.png and /dev/null differ
diff --git a/public/common-images/core-wallet/go-to-add-network.png b/public/common-images/core-wallet/go-to-add-network.png
deleted file mode 100644
index 776c9f21..00000000
Binary files a/public/common-images/core-wallet/go-to-add-network.png and /dev/null differ
diff --git a/public/common-images/core-wallet/go-to-advanced.png b/public/common-images/core-wallet/go-to-advanced.png
deleted file mode 100644
index 1a0445f7..00000000
Binary files a/public/common-images/core-wallet/go-to-advanced.png and /dev/null differ
diff --git a/public/common-images/core-wallet/go-to-import-private-key.png b/public/common-images/core-wallet/go-to-import-private-key.png
deleted file mode 100644
index e9684877..00000000
Binary files a/public/common-images/core-wallet/go-to-import-private-key.png and /dev/null differ
diff --git a/public/common-images/core-wallet/go-to-manage-networks.png b/public/common-images/core-wallet/go-to-manage-networks.png
deleted file mode 100644
index abba7e7b..00000000
Binary files a/public/common-images/core-wallet/go-to-manage-networks.png and /dev/null differ
diff --git a/public/common-images/core-wallet/go-to-menu.png b/public/common-images/core-wallet/go-to-menu.png
deleted file mode 100644
index 32fa06f5..00000000
Binary files a/public/common-images/core-wallet/go-to-menu.png and /dev/null differ
diff --git a/public/common-images/core-wallet/import-account.png b/public/common-images/core-wallet/import-account.png
deleted file mode 100644
index 6e562db6..00000000
Binary files a/public/common-images/core-wallet/import-account.png and /dev/null differ
diff --git a/public/common-images/core-wallet/pin-extension.png b/public/common-images/core-wallet/pin-extension.png
deleted file mode 100644
index 65293f9b..00000000
Binary files a/public/common-images/core-wallet/pin-extension.png and /dev/null differ
diff --git a/public/common-images/cryptography/multi-signature-schemes-methods.png b/public/common-images/cryptography/multi-signature-schemes-methods.png
deleted file mode 100644
index b917063f..00000000
Binary files a/public/common-images/cryptography/multi-signature-schemes-methods.png and /dev/null differ
diff --git a/public/common-images/cryptography/multi-signature-schemes.png b/public/common-images/cryptography/multi-signature-schemes.png
deleted file mode 100644
index 79a2e0f6..00000000
Binary files a/public/common-images/cryptography/multi-signature-schemes.png and /dev/null differ
diff --git a/public/common-images/cryptography/signature-aggregation.png b/public/common-images/cryptography/signature-aggregation.png
deleted file mode 100644
index 9a248b11..00000000
Binary files a/public/common-images/cryptography/signature-aggregation.png and /dev/null differ
diff --git a/public/common-images/cryptography/signature-scheme-methods.png b/public/common-images/cryptography/signature-scheme-methods.png
deleted file mode 100644
index 74cd04de..00000000
Binary files a/public/common-images/cryptography/signature-scheme-methods.png and /dev/null differ
diff --git a/public/common-images/evm-precompiles/allowlist-roles.png b/public/common-images/evm-precompiles/allowlist-roles.png
deleted file mode 100644
index 136cf115..00000000
Binary files a/public/common-images/evm-precompiles/allowlist-roles.png and /dev/null differ
diff --git a/public/common-images/evm-precompiles/precompiles.png b/public/common-images/evm-precompiles/precompiles.png
deleted file mode 100644
index 8d9d2f0e..00000000
Binary files a/public/common-images/evm-precompiles/precompiles.png and /dev/null differ
diff --git a/public/common-images/hypersdk/frontend/execute-read-only-action.png b/public/common-images/hypersdk/frontend/execute-read-only-action.png
deleted file mode 100644
index eed14ac7..00000000
Binary files a/public/common-images/hypersdk/frontend/execute-read-only-action.png and /dev/null differ
diff --git a/public/common-images/hypersdk/frontend/frontend.png b/public/common-images/hypersdk/frontend/frontend.png
deleted file mode 100644
index 6771df62..00000000
Binary files a/public/common-images/hypersdk/frontend/frontend.png and /dev/null differ
diff --git a/public/common-images/hypersdk/frontend/greeting.png b/public/common-images/hypersdk/frontend/greeting.png
deleted file mode 100644
index ef1e619a..00000000
Binary files a/public/common-images/hypersdk/frontend/greeting.png and /dev/null differ
diff --git a/public/common-images/hypersdk/frontend/issue-transaction.png b/public/common-images/hypersdk/frontend/issue-transaction.png
deleted file mode 100644
index 046b7c1a..00000000
Binary files a/public/common-images/hypersdk/frontend/issue-transaction.png and /dev/null differ
diff --git a/public/common-images/intro/instructors/aaron-buchwald.jpeg b/public/common-images/intro/instructors/aaron-buchwald.jpeg
deleted file mode 100644
index 1533fa7e..00000000
Binary files a/public/common-images/intro/instructors/aaron-buchwald.jpeg and /dev/null differ
diff --git a/public/common-images/intro/instructors/andrea-vargas.jpeg b/public/common-images/intro/instructors/andrea-vargas.jpeg
deleted file mode 100644
index be232738..00000000
Binary files a/public/common-images/intro/instructors/andrea-vargas.jpeg and /dev/null differ
diff --git a/public/common-images/intro/instructors/ash.jpeg b/public/common-images/intro/instructors/ash.jpeg
deleted file mode 100644
index befb44dd..00000000
Binary files a/public/common-images/intro/instructors/ash.jpeg and /dev/null differ
diff --git a/public/common-images/intro/instructors/ilya.jpeg b/public/common-images/intro/instructors/ilya.jpeg
deleted file mode 100644
index 0070982f..00000000
Binary files a/public/common-images/intro/instructors/ilya.jpeg and /dev/null differ
diff --git a/public/common-images/intro/instructors/martin-eckardt.jpeg b/public/common-images/intro/instructors/martin-eckardt.jpeg
deleted file mode 100644
index f08ea073..00000000
Binary files a/public/common-images/intro/instructors/martin-eckardt.jpeg and /dev/null differ
diff --git a/public/common-images/intro/instructors/owen-wahlgren.jpeg b/public/common-images/intro/instructors/owen-wahlgren.jpeg
deleted file mode 100644
index 3e93bbc3..00000000
Binary files a/public/common-images/intro/instructors/owen-wahlgren.jpeg and /dev/null differ
diff --git a/public/common-images/intro/instructors/rodrigo-villar.jpeg b/public/common-images/intro/instructors/rodrigo-villar.jpeg
deleted file mode 100644
index 347f2ed3..00000000
Binary files a/public/common-images/intro/instructors/rodrigo-villar.jpeg and /dev/null differ
diff --git a/public/common-images/intro/instructors/sarp.jpeg b/public/common-images/intro/instructors/sarp.jpeg
deleted file mode 100644
index fbcff86e..00000000
Binary files a/public/common-images/intro/instructors/sarp.jpeg and /dev/null differ
diff --git a/public/common-images/multi-chain-architecture/combined-throughput.png b/public/common-images/multi-chain-architecture/combined-throughput.png
deleted file mode 100644
index d485814a..00000000
Binary files a/public/common-images/multi-chain-architecture/combined-throughput.png and /dev/null differ
diff --git a/public/common-images/multi-chain-architecture/etna-upgrade/l1-running-cost.png b/public/common-images/multi-chain-architecture/etna-upgrade/l1-running-cost.png
deleted file mode 100644
index 910dfa57..00000000
Binary files a/public/common-images/multi-chain-architecture/etna-upgrade/l1-running-cost.png and /dev/null differ
diff --git a/public/common-images/multi-chain-architecture/etna-upgrade/l1s-compliance.png b/public/common-images/multi-chain-architecture/etna-upgrade/l1s-compliance.png
deleted file mode 100644
index 8bf55ff0..00000000
Binary files a/public/common-images/multi-chain-architecture/etna-upgrade/l1s-compliance.png and /dev/null differ
diff --git a/public/common-images/multi-chain-architecture/etna-upgrade/l1s-primary-network-faults.png b/public/common-images/multi-chain-architecture/etna-upgrade/l1s-primary-network-faults.png
deleted file mode 100644
index d4f09f4e..00000000
Binary files a/public/common-images/multi-chain-architecture/etna-upgrade/l1s-primary-network-faults.png and /dev/null differ
diff --git a/public/common-images/multi-chain-architecture/etna-upgrade/l1s-staking-requirement.png b/public/common-images/multi-chain-architecture/etna-upgrade/l1s-staking-requirement.png
deleted file mode 100644
index 5e50a9ce..00000000
Binary files a/public/common-images/multi-chain-architecture/etna-upgrade/l1s-staking-requirement.png and /dev/null differ
diff --git a/public/common-images/multi-chain-architecture/etna-upgrade/l1s.png b/public/common-images/multi-chain-architecture/etna-upgrade/l1s.png
deleted file mode 100644
index 906deb5c..00000000
Binary files a/public/common-images/multi-chain-architecture/etna-upgrade/l1s.png and /dev/null differ
diff --git a/public/common-images/multi-chain-architecture/etna-upgrade/subnet-running-cost.png b/public/common-images/multi-chain-architecture/etna-upgrade/subnet-running-cost.png
deleted file mode 100644
index f54e8a00..00000000
Binary files a/public/common-images/multi-chain-architecture/etna-upgrade/subnet-running-cost.png and /dev/null differ
diff --git a/public/common-images/multi-chain-architecture/etna-upgrade/subnets-compliance.png b/public/common-images/multi-chain-architecture/etna-upgrade/subnets-compliance.png
deleted file mode 100644
index 9aad4301..00000000
Binary files a/public/common-images/multi-chain-architecture/etna-upgrade/subnets-compliance.png and /dev/null differ
diff --git a/public/common-images/multi-chain-architecture/etna-upgrade/subnets-primary-network-congestion.png b/public/common-images/multi-chain-architecture/etna-upgrade/subnets-primary-network-congestion.png
deleted file mode 100644
index 4fa15ba6..00000000
Binary files a/public/common-images/multi-chain-architecture/etna-upgrade/subnets-primary-network-congestion.png and /dev/null differ
diff --git a/public/common-images/multi-chain-architecture/etna-upgrade/subnets-primary-network-fault.png b/public/common-images/multi-chain-architecture/etna-upgrade/subnets-primary-network-fault.png
deleted file mode 100644
index d4421cdd..00000000
Binary files a/public/common-images/multi-chain-architecture/etna-upgrade/subnets-primary-network-fault.png and /dev/null differ
diff --git a/public/common-images/multi-chain-architecture/etna-upgrade/subnets-staking-requirements-primary-network-and-subnets.png b/public/common-images/multi-chain-architecture/etna-upgrade/subnets-staking-requirements-primary-network-and-subnets.png
deleted file mode 100644
index 228eafff..00000000
Binary files a/public/common-images/multi-chain-architecture/etna-upgrade/subnets-staking-requirements-primary-network-and-subnets.png and /dev/null differ
diff --git a/public/common-images/multi-chain-architecture/etna-upgrade/subnets-staking-requirements-primary-network-only.png b/public/common-images/multi-chain-architecture/etna-upgrade/subnets-staking-requirements-primary-network-only.png
deleted file mode 100644
index 6c2601b9..00000000
Binary files a/public/common-images/multi-chain-architecture/etna-upgrade/subnets-staking-requirements-primary-network-only.png and /dev/null differ
diff --git a/public/common-images/multi-chain-architecture/etna-upgrade/subnets-staking-requirements.png b/public/common-images/multi-chain-architecture/etna-upgrade/subnets-staking-requirements.png
deleted file mode 100644
index d43b7c94..00000000
Binary files a/public/common-images/multi-chain-architecture/etna-upgrade/subnets-staking-requirements.png and /dev/null differ
diff --git a/public/common-images/multi-chain-architecture/etna-upgrade/subnets.png b/public/common-images/multi-chain-architecture/etna-upgrade/subnets.png
deleted file mode 100644
index 4755b301..00000000
Binary files a/public/common-images/multi-chain-architecture/etna-upgrade/subnets.png and /dev/null differ
diff --git a/public/common-images/multi-chain-architecture/subnets.png b/public/common-images/multi-chain-architecture/subnets.png
deleted file mode 100644
index d6043577..00000000
Binary files a/public/common-images/multi-chain-architecture/subnets.png and /dev/null differ
diff --git a/public/common-images/multi-chain-architecture/vm-variety.png b/public/common-images/multi-chain-architecture/vm-variety.png
deleted file mode 100644
index b638bffe..00000000
Binary files a/public/common-images/multi-chain-architecture/vm-variety.png and /dev/null differ
diff --git a/public/common-images/primary-network/p-chain.png b/public/common-images/primary-network/p-chain.png
deleted file mode 100644
index ad9de69a..00000000
Binary files a/public/common-images/primary-network/p-chain.png and /dev/null differ
diff --git a/public/common-images/solidity/encoding-decoding.png b/public/common-images/solidity/encoding-decoding.png
deleted file mode 100644
index 0203dee5..00000000
Binary files a/public/common-images/solidity/encoding-decoding.png and /dev/null differ
diff --git a/public/common-images/teleporter-token-bridge/hub-contract-structure.png b/public/common-images/teleporter-token-bridge/hub-contract-structure.png
deleted file mode 100644
index aed1c206..00000000
Binary files a/public/common-images/teleporter-token-bridge/hub-contract-structure.png and /dev/null differ
diff --git a/public/common-images/teleporter-token-bridge/spoke-contract-structure.png b/public/common-images/teleporter-token-bridge/spoke-contract-structure.png
deleted file mode 100644
index 0dcb138d..00000000
Binary files a/public/common-images/teleporter-token-bridge/spoke-contract-structure.png and /dev/null differ
diff --git a/public/common-images/teleporter/destination.png b/public/common-images/teleporter/destination.png
deleted file mode 100644
index 43d04ea8..00000000
Binary files a/public/common-images/teleporter/destination.png and /dev/null differ
diff --git a/public/common-images/teleporter/invoking-functions.png b/public/common-images/teleporter/invoking-functions.png
deleted file mode 100644
index 64aca873..00000000
Binary files a/public/common-images/teleporter/invoking-functions.png and /dev/null differ
diff --git a/public/common-images/teleporter/message-function-call.png b/public/common-images/teleporter/message-function-call.png
deleted file mode 100644
index 73df2cf4..00000000
Binary files a/public/common-images/teleporter/message-function-call.png and /dev/null differ
diff --git a/public/common-images/teleporter/message-multiple-parameters.png b/public/common-images/teleporter/message-multiple-parameters.png
deleted file mode 100644
index 71506fa9..00000000
Binary files a/public/common-images/teleporter/message-multiple-parameters.png and /dev/null differ
diff --git a/public/common-images/teleporter/message.png b/public/common-images/teleporter/message.png
deleted file mode 100644
index 16c4ea8c..00000000
Binary files a/public/common-images/teleporter/message.png and /dev/null differ
diff --git a/public/common-images/teleporter/source.png b/public/common-images/teleporter/source.png
deleted file mode 100644
index 13f35d37..00000000
Binary files a/public/common-images/teleporter/source.png and /dev/null differ
diff --git a/public/common-images/teleporter/teleporter-destination.png b/public/common-images/teleporter/teleporter-destination.png
deleted file mode 100644
index 470a5eb4..00000000
Binary files a/public/common-images/teleporter/teleporter-destination.png and /dev/null differ
diff --git a/public/common-images/teleporter/teleporter-fees-receipt.png b/public/common-images/teleporter/teleporter-fees-receipt.png
deleted file mode 100644
index 9ac3d0d2..00000000
Binary files a/public/common-images/teleporter/teleporter-fees-receipt.png and /dev/null differ
diff --git a/public/common-images/teleporter/teleporter-registry-class-diagram.png b/public/common-images/teleporter/teleporter-registry-class-diagram.png
deleted file mode 100644
index e48b393e..00000000
Binary files a/public/common-images/teleporter/teleporter-registry-class-diagram.png and /dev/null differ
diff --git a/public/common-images/teleporter/teleporter-registry.png b/public/common-images/teleporter/teleporter-registry.png
deleted file mode 100644
index 7a9d9eca..00000000
Binary files a/public/common-images/teleporter/teleporter-registry.png and /dev/null differ
diff --git a/public/common-images/teleporter/teleporter-source-destination.png b/public/common-images/teleporter/teleporter-source-destination.png
deleted file mode 100644
index db4bdfaa..00000000
Binary files a/public/common-images/teleporter/teleporter-source-destination.png and /dev/null differ
diff --git a/public/common-images/teleporter/teleporter-source.png b/public/common-images/teleporter/teleporter-source.png
deleted file mode 100644
index 1cd06b1b..00000000
Binary files a/public/common-images/teleporter/teleporter-source.png and /dev/null differ
diff --git a/public/common-images/teleporter/two-way-communication.png b/public/common-images/teleporter/two-way-communication.png
deleted file mode 100644
index a1bc0cd4..00000000
Binary files a/public/common-images/teleporter/two-way-communication.png and /dev/null differ
diff --git a/public/common-images/telepoter-chainlink-vrf/VRF provider and client.png b/public/common-images/telepoter-chainlink-vrf/VRF provider and client.png
deleted file mode 100644
index aa0fa12e..00000000
Binary files a/public/common-images/telepoter-chainlink-vrf/VRF provider and client.png and /dev/null differ
diff --git a/public/course-banner/avacloudapis.jpg b/public/course-banner/avacloudapis.jpg
deleted file mode 100644
index ac4bc1d0..00000000
Binary files a/public/course-banner/avacloudapis.jpg and /dev/null differ
diff --git a/public/course-banner/avalanche-fundamentals.jpg b/public/course-banner/avalanche-fundamentals.jpg
deleted file mode 100644
index bea148af..00000000
Binary files a/public/course-banner/avalanche-fundamentals.jpg and /dev/null differ
diff --git a/public/course-banner/customizing-evm.jpg b/public/course-banner/customizing-evm.jpg
deleted file mode 100644
index 91ae13c6..00000000
Binary files a/public/course-banner/customizing-evm.jpg and /dev/null differ
diff --git a/public/course-banner/gogopool-minipool.jpg b/public/course-banner/gogopool-minipool.jpg
deleted file mode 100644
index 06108332..00000000
Binary files a/public/course-banner/gogopool-minipool.jpg and /dev/null differ
diff --git a/public/course-banner/hypersdk.jpg b/public/course-banner/hypersdk.jpg
deleted file mode 100644
index 098eda8f..00000000
Binary files a/public/course-banner/hypersdk.jpg and /dev/null differ
diff --git a/public/course-banner/icm-chainlink.jpg b/public/course-banner/icm-chainlink.jpg
deleted file mode 100644
index ce475272..00000000
Binary files a/public/course-banner/icm-chainlink.jpg and /dev/null differ
diff --git a/public/course-banner/interchain-messaging.jpg b/public/course-banner/interchain-messaging.jpg
deleted file mode 100644
index 3af0fadd..00000000
Binary files a/public/course-banner/interchain-messaging.jpg and /dev/null differ
diff --git a/public/course-banner/interchain-token-transfer.jpg b/public/course-banner/interchain-token-transfer.jpg
deleted file mode 100644
index 22f50916..00000000
Binary files a/public/course-banner/interchain-token-transfer.jpg and /dev/null differ
diff --git a/public/course-banner/l1-tokenomics.jpg b/public/course-banner/l1-tokenomics.jpg
deleted file mode 100644
index 73cb2cae..00000000
Binary files a/public/course-banner/l1-tokenomics.jpg and /dev/null differ
diff --git a/public/course-banner/multi-chain-architecture.jpg b/public/course-banner/multi-chain-architecture.jpg
deleted file mode 100644
index 66888a2e..00000000
Binary files a/public/course-banner/multi-chain-architecture.jpg and /dev/null differ
diff --git a/public/course-banner/node-course.jpg b/public/course-banner/node-course.jpg
deleted file mode 100644
index eeb20dc9..00000000
Binary files a/public/course-banner/node-course.jpg and /dev/null differ
diff --git a/public/course-banner/safe-on-an-avalanche-chain.jpg b/public/course-banner/safe-on-an-avalanche-chain.jpg
deleted file mode 100644
index 54538d76..00000000
Binary files a/public/course-banner/safe-on-an-avalanche-chain.jpg and /dev/null differ
diff --git a/public/course-banner/solidity-fundamentals.jpg b/public/course-banner/solidity-fundamentals.jpg
deleted file mode 100644
index 52ef01e8..00000000
Binary files a/public/course-banner/solidity-fundamentals.jpg and /dev/null differ
diff --git a/public/course-banner/teleporter-chainlink-vrf.jpg b/public/course-banner/teleporter-chainlink-vrf.jpg
deleted file mode 100644
index f8825bf7..00000000
Binary files a/public/course-banner/teleporter-chainlink-vrf.jpg and /dev/null differ
diff --git a/public/course-banner/teleporter-token-bridge.jpg b/public/course-banner/teleporter-token-bridge.jpg
deleted file mode 100644
index 97893263..00000000
Binary files a/public/course-banner/teleporter-token-bridge.jpg and /dev/null differ
diff --git a/public/course-images/avacloudsdk/balance-app-init.png b/public/course-images/avacloudsdk/balance-app-init.png
deleted file mode 100644
index 49393d2a..00000000
Binary files a/public/course-images/avacloudsdk/balance-app-init.png and /dev/null differ
diff --git a/public/course-images/avacloudsdk/balance-app.png b/public/course-images/avacloudsdk/balance-app.png
deleted file mode 100644
index f2e6704d..00000000
Binary files a/public/course-images/avacloudsdk/balance-app.png and /dev/null differ
diff --git a/public/course-images/avacloudsdk/create-api-key.png b/public/course-images/avacloudsdk/create-api-key.png
deleted file mode 100644
index 0fc0137a..00000000
Binary files a/public/course-images/avacloudsdk/create-api-key.png and /dev/null differ
diff --git a/public/course-images/avacloudsdk/explorer.png b/public/course-images/avacloudsdk/explorer.png
deleted file mode 100644
index f8eeef6d..00000000
Binary files a/public/course-images/avacloudsdk/explorer.png and /dev/null differ
diff --git a/public/course-images/avacloudsdk/final-api-key.png b/public/course-images/avacloudsdk/final-api-key.png
deleted file mode 100644
index 8bf90a14..00000000
Binary files a/public/course-images/avacloudsdk/final-api-key.png and /dev/null differ
diff --git a/public/course-images/avacloudsdk/glacier-data-api.png b/public/course-images/avacloudsdk/glacier-data-api.png
deleted file mode 100644
index 02903aca..00000000
Binary files a/public/course-images/avacloudsdk/glacier-data-api.png and /dev/null differ
diff --git a/public/course-images/avacloudsdk/glacier-webhooks.png b/public/course-images/avacloudsdk/glacier-webhooks.png
deleted file mode 100644
index 060e5eb1..00000000
Binary files a/public/course-images/avacloudsdk/glacier-webhooks.png and /dev/null differ
diff --git a/public/course-images/avacloudsdk/grab-api-key.png b/public/course-images/avacloudsdk/grab-api-key.png
deleted file mode 100644
index 22528a77..00000000
Binary files a/public/course-images/avacloudsdk/grab-api-key.png and /dev/null differ
diff --git a/public/course-images/avacloudsdk/name-api-key.png b/public/course-images/avacloudsdk/name-api-key.png
deleted file mode 100644
index 23f7d53c..00000000
Binary files a/public/course-images/avacloudsdk/name-api-key.png and /dev/null differ
diff --git a/public/course-images/avacloudsdk/nfts.png b/public/course-images/avacloudsdk/nfts.png
deleted file mode 100644
index 8d5394c8..00000000
Binary files a/public/course-images/avacloudsdk/nfts.png and /dev/null differ
diff --git a/public/course-images/avacloudsdk/preview.png b/public/course-images/avacloudsdk/preview.png
deleted file mode 100644
index e870a072..00000000
Binary files a/public/course-images/avacloudsdk/preview.png and /dev/null differ
diff --git a/public/course-images/avacloudsdk/site-running.png b/public/course-images/avacloudsdk/site-running.png
deleted file mode 100644
index fb73f527..00000000
Binary files a/public/course-images/avacloudsdk/site-running.png and /dev/null differ
diff --git a/public/course-images/avacloudsdk/terminal.png b/public/course-images/avacloudsdk/terminal.png
deleted file mode 100644
index c9018a7f..00000000
Binary files a/public/course-images/avacloudsdk/terminal.png and /dev/null differ
diff --git a/public/course-images/avacloudsdk/tokens.png b/public/course-images/avacloudsdk/tokens.png
deleted file mode 100644
index 6daa1502..00000000
Binary files a/public/course-images/avacloudsdk/tokens.png and /dev/null differ
diff --git a/public/course-images/avacloudsdk/vs-code.png b/public/course-images/avacloudsdk/vs-code.png
deleted file mode 100644
index ef1cf539..00000000
Binary files a/public/course-images/avacloudsdk/vs-code.png and /dev/null differ
diff --git a/public/course-images/avacloudsdk/webhooks.jpg b/public/course-images/avacloudsdk/webhooks.jpg
deleted file mode 100644
index 105a763a..00000000
Binary files a/public/course-images/avacloudsdk/webhooks.jpg and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/1.png b/public/course-images/avalanche-fundamentals/1.png
deleted file mode 100644
index da87b2e7..00000000
Binary files a/public/course-images/avalanche-fundamentals/1.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/10.png b/public/course-images/avalanche-fundamentals/10.png
deleted file mode 100644
index c2a7e48c..00000000
Binary files a/public/course-images/avalanche-fundamentals/10.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/11.png b/public/course-images/avalanche-fundamentals/11.png
deleted file mode 100644
index 097e0163..00000000
Binary files a/public/course-images/avalanche-fundamentals/11.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/12.png b/public/course-images/avalanche-fundamentals/12.png
deleted file mode 100644
index dc41ac9b..00000000
Binary files a/public/course-images/avalanche-fundamentals/12.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/13.png b/public/course-images/avalanche-fundamentals/13.png
deleted file mode 100644
index 0b1067ad..00000000
Binary files a/public/course-images/avalanche-fundamentals/13.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/14.png b/public/course-images/avalanche-fundamentals/14.png
deleted file mode 100644
index 5d2b9849..00000000
Binary files a/public/course-images/avalanche-fundamentals/14.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/15.png b/public/course-images/avalanche-fundamentals/15.png
deleted file mode 100644
index 4fb897d8..00000000
Binary files a/public/course-images/avalanche-fundamentals/15.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/16.png b/public/course-images/avalanche-fundamentals/16.png
deleted file mode 100644
index 279dd990..00000000
Binary files a/public/course-images/avalanche-fundamentals/16.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/17.png b/public/course-images/avalanche-fundamentals/17.png
deleted file mode 100644
index 80459bc9..00000000
Binary files a/public/course-images/avalanche-fundamentals/17.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/18.png b/public/course-images/avalanche-fundamentals/18.png
deleted file mode 100644
index 5fbdeaaf..00000000
Binary files a/public/course-images/avalanche-fundamentals/18.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/19.png b/public/course-images/avalanche-fundamentals/19.png
deleted file mode 100644
index ee8ae851..00000000
Binary files a/public/course-images/avalanche-fundamentals/19.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/2.png b/public/course-images/avalanche-fundamentals/2.png
deleted file mode 100644
index df946bfc..00000000
Binary files a/public/course-images/avalanche-fundamentals/2.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/20.png b/public/course-images/avalanche-fundamentals/20.png
deleted file mode 100644
index b6d570e5..00000000
Binary files a/public/course-images/avalanche-fundamentals/20.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/21.png b/public/course-images/avalanche-fundamentals/21.png
deleted file mode 100644
index 6a9a1e9c..00000000
Binary files a/public/course-images/avalanche-fundamentals/21.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/22.png b/public/course-images/avalanche-fundamentals/22.png
deleted file mode 100644
index e9e0db7f..00000000
Binary files a/public/course-images/avalanche-fundamentals/22.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/23.png b/public/course-images/avalanche-fundamentals/23.png
deleted file mode 100644
index 55e3f0b7..00000000
Binary files a/public/course-images/avalanche-fundamentals/23.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/24.png b/public/course-images/avalanche-fundamentals/24.png
deleted file mode 100644
index 55e3f0b7..00000000
Binary files a/public/course-images/avalanche-fundamentals/24.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/25.png b/public/course-images/avalanche-fundamentals/25.png
deleted file mode 100644
index 1e188985..00000000
Binary files a/public/course-images/avalanche-fundamentals/25.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/26.png b/public/course-images/avalanche-fundamentals/26.png
deleted file mode 100644
index 639033da..00000000
Binary files a/public/course-images/avalanche-fundamentals/26.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/27.png b/public/course-images/avalanche-fundamentals/27.png
deleted file mode 100644
index d3a4280e..00000000
Binary files a/public/course-images/avalanche-fundamentals/27.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/28.png b/public/course-images/avalanche-fundamentals/28.png
deleted file mode 100644
index dda35cfc..00000000
Binary files a/public/course-images/avalanche-fundamentals/28.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/29.png b/public/course-images/avalanche-fundamentals/29.png
deleted file mode 100644
index 9eb82c18..00000000
Binary files a/public/course-images/avalanche-fundamentals/29.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/3.png b/public/course-images/avalanche-fundamentals/3.png
deleted file mode 100644
index 42fb4d4b..00000000
Binary files a/public/course-images/avalanche-fundamentals/3.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/30.png b/public/course-images/avalanche-fundamentals/30.png
deleted file mode 100644
index 4c8f8ab7..00000000
Binary files a/public/course-images/avalanche-fundamentals/30.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/31.png b/public/course-images/avalanche-fundamentals/31.png
deleted file mode 100644
index 1c7e2b27..00000000
Binary files a/public/course-images/avalanche-fundamentals/31.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/32.png b/public/course-images/avalanche-fundamentals/32.png
deleted file mode 100644
index a8a46fa9..00000000
Binary files a/public/course-images/avalanche-fundamentals/32.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/33.png b/public/course-images/avalanche-fundamentals/33.png
deleted file mode 100644
index 953a1a56..00000000
Binary files a/public/course-images/avalanche-fundamentals/33.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/34.png b/public/course-images/avalanche-fundamentals/34.png
deleted file mode 100644
index 8f2bbf60..00000000
Binary files a/public/course-images/avalanche-fundamentals/34.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/35.png b/public/course-images/avalanche-fundamentals/35.png
deleted file mode 100644
index 5b6a3a64..00000000
Binary files a/public/course-images/avalanche-fundamentals/35.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/4.png b/public/course-images/avalanche-fundamentals/4.png
deleted file mode 100644
index a64b3c70..00000000
Binary files a/public/course-images/avalanche-fundamentals/4.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/5.png b/public/course-images/avalanche-fundamentals/5.png
deleted file mode 100644
index 69896eef..00000000
Binary files a/public/course-images/avalanche-fundamentals/5.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/6.png b/public/course-images/avalanche-fundamentals/6.png
deleted file mode 100644
index e61bb892..00000000
Binary files a/public/course-images/avalanche-fundamentals/6.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/7.png b/public/course-images/avalanche-fundamentals/7.png
deleted file mode 100644
index 39ec194c..00000000
Binary files a/public/course-images/avalanche-fundamentals/7.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/8.png b/public/course-images/avalanche-fundamentals/8.png
deleted file mode 100644
index 688789a3..00000000
Binary files a/public/course-images/avalanche-fundamentals/8.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/9.png b/public/course-images/avalanche-fundamentals/9.png
deleted file mode 100644
index a9f2a925..00000000
Binary files a/public/course-images/avalanche-fundamentals/9.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/bridge-back-usdc.png b/public/course-images/avalanche-fundamentals/bridge-back-usdc.png
deleted file mode 100644
index fb23bada..00000000
Binary files a/public/course-images/avalanche-fundamentals/bridge-back-usdc.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/deposit.png b/public/course-images/avalanche-fundamentals/deposit.png
deleted file mode 100644
index 7bcfce8d..00000000
Binary files a/public/course-images/avalanche-fundamentals/deposit.png and /dev/null differ
diff --git a/public/course-images/avalanche-fundamentals/updated-balance.png b/public/course-images/avalanche-fundamentals/updated-balance.png
deleted file mode 100644
index 546c8f8d..00000000
Binary files a/public/course-images/avalanche-fundamentals/updated-balance.png and /dev/null differ
diff --git a/public/course-images/codespaces/open-locally.png b/public/course-images/codespaces/open-locally.png
deleted file mode 100644
index 1e6d9514..00000000
Binary files a/public/course-images/codespaces/open-locally.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/1.png b/public/course-images/customizing-evm/1.png
deleted file mode 100644
index 447bd924..00000000
Binary files a/public/course-images/customizing-evm/1.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/10.png b/public/course-images/customizing-evm/10.png
deleted file mode 100644
index 9cf7a0c4..00000000
Binary files a/public/course-images/customizing-evm/10.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/11.png b/public/course-images/customizing-evm/11.png
deleted file mode 100644
index cf82eb00..00000000
Binary files a/public/course-images/customizing-evm/11.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/12.png b/public/course-images/customizing-evm/12.png
deleted file mode 100644
index 4411ab5b..00000000
Binary files a/public/course-images/customizing-evm/12.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/13.png b/public/course-images/customizing-evm/13.png
deleted file mode 100644
index 5b9b4972..00000000
Binary files a/public/course-images/customizing-evm/13.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/14.png b/public/course-images/customizing-evm/14.png
deleted file mode 100644
index 1e6d9514..00000000
Binary files a/public/course-images/customizing-evm/14.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/15.png b/public/course-images/customizing-evm/15.png
deleted file mode 100644
index 1e4a903e..00000000
Binary files a/public/course-images/customizing-evm/15.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/16.png b/public/course-images/customizing-evm/16.png
deleted file mode 100644
index bea13e2a..00000000
Binary files a/public/course-images/customizing-evm/16.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/17.png b/public/course-images/customizing-evm/17.png
deleted file mode 100644
index 9449708e..00000000
Binary files a/public/course-images/customizing-evm/17.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/18.png b/public/course-images/customizing-evm/18.png
deleted file mode 100644
index 2f4876aa..00000000
Binary files a/public/course-images/customizing-evm/18.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/19.png b/public/course-images/customizing-evm/19.png
deleted file mode 100644
index a72f94e4..00000000
Binary files a/public/course-images/customizing-evm/19.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/2.png b/public/course-images/customizing-evm/2.png
deleted file mode 100644
index a0fa056d..00000000
Binary files a/public/course-images/customizing-evm/2.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/22.png b/public/course-images/customizing-evm/22.png
deleted file mode 100644
index 2fdbcb0a..00000000
Binary files a/public/course-images/customizing-evm/22.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/23.png b/public/course-images/customizing-evm/23.png
deleted file mode 100644
index 895a381b..00000000
Binary files a/public/course-images/customizing-evm/23.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/24.png b/public/course-images/customizing-evm/24.png
deleted file mode 100644
index fca98b3c..00000000
Binary files a/public/course-images/customizing-evm/24.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/25.png b/public/course-images/customizing-evm/25.png
deleted file mode 100644
index 6600eaed..00000000
Binary files a/public/course-images/customizing-evm/25.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/26.png b/public/course-images/customizing-evm/26.png
deleted file mode 100644
index 42d8368e..00000000
Binary files a/public/course-images/customizing-evm/26.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/27.png b/public/course-images/customizing-evm/27.png
deleted file mode 100644
index 3bfb962e..00000000
Binary files a/public/course-images/customizing-evm/27.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/28.png b/public/course-images/customizing-evm/28.png
deleted file mode 100644
index 5b6cf55e..00000000
Binary files a/public/course-images/customizing-evm/28.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/29.png b/public/course-images/customizing-evm/29.png
deleted file mode 100644
index 273fd4b6..00000000
Binary files a/public/course-images/customizing-evm/29.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/3.png b/public/course-images/customizing-evm/3.png
deleted file mode 100644
index 1d5a6c90..00000000
Binary files a/public/course-images/customizing-evm/3.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/30.png b/public/course-images/customizing-evm/30.png
deleted file mode 100644
index 382baf9b..00000000
Binary files a/public/course-images/customizing-evm/30.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/31.png b/public/course-images/customizing-evm/31.png
deleted file mode 100644
index 5d2b9849..00000000
Binary files a/public/course-images/customizing-evm/31.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/32.png b/public/course-images/customizing-evm/32.png
deleted file mode 100644
index 3208e25a..00000000
Binary files a/public/course-images/customizing-evm/32.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/33.png b/public/course-images/customizing-evm/33.png
deleted file mode 100644
index 2afc136a..00000000
Binary files a/public/course-images/customizing-evm/33.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/34.png b/public/course-images/customizing-evm/34.png
deleted file mode 100644
index f762d6fe..00000000
Binary files a/public/course-images/customizing-evm/34.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/35.png b/public/course-images/customizing-evm/35.png
deleted file mode 100644
index 35bcef70..00000000
Binary files a/public/course-images/customizing-evm/35.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/36.png b/public/course-images/customizing-evm/36.png
deleted file mode 100644
index b9a0c417..00000000
Binary files a/public/course-images/customizing-evm/36.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/37.png b/public/course-images/customizing-evm/37.png
deleted file mode 100644
index bea13e2a..00000000
Binary files a/public/course-images/customizing-evm/37.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/38.png b/public/course-images/customizing-evm/38.png
deleted file mode 100644
index ce46510a..00000000
Binary files a/public/course-images/customizing-evm/38.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/39.png b/public/course-images/customizing-evm/39.png
deleted file mode 100644
index 34701d54..00000000
Binary files a/public/course-images/customizing-evm/39.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/4.png b/public/course-images/customizing-evm/4.png
deleted file mode 100644
index 0460bfa1..00000000
Binary files a/public/course-images/customizing-evm/4.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/40.png b/public/course-images/customizing-evm/40.png
deleted file mode 100644
index 2f4876aa..00000000
Binary files a/public/course-images/customizing-evm/40.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/41.png b/public/course-images/customizing-evm/41.png
deleted file mode 100644
index a72f94e4..00000000
Binary files a/public/course-images/customizing-evm/41.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/42.png b/public/course-images/customizing-evm/42.png
deleted file mode 100644
index abba7e7b..00000000
Binary files a/public/course-images/customizing-evm/42.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/43.png b/public/course-images/customizing-evm/43.png
deleted file mode 100644
index 776c9f21..00000000
Binary files a/public/course-images/customizing-evm/43.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/44.png b/public/course-images/customizing-evm/44.png
deleted file mode 100644
index 2fdbcb0a..00000000
Binary files a/public/course-images/customizing-evm/44.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/45.png b/public/course-images/customizing-evm/45.png
deleted file mode 100644
index 895a381b..00000000
Binary files a/public/course-images/customizing-evm/45.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/46.png b/public/course-images/customizing-evm/46.png
deleted file mode 100644
index 42d8368e..00000000
Binary files a/public/course-images/customizing-evm/46.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/47.png b/public/course-images/customizing-evm/47.png
deleted file mode 100644
index 3bfb962e..00000000
Binary files a/public/course-images/customizing-evm/47.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/48.png b/public/course-images/customizing-evm/48.png
deleted file mode 100644
index 01e788aa..00000000
Binary files a/public/course-images/customizing-evm/48.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/5.png b/public/course-images/customizing-evm/5.png
deleted file mode 100644
index 94153b60..00000000
Binary files a/public/course-images/customizing-evm/5.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/6.png b/public/course-images/customizing-evm/6.png
deleted file mode 100644
index 6e79b3e6..00000000
Binary files a/public/course-images/customizing-evm/6.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/7.png b/public/course-images/customizing-evm/7.png
deleted file mode 100644
index 0b6a0343..00000000
Binary files a/public/course-images/customizing-evm/7.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/8.png b/public/course-images/customizing-evm/8.png
deleted file mode 100644
index 429a5041..00000000
Binary files a/public/course-images/customizing-evm/8.png and /dev/null differ
diff --git a/public/course-images/customizing-evm/9.png b/public/course-images/customizing-evm/9.png
deleted file mode 100644
index 47d44249..00000000
Binary files a/public/course-images/customizing-evm/9.png and /dev/null differ
diff --git a/public/course-images/ictt/core-bridge.png b/public/course-images/ictt/core-bridge.png
deleted file mode 100644
index ef69ace6..00000000
Binary files a/public/course-images/ictt/core-bridge.png and /dev/null differ
diff --git a/public/course-images/ictt/ictt.png b/public/course-images/ictt/ictt.png
deleted file mode 100644
index f9e4c0e8..00000000
Binary files a/public/course-images/ictt/ictt.png and /dev/null differ
diff --git a/public/course-images/interchain-messaging/cross-chain-vrf.png b/public/course-images/interchain-messaging/cross-chain-vrf.png
deleted file mode 100644
index 59a91d6e..00000000
Binary files a/public/course-images/interchain-messaging/cross-chain-vrf.png and /dev/null differ
diff --git a/public/course-images/interchain-token-transfer/cross-chain-swap-tx-receipt.png b/public/course-images/interchain-token-transfer/cross-chain-swap-tx-receipt.png
deleted file mode 100644
index c88d430e..00000000
Binary files a/public/course-images/interchain-token-transfer/cross-chain-swap-tx-receipt.png and /dev/null differ
diff --git a/public/course-images/interchain-token-transfer/site-running.png b/public/course-images/interchain-token-transfer/site-running.png
deleted file mode 100644
index 636703ce..00000000
Binary files a/public/course-images/interchain-token-transfer/site-running.png and /dev/null differ
diff --git a/public/course-images/multi-chain-architecture/gas-comparison.png b/public/course-images/multi-chain-architecture/gas-comparison.png
deleted file mode 100644
index dbaa26a2..00000000
Binary files a/public/course-images/multi-chain-architecture/gas-comparison.png and /dev/null differ
diff --git a/public/course-images/multi-chain-architecture/subnet-fee-comparison.png b/public/course-images/multi-chain-architecture/subnet-fee-comparison.png
deleted file mode 100644
index b3e30a6b..00000000
Binary files a/public/course-images/multi-chain-architecture/subnet-fee-comparison.png and /dev/null differ
diff --git a/public/course-images/multi-chain-architecture/transaction-fees/high-demand.png b/public/course-images/multi-chain-architecture/transaction-fees/high-demand.png
deleted file mode 100644
index ad9b7203..00000000
Binary files a/public/course-images/multi-chain-architecture/transaction-fees/high-demand.png and /dev/null differ
diff --git a/public/course-images/multi-chain-architecture/transaction-fees/low-demand.png b/public/course-images/multi-chain-architecture/transaction-fees/low-demand.png
deleted file mode 100644
index 84c1d07b..00000000
Binary files a/public/course-images/multi-chain-architecture/transaction-fees/low-demand.png and /dev/null differ
diff --git a/public/course-images/multi-chain-architecture/transaction-fees/stablecoin-swap.png b/public/course-images/multi-chain-architecture/transaction-fees/stablecoin-swap.png
deleted file mode 100644
index 77434efe..00000000
Binary files a/public/course-images/multi-chain-architecture/transaction-fees/stablecoin-swap.png and /dev/null differ
diff --git a/public/course-images/multi-chain-architecture/transaction-fees/swap-fees-high.png b/public/course-images/multi-chain-architecture/transaction-fees/swap-fees-high.png
deleted file mode 100644
index a08509ea..00000000
Binary files a/public/course-images/multi-chain-architecture/transaction-fees/swap-fees-high.png and /dev/null differ
diff --git a/public/course-images/multi-chain-architecture/transaction-fees/swap-fees-low.png b/public/course-images/multi-chain-architecture/transaction-fees/swap-fees-low.png
deleted file mode 100644
index 8dfc6891..00000000
Binary files a/public/course-images/multi-chain-architecture/transaction-fees/swap-fees-low.png and /dev/null differ
diff --git a/public/course-images/multi-chain-architecture/transaction-fees/user-price-expectation.png b/public/course-images/multi-chain-architecture/transaction-fees/user-price-expectation.png
deleted file mode 100644
index daa8e9ff..00000000
Binary files a/public/course-images/multi-chain-architecture/transaction-fees/user-price-expectation.png and /dev/null differ
diff --git a/public/course-images/teleporter/message-multiple-parameters-decode.png b/public/course-images/teleporter/message-multiple-parameters-decode.png
deleted file mode 100644
index eff8826f..00000000
Binary files a/public/course-images/teleporter/message-multiple-parameters-decode.png and /dev/null differ
diff --git a/public/course-images/teleporter/teleporter-source-destination-with-relayer.png b/public/course-images/teleporter/teleporter-source-destination-with-relayer.png
deleted file mode 100644
index f2ce3a6e..00000000
Binary files a/public/course-images/teleporter/teleporter-source-destination-with-relayer.png and /dev/null differ
diff --git a/public/course-preview.png b/public/course-preview.png
deleted file mode 100644
index 01f0391a..00000000
Binary files a/public/course-preview.png and /dev/null differ
diff --git a/public/guide-images/telegram-miniapp/include-branches.png b/public/guide-images/telegram-miniapp/include-branches.png
deleted file mode 100644
index 04f67333..00000000
Binary files a/public/guide-images/telegram-miniapp/include-branches.png and /dev/null differ
diff --git a/public/guide-images/telegram-miniapp/use-template.png b/public/guide-images/telegram-miniapp/use-template.png
deleted file mode 100644
index 39cecf15..00000000
Binary files a/public/guide-images/telegram-miniapp/use-template.png and /dev/null differ
diff --git a/public/guide-images/use-privy-on-l1/1.png b/public/guide-images/use-privy-on-l1/1.png
deleted file mode 100644
index d1b27133..00000000
Binary files a/public/guide-images/use-privy-on-l1/1.png and /dev/null differ
diff --git a/public/guide-images/use-privy-on-l1/2.png b/public/guide-images/use-privy-on-l1/2.png
deleted file mode 100644
index 0f35e658..00000000
Binary files a/public/guide-images/use-privy-on-l1/2.png and /dev/null differ
diff --git a/public/guide-images/use-privy-on-l1/3.png b/public/guide-images/use-privy-on-l1/3.png
deleted file mode 100644
index 4f1aa004..00000000
Binary files a/public/guide-images/use-privy-on-l1/3.png and /dev/null differ
diff --git a/public/guide-images/use-privy-on-l1/4.png b/public/guide-images/use-privy-on-l1/4.png
deleted file mode 100644
index 0869577d..00000000
Binary files a/public/guide-images/use-privy-on-l1/4.png and /dev/null differ
diff --git a/public/guide-images/use-privy-on-l1/5.png b/public/guide-images/use-privy-on-l1/5.png
deleted file mode 100644
index 63cba476..00000000
Binary files a/public/guide-images/use-privy-on-l1/5.png and /dev/null differ
diff --git a/public/guide-images/use-privy-on-l1/6.png b/public/guide-images/use-privy-on-l1/6.png
deleted file mode 100644
index 327e7b4f..00000000
Binary files a/public/guide-images/use-privy-on-l1/6.png and /dev/null differ
diff --git a/public/guide-images/use-privy-on-l1/7.png b/public/guide-images/use-privy-on-l1/7.png
deleted file mode 100644
index 6d068209..00000000
Binary files a/public/guide-images/use-privy-on-l1/7.png and /dev/null differ
diff --git a/public/logo.png b/public/logo.png
deleted file mode 100644
index 0662dbb2..00000000
Binary files a/public/logo.png and /dev/null differ
diff --git a/public/robots.txt b/public/robots.txt
deleted file mode 100644
index 860c04fe..00000000
--- a/public/robots.txt
+++ /dev/null
@@ -1,6 +0,0 @@
-User-agent: *
-Allow: /
-
-Host: https://academy.avax.network
-
-Sitemap: https://academy.avax.network/sitemap.xml
diff --git a/public/wolfie-check.png b/public/wolfie-check.png
deleted file mode 100644
index 21f86e42..00000000
Binary files a/public/wolfie-check.png and /dev/null differ
diff --git a/public/wolfie/wolfie-hack.png b/public/wolfie/wolfie-hack.png
deleted file mode 100644
index f9f9a569..00000000
Binary files a/public/wolfie/wolfie-hack.png and /dev/null differ
diff --git a/tailwind.config.js b/tailwind.config.js
deleted file mode 100644
index 321bc1e4..00000000
--- a/tailwind.config.js
+++ /dev/null
@@ -1,75 +0,0 @@
-import { createPreset, presets } from 'fumadocs-ui/tailwind-plugin';
-import animate from 'tailwindcss-animate';
-
-/** @type {import('tailwindcss').Config} */
-export default {
-  content: [
-    './components/**/*.{ts,tsx}',
-    './app/**/*.{ts,tsx}',
-    './content/**/*.mdx',
-    './mdx-components.tsx',
-    './node_modules/fumadocs-ui/dist/**/*.js',
-  ],
-  presets: [
-    createPreset({
-      preset: {
-        ...presets.default,
-        dark: {
-          ...presets.default.dark,
-          background: '0 0% 2%',
-          foreground: '0 0% 98%',
-          popover: '0 0% 4%',
-          card: '0 0% 4%',
-          muted: '0 0% 8%',
-          border: '0 0% 14%',
-          accent: '0 0% 15%',
-          'accent-foreground': '0 0% 100%',
-          'muted-foreground': '0 0% 60%',
-        },
-      },
-    }),
-  ],
-  theme: {
-    extend: {
-      fontFamily: {
-        sans: ['var(--font-geist-sans)'],
-        mono: ['var(--font-geist-mono)'],
-      },
-      
-      keyframes: {
-        updown: {
-          'from, to': {
-            transform: 'translateY(-20px)',
-          },
-          '50%': {
-            transform: 'translateY(20px)',
-          },
-        },
-        light: {
-          'from, to': {
-            opacity: 0.7,
-          },
-          '50%': {
-            opacity: 1,
-          },
-        },
-        stroke: {
-          from: {
-            'stroke-dasharray': 1000,
-          },
-          to: {
-            'stroke-dasharray': 1000,
-            'stroke-dashoffset': 2000,
-          },
-        },
-      },
-      animation: {
-        stroke: 'stroke 5s linear infinite',
-        light: 'light 2s ease-in-out infinite',
-        updown: 'updown 3s ease-in-out infinite',
-      },
-    },
-  },
-  plugins: [animate],
-};
-
diff --git a/tailwind.config.ts b/tailwind.config.ts
new file mode 100644
index 00000000..c21e4a62
--- /dev/null
+++ b/tailwind.config.ts
@@ -0,0 +1,18 @@
+import type { Config } from "tailwindcss";
+
+export default {
+  content: [
+    "./pages/**/*.{js,ts,jsx,tsx,mdx}",
+    "./components/**/*.{js,ts,jsx,tsx,mdx}",
+    "./app/**/*.{js,ts,jsx,tsx,mdx}",
+  ],
+  theme: {
+    extend: {
+      colors: {
+        background: "var(--background)",
+        foreground: "var(--foreground)",
+      },
+    },
+  },
+  plugins: [],
+} satisfies Config;
\ No newline at end of file
diff --git a/tsconfig.json b/tsconfig.json
index f87c06ee..47d1cd9d 100644
--- a/tsconfig.json
+++ b/tsconfig.json
@@ -24,6 +24,6 @@
       }
     ]
   },
-  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts", "app/providers.js"],
+  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts"],
   "exclude": ["node_modules"]
 }
diff --git a/utils/cn.ts b/utils/cn.ts
deleted file mode 100644
index ba66fd25..00000000
--- a/utils/cn.ts
+++ /dev/null
@@ -1 +0,0 @@
-export { twMerge as cn } from 'tailwind-merge';
diff --git a/utils/course-loader.ts b/utils/course-loader.ts
deleted file mode 100644
index 50e23dd9..00000000
--- a/utils/course-loader.ts
+++ /dev/null
@@ -1,39 +0,0 @@
-import { createMDXSource, defaultSchemas } from 'fumadocs-mdx';
-import { z } from 'zod';
-import type { InferMetaType, InferPageType } from 'fumadocs-core/source';
-import { loader } from 'fumadocs-core/source';
-import { icons } from 'lucide-react';
-import { map } from '.map';
-import { create } from '@/components/ui/icon';
-
-const loaderOutput = loader({
-  baseUrl: '/course',
-  rootDir: 'course',
-  icon(icon) {
-    if (icon && icon in icons)
-      return create({ icon: icons[icon as keyof typeof icons] });
-  },
-  source: createMDXSource(map, {
-    schema: {
-      frontmatter: defaultSchemas.frontmatter.extend({
-        preview: z.string().optional(),
-        toc: z.boolean().default(true),
-        index: z.boolean().default(false),
-        updated: z.string().or(z.date()).transform((value, context) => {
-            try {
-              return new Date(value);
-            } catch {
-              context.addIssue({ code: z.ZodIssueCode.custom, message: "Invalid date" });
-              return z.NEVER;
-            }
-          }),
-        authors: z.array(z.string()),
-        comments: z.boolean().default(false),
-      }),
-    },
-  }),
-});
-
-export type Page = InferPageType<typeof loaderOutput>;
-export type Meta = InferMetaType<typeof loaderOutput>;
-export const { getPage: getCoursePage, getPages: getCoursePages, pageTree: coursePageTree } = loaderOutput;
\ No newline at end of file
diff --git a/utils/guide-loader.ts b/utils/guide-loader.ts
deleted file mode 100644
index 36ad68e9..00000000
--- a/utils/guide-loader.ts
+++ /dev/null
@@ -1,24 +0,0 @@
-import { createMDXSource, defaultSchemas } from 'fumadocs-mdx';
-import { z } from 'zod';
-import type { InferMetaType, InferPageType } from 'fumadocs-core/source';
-import { loader } from 'fumadocs-core/source';
-import { map } from '.map';
-
-const loaderOutput = loader({
-  baseUrl: '/guide',
-  rootDir: 'guide',
-  source: createMDXSource(map, {
-    schema: {
-      frontmatter: defaultSchemas.frontmatter.extend({
-        authors: z.array(z.string()),
-        topics: z.array(z.string()),
-        date: z.string().date().or(z.date()).optional(),
-        comments: z.boolean().default(false),
-      }),
-    },
-  }),
-});
-
-export type Page = InferPageType<typeof loaderOutput>;
-export type Meta = InferMetaType<typeof loaderOutput>;
-export const { getPage: getGuidePage, getPages: getGuidePages, pageTree: guidePageTree } = loaderOutput;
\ No newline at end of file
diff --git a/utils/indexedDB.ts b/utils/indexedDB.ts
deleted file mode 100644
index 80a64e71..00000000
--- a/utils/indexedDB.ts
+++ /dev/null
@@ -1,50 +0,0 @@
-import { openDB, IDBPDatabase } from 'idb';
-
-interface QuizDB {
-  quizResponses: {
-    key: string;
-    value: {
-      selectedAnswers: number[];
-      isAnswerChecked: boolean;
-      isCorrect: boolean;
-    };
-  };
-}
-
-const dbName = 'QuizDatabase';
-const storeName = 'quizResponses';
-
-let dbPromise: Promise<IDBPDatabase<QuizDB>> | null = null;
-
-function getDBPromise() {
-  if (!dbPromise) {
-    dbPromise = openDB<QuizDB>(dbName, 1, {
-      upgrade(db) {
-        db.createObjectStore(storeName);
-      },
-    });
-  }
-  return dbPromise;
-}
-
-export async function saveQuizResponse(quizId: string, response: QuizDB['quizResponses']['value']) {
-  if (typeof window !== 'undefined') {
-    const db = await getDBPromise();
-    await db.put(storeName, response, quizId);
-  }
-}
-
-export async function getQuizResponse(quizId: string): Promise<QuizDB['quizResponses']['value'] | undefined> {
-  if (typeof window !== 'undefined') {
-    const db = await getDBPromise();
-    return db.get(storeName, quizId);
-  }
-  return undefined;
-}
-
-export async function resetQuizResponse(quizId: string) {
-  if (typeof window !== 'undefined') {
-    const db = await getDBPromise();
-    await db.delete(storeName, quizId);
-  }
-}
\ No newline at end of file
diff --git a/utils/metadata.ts b/utils/metadata.ts
deleted file mode 100644
index 7970438d..00000000
--- a/utils/metadata.ts
+++ /dev/null
@@ -1,27 +0,0 @@
-import type { Metadata } from 'next/types';
-
-export function createMetadata(override: Metadata): Metadata {
-  return {
-    ...override,
-    openGraph: {
-      title: override.title ?? undefined,
-      description: override.description ?? undefined,
-      url: 'https://academy.avax.network',
-      images: '/banner.png',
-      siteName: 'Avalanche Academy',
-      ...override.openGraph,
-    },
-    twitter: {
-      card: 'summary_large_image',
-      title: override.title ?? undefined,
-      description: override.description ?? undefined,
-      images: '/banner.png',
-      ...override.twitter,
-    },
-  };
-}
-
-export const baseUrl =
-  process.env.NODE_ENV === 'development'
-    ? new URL('http://localhost:3000')
-    : new URL(`https://${process.env.VERCEL_URL!}`);
diff --git a/utils/quizProgress.ts b/utils/quizProgress.ts
deleted file mode 100644
index 486b1cea..00000000
--- a/utils/quizProgress.ts
+++ /dev/null
@@ -1,27 +0,0 @@
-import { getQuizResponse } from './indexedDB';
-
-interface QuizProgress {
-  [quizId: string]: boolean;
-}
-
-export async function getQuizProgress(quizIds: string[]): Promise<QuizProgress> {
-  const progress: QuizProgress = {};
-  
-  for (const quizId of quizIds) {
-    const response = await getQuizResponse(quizId);
-    progress[quizId] = response ? response.isCorrect : false;
-  }
-  
-  return progress;
-}
-
-export function calculateCompletionRate(progress: QuizProgress): number {
-  const totalQuizzes = Object.keys(progress).length;
-  const completedQuizzes = Object.values(progress).filter(Boolean).length;
-  return (completedQuizzes / totalQuizzes) * 100;
-}
-
-export function isEligibleForCertificate(progress: QuizProgress, threshold: number = 80): boolean {
-  const completionRate = calculateCompletionRate(progress);
-  return completionRate >= threshold;
-}
\ No newline at end of file
diff --git a/utils/source.ts b/utils/source.ts
deleted file mode 100644
index a1ae22ff..00000000
--- a/utils/source.ts
+++ /dev/null
@@ -1,54 +0,0 @@
-import { createMDXSource, defaultSchemas } from 'fumadocs-mdx';
-import { z } from 'zod';
-import type { InferMetaType, InferPageType } from 'fumadocs-core/source';
-import { loader } from 'fumadocs-core/source';
-import { icons } from 'lucide-react';
-import { map } from '.map';
-import { create } from '@/components/ui/icon';
-
-const loaderOutput = loader({
-  baseUrl: '/course',
-  rootDir: 'course',
-  icon(icon) {
-    if (icon && icon in icons)
-      return create({ icon: icons[icon as keyof typeof icons] });
-  },
-  source: createMDXSource(map, {
-    schema: {
-      frontmatter: defaultSchemas.frontmatter.extend({
-        preview: z.string().optional(),
-        toc: z.boolean().default(true),
-        index: z.boolean().default(false),
-        updated: z.string().or(z.date()).transform((value, context) => {
-            try {
-              return new Date(value);
-            } catch {
-              context.addIssue({ code: z.ZodIssueCode.custom, message: "Invalid date" });
-              return z.NEVER;
-            }
-          }),
-        authors: z.array(z.string()),
-        comments: z.boolean().default(false),
-      }),
-    },
-  }),
-});
-
-export const guide = loader({
-  baseUrl: '/guide',
-  rootDir: 'guide',
-  source: createMDXSource(map, {
-    schema: {
-      frontmatter: defaultSchemas.frontmatter.extend({
-        authors: z.array(z.string()),
-        topics: z.array(z.string()),
-        date: z.string().date().or(z.date()).optional(),
-        comments: z.boolean().default(false),
-      }),
-    },
-  }),
-});
-
-export type Page = InferPageType<typeof loaderOutput>;
-export type Meta = InferMetaType<typeof loaderOutput>;
-export const { getPage, getPages, pageTree } = loaderOutput;