diff --git a/Gemfile b/Gemfile
index c98b092..1a301d9 100644
--- a/Gemfile
+++ b/Gemfile
@@ -1,2 +1,3 @@
 source "https://rubygems.org"
 gem "jekyll-theme-console", path: "./_vendor/jekyll-theme-console"
+gem 'jekyll-feed'
\ No newline at end of file
diff --git a/_config.yml b/_config.yml
index d0577c1..6e1e887 100644
--- a/_config.yml
+++ b/_config.yml
@@ -10,6 +10,7 @@ header_pages:
 - services.md
 - software.md
 - company.md
+- blog.md
 - contact.md
 
 style: dark
@@ -19,6 +20,11 @@ footer: '© 2025 Distrust LLC'
 
 theme: jekyll-theme-console
 
+permalink: blog/:title.html
+
+plugins:
+- jekyll-feed
+
 # Exclude from processing.
 # The following items will not be processed, by default.
 # Any item listed under the `exclude:` key here will be automatically added to
diff --git a/_includes/footer.html b/_includes/footer.html
index a3225b0..13779a8 100644
--- a/_includes/footer.html
+++ b/_includes/footer.html
@@ -8,6 +8,10 @@
 			<a class="footer-link" href="/software.html">Software</a>
 			<a class="footer-link" href="/company.html">Company</a>
 			<a class="footer-link" href="/contact.html">Contact</a>
+			<a class="footer-link" href="/feed.xml" style="vertical-align: middle;">
+				<img style="filter: grayscale(100%); width: 22px; vertical-align: sub" src="/assets/base/rss.png" />
+			</a>
+
 		</div>
 	</div>
 	<script type="text/javascript" src="/assets/js/main.js"></script>
diff --git a/_includes/head.html b/_includes/head.html
index 28d3fb5..dd23ac7 100644
--- a/_includes/head.html
+++ b/_includes/head.html
@@ -108,9 +108,12 @@
       <div>
         <a href="/company.html">Company</a>
       </div>
+			<div>
+				<a href="/blog.html">Blog</a>
+			</div>
       <div>
         <a href="/contact.html">Contact</a>
-      </div>
+			</div>
     </div>
   </div>
 </head>
diff --git a/_includes/header.html b/_includes/header.html
index 19b69fa..0530dc2 100644
--- a/_includes/header.html
+++ b/_includes/header.html
@@ -3,7 +3,7 @@
   <div class="menu">
     <div class="left-menu">
       <a id="home-link" href="/index.html">
-        <img class="menu-logo" src="assets/base/distrust-text-white.svg"
+        <img class="menu-logo" src="/assets/base/distrust-text-white.svg"
           alt="Distrust broken chain logo with white text" />
       </a>
     </div>
@@ -20,6 +20,7 @@
         <li class="show">
           <a href="/contact.html" class="mega-inverted button">Work with us</a>
         </li>
+
       </ul>
       <div id="hamburger-menu" class="hide menu-button-container" for="menu-toggle">
         <input id="menu-toggle" type="checkbox" />
diff --git a/_layouts/blog.html b/_layouts/blog.html
new file mode 100644
index 0000000..eeb64d8
--- /dev/null
+++ b/_layouts/blog.html
@@ -0,0 +1,39 @@
+<!DOCTYPE html>
+<html lang="{{ page.lang | default: site.lang | default: en }}">
+	{%- include head.html -%}
+	<body>
+		{%- include header.html -%}
+		<div class="container">
+			<main class="blog">
+				<div class="entry">
+					<div class="posts">
+						{% for post in site.posts %}
+						<div class="blog-details">
+							<div class="blog-details-date">{{ post.date | date: "%b %e, %Y" }}</div>
+							<div class="blog-details-read-time">{{ post.content | number_of_words | divided_by: 200 }} min read</div>
+						</div>
+						<a class="blog-link" href="{{ post.url | relative_url }}" title="{{ post.title }}">
+							<article>
+								<h1>{{ post.title }}</h1>
+								<p>{{ post.excerpt | strip_html | truncatewords: 25 }}</p>
+							</article>
+							<div class="arrow-link">
+								Read
+								<span class="arrow">&#x2192;</span>
+							</div>
+						</a>
+						{% endfor %}
+					</div>
+				</div>
+
+				<p>
+					{% for author in page.authors %}
+					— {{ author.name }}{% unless forloop.last %}, {% endunless %}
+					{% endfor %}
+				</p>
+			</main>
+			{%- include footer.html -%}
+		</div>
+	</body>
+</html>
+
diff --git a/_layouts/post.html b/_layouts/post.html
new file mode 100644
index 0000000..32efb00
--- /dev/null
+++ b/_layouts/post.html
@@ -0,0 +1,30 @@
+<!DOCTYPE html>
+<html lang="{{ page.lang | default: site.lang | default: en }}">
+	{%- include head.html -%}
+	<body>
+		{%- include header.html -%}
+		<div class="container">
+			<main class="blog">
+				<article class="post">
+					<div class="blog-details">
+						<div class="blog-details-date">{{ page.date | date: "%b %e, %Y" }}</div>
+						<div class="blog-details-read-time">{{ page.content | number_of_words | divided_by: 200 }} min read</div>
+					</div>
+					<h1>{{page.title}}</h1>
+
+					<div class="entry">
+						{{ content }}
+					</div>
+
+					<p>
+						{% for author in page.authors %}
+							— {{ author.name }}{% unless forloop.last %}, {% endunless %}
+						{% endfor %}
+					</p>
+				</article>
+			</main>
+			{%- include footer.html -%}
+		</div>
+	</body>
+</html>
+
diff --git a/_posts/2025-03-20-bitby-report.md b/_posts/2025-03-20-bitby-report.md
new file mode 100644
index 0000000..1bb1209
--- /dev/null
+++ b/_posts/2025-03-20-bitby-report.md
@@ -0,0 +1,173 @@
+---
+layout: post
+title: The Safe{Wallet}/Bybit incident report and mitigation strategies
+date: 2025-04-02
+---
+
+The Safe{Wallet}/Bybit incident is an example of a nation-state actor executing a series of sophisticated, multi-layered attacks on high-value targets. In cases where the potential gain is significant, all attacks are on the table. It may be justified for attackers to invest in multiple 0-day vulnerabilities and chain them into elaborate exploit sequences. These campaigns often span multiple layers of tech stack, involve precision-targeted social engineering, insider compromise, or even physical infiltration.
+
+As such, defending against this level of adversary requires a threat model that accounts for their full range of capabilities—and guides the design of equally rigorous mitigations. It demands defenders adopt a much more rigorous set of assumptions about attacker's capabilities and invest time in implementing controls that typical organizations may not need. When protecting high value assets, the game changes.
+
+### Threat model assumptions
+
+At Distrust, we operate under the assumption that nation-state actors are persistent, highly resourced, and capable of compromising nearly any layer of the system. Accordingly, our threat model assumes:
+
+* All screens are visible to the adversary
+* All keyboard input is being logged by the adversary
+* Any firmware or bootloader not verified on every boot is considered compromised
+* Any host OS with network access is compromised
+* Any guest OS used for non-production purposes is compromised
+* At least one member of the Production Team is compromised
+* At least one maintainer of third party code used in the system is compromised
+* At least one member of third party system used in production is compromised
+* Physical attacks are viable and likely
+* Side-channel attacks are viable and likely
+
+These assumptions drive everything at Distrust, including the strategies and tooling outlined in this report. The strategies we've developed are built specifically to address this elevated threat model. Many of our open source tools are ready to use today, some are reference designs, while other tooling requires further development.
+
+### Summary
+
+This report identifies critical single points of failure—cases where trust is placed in a single individual or computer—creating opportunities for compromise. In contrast, blockchains offer stronger security properties through cryptography and decentralized trust models.
+
+Traditional infrastructure has historically lacked mechanisms to distribute trust, but this limitation can be addressed. By applying targeted design strategies, it's possible to distribute trust (**dis**trust, get it?) across systems and reduce the risk of a single compromised actor undermining the integrity of the entire system.
+
+---
+
+## Root cause analysis and mitigation strategies
+
+In our opinion, the primary causes of this incident stem from two key issues identified in the [Sygnia report](https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/):
+
+* > ... a developer’s Mac OS workstation was compromised, likely through social engineering.
+
+* > ... the modification of JavaScript resources directly on the S3 bucket serving the domain app.safe[.]global.
+
+These findings highlight both endpoint compromise and weak controls around cloud infrastructure. The following sections focus on how such risks could be mitigated through architectural decisions and more rigorous threat modeling.
+
+## Introduction
+
+The compromise occurred due to several key factors, already documented in other reports. This report focuses on how the incident **could have been prevented** through a stronger, first-principles approach to infrastructure design.
+
+While many security teams reach for quick wins—like access token rotation, stricter IAM policies, or improved monitoring—these are often reactive measures. They may help, but they're equivalent of "plugging holes on a sinking ship" rather than rebuilding the hull from stronger material.
+
+For example, improving access control to the S3 bucket used to serve JavaScript resources, or adding better monitoring, are good steps. However, they  don't address the root cause.
+
+> At the core of this breach lies a recurring theme: single points of failure.
+
+To explore this from first principles, consider the deployment pipeline. In most companies, one individual—an admin or developer—often has the ability to modify critical infrastructure or code. That person becomes a single point of failure.
+
+Even if the pipeline is hardened, the risk will shift, rather than disappear. There is almost always one super-admin who has the "keys to the kingdom". Most cloud platforms encourage this pattern, and the industry has come to accept it.
+
+But this isn't about doubting your team and their intentions—it's about designing systems where **trust is distributed**. In the blockchain space, this is already accepted practice. So the question becomes:
+
+> *Does it make sense for a single individual to hold the integrity of an entire system in their hands?*
+
+Those who've worked with decentralized systems would say: absolutely not.
+
+#### Mitigation principles
+
+To adequately defend against the risks outlined in the Distrust threat model, it is critical to distinguish between **cold** and **hot** wallets. The following principles are drawn from practical experience building secure systems at BitGo, Unit410, and Turnkey, as well as from diligence work conduced across leading custodial and vaulting solutions.
+
+* A **cold cryptographic key management system** is one where all components can be built, operated, and verified offline. If any part of the system requires trusting a networked component, it becomes a **hot** system by definition. For example, if a wallet relies on internet-connected components, it should be considered a hot wallet—regardless of how it's marketed. While some systems make trade-offs for user experience, these often come at the cost of security guarantees.
+
+* Cold cryptographic key management systems that leverage truly random entropy sources are **not susceptible to remote attacks**, and are only exposed to localized threats such as physical access or side-channel attacks.
+
+* A common misconception is that simply keeping a key offline makes a system cold and secure. But an attacker doesn't always need to steal the key—they just need to achieve the outcome where the key performs an operation on the desired data on their behalf.
+
+* **All software in the stack must be open source**, built deterministically (to support reproduction), and compiled using a fully bootstrapped toolchain. Otherwise, the system remains exposed to single points of failure, especially via supply chain compromise.
+
+#### Mitigations and reference designs
+
+We propose two high-level design strategies that can eliminate the types of vulnerabilities exploited in the Safe{Wallet}/Bybit attack. Both approaches offer similar levels of security assurance—but differ significantly in implementation complexity and effort.
+
+In our view, **when billions of dollars are at stake**, it is worth investing in proven low-level mitigations, even if they are operationally harder to deploy. The accounting is simple: **invest in securing your system up front**, rather than gambling on assumptions you won't be targeted.
+
+State funded actors are highly motivated—and when digital assets are involved, it's game theory at work. The cost of compromising a weak system is often far less than the potential gain.
+
+We've seen this playbook used in previous incidents, a major example being Axie Infinity, and we will see it again. Attackers are increasingly exploiting supply chains and single points of failure—while defenders often under-invest in securing this surface area.
+
+#### Strategy 1 - Run everything locally
+
+This strategy can be implemented without major adjustments to the existing system. The goal is to move the component currently introducing risk—effectively making the wallet "hot"--—into an offline component, upgrading the system to a fully cold solution.
+
+The idea centers on extracting the **signing** component from the application (which currently operates in the UI) and converting it into an offline application.
+
+However, simply making a component offline does not eliminate all single points of failure. To close off supply chain threats stemming from compiler, dependency or environment compromise requires that the application is reproduced on multiple diverse systems (using different chipsets and operating systems), using a fully bootstrapped compiler—a fully hermetic, deterministic and reproducible process.
+
+We've developed open source tooling for this under **[StageX](https://codeberg.org/stagex/stagex)**. To learn more about the importance of reproducible builds, check out [this video](https://antonlivaja.com/videos/2024-incyber-stagex-talk.mp4), where one of our co-founders explains how the SolarWinds incident unfolded—and how it could have been prevented.
+
+##### Reference design
+
+This reference design was developed for the Safe{Wallet} team, but it can be applied to any system seeking to distribute trust.
+
+1. **System administrators use dedicated offline laptops**
+
+	* All radio hardware (Bluetooth, Wi-Fi) is physically removed
+
+	* Machines are air-gapped and have never been connected to the internet
+
+2. **Engineers provision and manage their own personal signing keys (PGP)**
+
+	* Smart cards like NitroKey or YubiKey are used
+
+	* Signing operations are performed exclusively on the engineer's offline system
+
+	* Distrust has developed open source tooling to drastically simplify PGP key provisioning: **[Trove](https://trove.distrust.co/generated-documents/all-levels/pgp-key-provisioning.html)**
+
+3. **Offline signing applications are deterministically compiled, verified, and signed by multiple engineers**
+
+	* Includes a full set of tools needed for secure offline key operations
+
+	* Distrust also created **[AirgapOS](https://git.distrust.co/public/airgap)**, a custom Linux distribution designed specifically for offline secret management. It has been independently audited and is used in production by several major digitial asset organizations.
+
+4. **All sensitive operations are fully verified offline before any cryptographic action is taken**
+
+This design drastically reduces exposure to remote attacks and central points of trust, aligning closely with Distrust's first-principles security model.
+
+#### Strategy 2 - Use remotely verified service
+
+This strategy maintains a user experience nearly identical to the current system, while introducing verifiability at critical points in the architecture. It requires significantly more engineering effort and operational discipline, and the tooling needed to support this model is still under active development.
+
+##### Reference design
+
+This design relies on **secure enclaves** to host servers that are immutable, deterministic, and capable of cryptographically attesting to the software they are running. While this brings us closer to a cold setup, some residual attack surface—such as browser exploits, host OS compromise, or 0-day attacks—will always remain.
+
+The core implementation steps are:
+
+1. **Rewrite the application to run entirely within a secure enclave**
+
+	* TLS termination occurs **inside** the enclave
+
+	* The web interface is served **from within** the enclave
+
+	* Nothing outside the enclave is trusted
+
+2. **Create a deterministic OS image with remote attestation (e.g., TPM2, Nitro Enclave or similar)**
+
+	* The entire stack is built using full source bootstrapped compiler in a bit-for-bit reproducible manner
+
+3. **One engineer deploys a new enclave** with the updated application code
+
+4. **A second engineer independently verifies** that the deployed code matches the version in the source repository
+
+5. **Clients are issued a service worker** on first load that pins attestation keys for all future remote verification
+
+	* Users can optionally verify and download the application locally for offline operations
+
+	* Users are also encouraged to self-build and match the published signed hash
+
+
+## Implementation considerations
+
+Implementing these strategies can be technically demanding. They represent two ends of the trust minimization spectrum: one favoring offline, air-gapped assurance; the other introducing verifiability within connected systems. Both approaches significantly reduce risk but vary in complexity, tooling and requirements, and rollout timelines.
+
+This high-level overview is meant to illustrate the kinds of problems we focus on at Distrust. Depending on the chosen strategy and organizational context, implementation can take anywhere from a few weeks to several years, especially as tooling continues to mature.
+
+## About Distrust
+
+The Distrust team has helped build and secure some of the highest-risk systems in the world. This includes vaulting infrastructure at BitGo, Unit410, and Turnkey, as well as security work with electrical grid operators, industrial control systems, and other mission-critical systems.
+
+We've conducted deep security due diligence across most major custodians. Through our experience with organizations that operate under constant threat—where **every class of attack is viable**—we've developed a methodology and set of open source tools designed to defend against even the most sophisticated adversaries.
+
+Today, we're taking the hard-earned lessons from that work and sharing them with the broader community. Our goal is to help others strengthen their security posture by making what we've learned—and the open source tools we've built—available to everyone.
+
+**Looking for help analyzing and mitigating security risks in your own organization? [Talk to us](https://distrust.co/contact.html)**.
diff --git a/_sass/base.scss b/_sass/base.scss
index 5b4380b..a8b44c1 100644
--- a/_sass/base.scss
+++ b/_sass/base.scss
@@ -99,7 +99,7 @@ a {
 a:hover {
 	text-decoration: none;
 	color: var(--background-color);
-	background-color: var(--base-color);
+	background: var(--base-color);
 	transition: background-color 0.3s ease-in-out, color 0.3s ease-in-out;
 }
 
@@ -367,6 +367,9 @@ a:hover {
 	border-radius: 4px;
 	margin-left: 0px;
 	padding-left: 0px;
+	/* TODO: for some reason, removing this makes it white. */
+	/* Firefox shows no computed reason for it to be white. */
+	background-color: var(--background-color);
 }
 
 .arrow {
@@ -375,6 +378,17 @@ a:hover {
 	transition: transform 0.3s ease;
 }
 
+.blog-link:hover .arrow {
+	transform: translateX(5px);
+	background: none !important;
+	background-color: var(--base-color);
+	color: white !important;
+}
+
+.blog a:hover {
+	background: unset;
+}
+
 .arrow-link:hover .arrow {
 	transform: translateX(5px);
 	background: none !important;
@@ -596,11 +610,9 @@ footer {
 	display: inline-block;
 	text-decoration: none;
 	margin-left: 20px;
-	transition: transform 0.5s ease !important;
 }
 
 .footer-link:hover {
-	transform: translateY(-2px);
 	background: transparent;
 	color: white;
 }
@@ -653,7 +665,6 @@ hr {
 	margin: 0px 4px;
 	font-size: 1.1rem;
 	text-decoration: none;
-	transition: transform 0.5s ease;
 }
 
 .header-page-links a.active {
@@ -661,7 +672,6 @@ hr {
 }
 
 .header-page-links a:hover {
-	transform: translateY(-2px);
 	background-color: transparent;
 	color: white;
 }
@@ -1177,6 +1187,11 @@ section {
 	margin: 250px 0px;
 }
 
+.extra-spacing {
+   margin-top: 70px;
+   margin-bottom: 70px;
+}
+
 .companies {
 	display: flex;
 	justify-content: space-between;
@@ -1641,6 +1656,18 @@ pre {
 /**
  * Blog
  */
+
+.blog {
+	margin: auto;
+	max-width: 700px;
+	margin-top: 80px;
+}
+
+.post {
+	max-width: 700px;
+	margin: 100px 0px;
+}
+
 .post img {
 	max-width: 100%;
 }
@@ -1649,6 +1676,94 @@ pre {
 	max-width: 100%;
 }
 
+#lp-post-img {
+   max-width: 100%;
+}
+
+.entry {
+	font-size: 1.2rem;
+}
+
+.date h4 {
+	font-size: 1rem !important;
+}
+
+#blog-header {
+	margin: 80px 0px;
+}
+
+.blog-header-title {
+	display: inline-block;
+	font-size: 3.2rem;
+	text-align: center;
+	width: 100%;
+	margin-top: 80px;
+}
+
+.blog-header-subtitle {
+	text-align: center;
+	font-size: 1.5rem;
+	color: var(--light-grey);
+}
+
+.blog h1 {
+	font-size: 2.5rem !important;
+	line-height: 2.2rem !important;
+	font-weight: 600 !important;
+}
+
+.blog h2 {
+	font-size: 1.8rem !important;
+	font-weight: 600 !important;
+}
+
+.blog h3 {
+	font-size: 1.6rem !important;
+	font-weight: 600 !important;
+}
+
+.blog h4 {
+	font-size: 1.4rem !important;
+	font-weight: 600 !important;
+}
+
+.blog h5 {
+	font-size: 1.2rem !important;
+	font-weight: 600 !important;
+}
+
+.blog hr {
+	margin: 80px 0px;
+}
+
+.post a {
+	color: var(--light-teal);
+}
+
+.post a:hover {
+	text-decoration: underline;
+}
+
+.blog-details {
+	display: flex;
+	flex-direction: left;
+	font-size: 0.9rem;
+	margin-bottom: 10px;
+}
+
+.blog-details-date {
+	background: var(--light-grey);
+	color: var(--background-color);
+	border-radius: 5px;
+	padding: 2px 10px;
+}
+
+.blog-details-read-time {
+	padding: 2px 10px;
+	margin-left: 15px;
+	color: white;
+}
+
 /** end blog */
 
 *,
diff --git a/assets/base/rss.png b/assets/base/rss.png
new file mode 100644
index 0000000..2df0b6e
Binary files /dev/null and b/assets/base/rss.png differ
diff --git a/assets/images/whale_shark.jpg b/assets/images/whale_shark.jpg
new file mode 100644
index 0000000..71ea16e
Binary files /dev/null and b/assets/images/whale_shark.jpg differ
diff --git a/assets/js/main.js b/assets/js/main.js
index 55e1b97..526cae2 100644
--- a/assets/js/main.js
+++ b/assets/js/main.js
@@ -1,90 +1,90 @@
 const collapsibleButton = document.querySelector("#hamburger-menu");
 const menuContent = document.querySelector(".menu-content");
 collapsibleButton.addEventListener("click", function () {
-    menuContent.classList.toggle("active");
-    if (menuContent.style.display === "block") {
-        menuContent.style.display = "none";
-    } else {
-        menuContent.style.display = "block";
-    }
+	menuContent.classList.toggle("active");
+	if (menuContent.style.display === "block") {
+		menuContent.style.display = "none";
+	} else {
+		menuContent.style.display = "block";
+	}
 });
 
 document.addEventListener('DOMContentLoaded', function () {
-    initializeCompaniesCarousel();
-    fetch('../assets/js/carousel-items.json')
-        .then(response => response.json())
-        .then(data => {
-            createCarouselItems(data);
-						initializeCarousel();
-        })
-        .catch(error => console.error('Error loading JSON:', error));
+	initializeCompaniesCarousel();
+	fetch('../assets/js/carousel-items.json')
+		.then(response => response.json())
+		.then(data => {
+			createCarouselItems(data);
+			initializeCarousel();
+		})
+		.catch(error => console.error('Error loading JSON:', error));
 });
 
 function createCarouselItems(items) {
-    const carousel = document.querySelector('#carousel');
-    items.forEach(item => {
-        const itemDiv = document.createElement('div');
-        itemDiv.className = 'carousel-item'
+	const carousel = document.querySelector('#carousel');
+	items.forEach(item => {
+		const itemDiv = document.createElement('div');
+		itemDiv.className = 'carousel-item'
 
-        const link = document.createElement('a');
-        link.className = 'carousel-link';
-        link.href = item.link;
-        link.target = '_blank';
-        link.rel = 'noopener noreferrer';
-        const linkText = document.createTextNode(item.description);
+		const link = document.createElement('a');
+		link.className = 'carousel-link';
+		link.href = item.link;
+		link.target = '_blank';
+		link.rel = 'noopener noreferrer';
+		const linkText = document.createTextNode(item.description);
 
-        link.appendChild(linkText);
-        itemDiv.appendChild(link);
-        carousel.appendChild(itemDiv);
-    });
+		link.appendChild(linkText);
+		itemDiv.appendChild(link);
+		carousel.appendChild(itemDiv);
+	});
 }
 
 function initializeCarousel() {
-    const carousel = document.querySelector('#carousel');
-    const items = Array.from(carousel.children);
-    const totalItems = items.length;
-    const middleIndex = Math.floor(totalItems / 2);
-    let currentIndex = -middleIndex;
+	const carousel = document.querySelector('#carousel');
+	const items = Array.from(carousel.children);
+	const totalItems = items.length;
+	const middleIndex = Math.floor(totalItems / 2);
+	let currentIndex = -middleIndex;
 
-    function cycleItems() {
-        currentIndex = (currentIndex - 1 + totalItems) % totalItems;
-        updateCarouselItems();
-    }
+	function cycleItems() {
+		currentIndex = (currentIndex - 1 + totalItems) % totalItems;
+		updateCarouselItems();
+	}
 
-    function updateCarouselItems() {
-        items.forEach((item, index) => {
-            let positionIndex = (currentIndex + index + totalItems) % totalItems;
-            let offset = positionIndex - middleIndex;
-            item.style.transform = `translateY(${offset * 100}%)`;
-            item.classList.toggle('active', positionIndex === middleIndex);
-            item.style.visibility = 'visible';
-        });
-    }
+	function updateCarouselItems() {
+		items.forEach((item, index) => {
+			let positionIndex = (currentIndex + index + totalItems) % totalItems;
+			let offset = positionIndex - middleIndex;
+			item.style.transform = `translateY(${offset * 100}%)`;
+			item.classList.toggle('active', positionIndex === middleIndex);
+			item.style.visibility = 'visible';
+		});
+	}
 
-    updateCarouselItems();
-    setInterval(cycleItems, 7000);
+	updateCarouselItems();
+	setInterval(cycleItems, 7000);
 }
 
 function initializeCompaniesCarousel() {
-  const slider = document.getElementById('logoSlider');
+	const slider = document.getElementById('logoSlider');
 
-  // Duplicate the existing logos by appending the same HTML again:
-  slider.innerHTML += slider.innerHTML;
+	// Duplicate the existing logos by appending the same HTML again:
+	slider.innerHTML += slider.innerHTML;
 
-  let offset = 0;
-  const speed = 0.5;
+	let offset = 0;
+	const speed = 0.5;
 
-  function animate() {
-    offset -= speed;
-    slider.style.transform = `translateX(${offset}px)`;
+	function animate() {
+		offset -= speed;
+		slider.style.transform = `translateX(${offset}px)`;
 
-    // After half of the total (2 sets) is scrolled, reset
-    if (Math.abs(offset) >= slider.scrollWidth / 2) {
-      offset = 0;
-    }
-    requestAnimationFrame(animate);
-  }
+		// After half of the total (2 sets) is scrolled, reset
+		if (Math.abs(offset) >= slider.scrollWidth / 2) {
+			offset = 0;
+		}
+		requestAnimationFrame(animate);
+	}
 
-  requestAnimationFrame(animate);
+	requestAnimationFrame(animate);
 }
 
diff --git a/blog.md b/blog.md
new file mode 100644
index 0000000..e4e5ce5
--- /dev/null
+++ b/blog.md
@@ -0,0 +1,5 @@
+---
+layout: blog
+title: Blog
+permalink: /blog.html
+---
