diff --git a/app/glossary-demo/page.tsx b/app/glossary-demo/page.tsx
new file mode 100644
index 00000000..8fdce8cd
--- /dev/null
+++ b/app/glossary-demo/page.tsx
@@ -0,0 +1,83 @@
+import { GlossaryTerm } from "@/components/ui/glossary-term"
+import { getAllGlossaryTerms } from "@/data/glossary"
+
+export const metadata = {
+  title: "Glossary Demo - PSE",
+  description: "Technical terms glossary with hover tooltips",
+}
+
+export default function GlossaryDemoPage() {
+  const allTerms = getAllGlossaryTerms()
+
+  // Group terms by category
+  const termsByCategory = allTerms.reduce((acc, term) => {
+    const category = term.category || "Other"
+    if (!acc[category]) acc[category] = []
+    acc[category].push(term)
+    return acc
+  }, {} as Record<string, typeof allTerms>)
+
+  return (
+    <div className="min-h-screen bg-white dark:bg-anakiwa-975 py-16 px-4">
+      <div className="max-w-3xl mx-auto">
+        <h1 className="text-3xl font-bold text-tuatara-950 dark:text-white mb-4">
+          Glossary Demo
+        </h1>
+        <p className="text-tuatara-600 dark:text-tuatara-300 mb-8">
+          Hover over the underlined terms to see their definitions.
+        </p>
+
+        {/* Example paragraph with glossary terms */}
+        <div className="bg-tuatara-50 dark:bg-anakiwa-950 rounded-lg p-6 mb-12">
+          <h2 className="text-xl font-semibold text-tuatara-900 dark:text-white mb-4">
+            Example Usage
+          </h2>
+          <p className="text-tuatara-700 dark:text-tuatara-200 leading-relaxed">
+            <GlossaryTerm term="pse">PSE</GlossaryTerm> is focused on building
+            privacy-preserving tools using technologies like{" "}
+            <GlossaryTerm term="zero-knowledge">zero-knowledge proofs</GlossaryTerm>.
+            Projects like <GlossaryTerm term="semaphore">Semaphore</GlossaryTerm> and{" "}
+            <GlossaryTerm term="bandada">Bandada</GlossaryTerm> enable anonymous
+            group membership, while <GlossaryTerm term="tlsn">TLSNotary</GlossaryTerm>{" "}
+            provides data verification without revealing everything.
+          </p>
+          <p className="text-tuatara-700 dark:text-tuatara-200 leading-relaxed mt-4">
+            Privacy networks like <GlossaryTerm term="tor">Tor</GlossaryTerm> protect
+            users when making <GlossaryTerm term="rpc">RPC</GlossaryTerm> calls to
+            blockchain nodes. Advanced cryptographic techniques like{" "}
+            <GlossaryTerm term="fhe">FHE</GlossaryTerm> and{" "}
+            <GlossaryTerm term="mpc">MPC</GlossaryTerm> enable computation on
+            encrypted data.
+          </p>
+        </div>
+
+        {/* Full glossary list */}
+        <h2 className="text-2xl font-bold text-tuatara-950 dark:text-white mb-6">
+          All Terms
+        </h2>
+
+        {Object.entries(termsByCategory).map(([category, terms]) => (
+          <div key={category} className="mb-8">
+            <h3 className="text-lg font-semibold text-anakiwa-600 dark:text-anakiwa-400 mb-3">
+              {category}
+            </h3>
+            <div className="grid gap-2">
+              {terms.map((entry) => (
+                <div
+                  key={entry.term}
+                  className="flex items-start gap-2 p-3 rounded-lg bg-tuatara-50 dark:bg-anakiwa-950"
+                >
+                  <GlossaryTerm term={entry.term.toLowerCase().replace(/\s+/g, "-")}>
+                    <span className="font-medium text-tuatara-900 dark:text-white">
+                      {entry.term}
+                    </span>
+                  </GlossaryTerm>
+                </div>
+              ))}
+            </div>
+          </div>
+        ))}
+      </div>
+    </div>
+  )
+}
diff --git a/components/site-footer.tsx b/components/site-footer.tsx
index 649320ac..37a6c531 100644
--- a/components/site-footer.tsx
+++ b/components/site-footer.tsx
@@ -146,9 +146,6 @@ export function SiteFooter() {
             </AppLink>
           </LinksWrapper>
           <LinksWrapper>
-            <AppLink href={siteConfig.links.discord} external variant="button">
-              <ItemLabel label="Feedback" />
-            </AppLink>
             <AppLink
               href={siteConfig.links.privacyPolicy}
               external
diff --git a/components/ui/glossary-term.tsx b/components/ui/glossary-term.tsx
new file mode 100644
index 00000000..cfd4c957
--- /dev/null
+++ b/components/ui/glossary-term.tsx
@@ -0,0 +1,89 @@
+"use client"
+
+import { useState } from "react"
+import { findGlossaryTerm, GlossaryEntry } from "@/data/glossary"
+import { cn } from "@/lib/utils"
+
+interface GlossaryTermProps {
+  /** The term to look up in the glossary */
+  term: string
+  /** Optional: custom text to display (defaults to the term) */
+  children?: React.ReactNode
+  /** Optional: custom definition (overrides glossary lookup) */
+  definition?: string
+  /** Optional: additional CSS classes */
+  className?: string
+}
+
+export function GlossaryTerm({
+  term,
+  children,
+  definition: customDefinition,
+  className,
+}: GlossaryTermProps) {
+  const [isVisible, setIsVisible] = useState(false)
+
+  // Look up term in glossary
+  const glossaryEntry = findGlossaryTerm(term)
+  const definition = customDefinition || glossaryEntry?.definition
+  const displayTerm = glossaryEntry?.term || term
+
+  // If no definition found, just render the text without tooltip
+  if (!definition) {
+    return <span className={className}>{children || term}</span>
+  }
+
+  return (
+    <span
+      className={cn("relative inline-block", className)}
+      onMouseEnter={() => setIsVisible(true)}
+      onMouseLeave={() => setIsVisible(false)}
+    >
+      {/* The term with dotted underline to indicate it's interactive */}
+      <span className="border-b border-dotted border-anakiwa-500 dark:border-anakiwa-400 cursor-help">
+        {children || term}
+      </span>
+
+      {/* Tooltip popup */}
+      {isVisible && (
+        <span
+          role="tooltip"
+          className={cn(
+            "absolute z-50 bottom-full left-1/2 -translate-x-1/2 mb-2",
+            "w-64 p-3 rounded-lg shadow-lg",
+            "bg-white dark:bg-anakiwa-950",
+            "border border-tuatara-200 dark:border-anakiwa-800",
+            "text-sm text-tuatara-700 dark:text-tuatara-200",
+            "animate-in fade-in-0 zoom-in-95 duration-200"
+          )}
+        >
+          {/* Arrow */}
+          <span
+            className={cn(
+              "absolute top-full left-1/2 -translate-x-1/2",
+              "border-8 border-transparent border-t-white dark:border-t-anakiwa-950",
+              "drop-shadow-sm"
+            )}
+          />
+
+          {/* Term title */}
+          <span className="block font-semibold text-tuatara-900 dark:text-white mb-1">
+            {displayTerm}
+          </span>
+
+          {/* Category badge */}
+          {glossaryEntry?.category && (
+            <span className="inline-block px-2 py-0.5 mb-2 text-xs rounded-full bg-anakiwa-100 dark:bg-anakiwa-900 text-anakiwa-700 dark:text-anakiwa-300">
+              {glossaryEntry.category}
+            </span>
+          )}
+
+          {/* Definition */}
+          <span className="block leading-relaxed">
+            {definition}
+          </span>
+        </span>
+      )}
+    </span>
+  )
+}
diff --git a/config/site.ts b/config/site.ts
index 7260c132..2a575a03 100644
--- a/config/site.ts
+++ b/config/site.ts
@@ -9,10 +9,10 @@ export const siteConfig = {
     twitter: "https://x.com/PrivacyEthereum",
     github: "https://github.com/privacy-ethereum",
     docs: "https://ui.shadcn.com",
-    discord: "https://discord.com/invite/sF5CT5rzrR",
+    discord: "https://discord.gg/5vv7bk5u5y",
     articles: "https://pse.dev/blog",
     youtube: "https://www.youtube.com/@PrivacyEthereum",
-    jobs: "https://jobs.lever.co/ethereumfoundation/?department=Ethereum%20Foundation&team=Privacy%20and%20Scaling%20Explorations",
+    jobs: "https://jobs.ashbyhq.com/ethereum-foundation",
     termOfUse: "https://ethereum.org/en/terms-of-use/",
     privacyPolicy: "https://ethereum.org/en/privacy-policy/",
     activity:
diff --git a/content/articles/privacy-experience-report.md b/content/articles/privacy-experience-report.md
index d18fcae1..8de9ccf8 100644
--- a/content/articles/privacy-experience-report.md
+++ b/content/articles/privacy-experience-report.md
@@ -1,5 +1,5 @@
 ---
-title: "Why Users Don’t Use Privacy (Yet): Insights from On-Chain Privacy Experience"
+title: "Why Users Don't Use Privacy (Yet): Insights from On-Chain Privacy Experience"
 description: "This research examines why on-chain privacy tools see low adoption despite strong user interest, focusing on how different user profiles experience emerging privacy products. Interviews reveal that confusion about privacy guarantees, heavy and technical setup, unsafe defaults, and lack of trust/verification drive drop-off, pointing to a need for privacy UX that is transparent, testable, and human-centered rather than power-user-only."
 date: "2025-12-02"
 authors:
@@ -23,7 +23,7 @@ Our **hypothesis** was that privacy UX needs differ by both user profile and use
 
 Through qualitative interviews, we identified recurring themes across all tools tested:
 
-1. **Unclear Privacy Boundaries:** Users misunderstood what was actually private and when. Many assumed “shielded” meant fully anonymous.
+1. **Unclear Privacy Boundaries:** Users misunderstood what was actually private and when. Many assumed "shielded" meant fully anonymous.
 2. **Trust Without Proof:** Users relied on project reputation rather than verifiable evidence; they wanted on-chain or third-party proof of trustworthiness.
 3. **Overly Technical Setup:** Both technical and non-technical users found setup flows cognitively heavy and error-prone, often requiring advanced steps (ENS, RPCs, manual deployment).
 4. **Unsafe Defaults and Feedback Gaps:** Privacy options were hidden or defaulted to public. Users wanted visible privacy indicators and persistent confirmations.
@@ -34,11 +34,11 @@ Through qualitative interviews, we identified recurring themes across all tools
 
 ## **Overall Conclusion**
 
-Users don’t reject privacy, they reject _invisible, unverified, or cognitively heavy privacy_. To expand adoption, privacy tools must evolve from “power-user cryptography” to _trustable, testable, and human-centered infrastructure._
+Users don't reject privacy, they reject _invisible, unverified, or cognitively heavy privacy_. To expand adoption, privacy tools must evolve from "power-user cryptography" to _trustable, testable, and human-centered infrastructure._
 
 ## **Acknowledgements**
 
-This study would not have been possible without the pioneering work of the privacy projects we examined: [Fluidkey](https://www.fluidkey.com/), [Railgun](https://railgun.org/), [Privacy Pools](https://privacypools.com/), [Flashbots](https://www.flashbots.net/),** and [Shutter (Shielded Voting DAO)](https://www.shutter.network/shielded-voting).
+This study would not have been possible without the pioneering work of the privacy projects we examined: [Fluidkey](https://www.fluidkey.com/), [Railgun](https://railgun.org/), [Privacy Pools](https://privacypools.com/), [Flashbots](https://www.flashbots.net/), and [Shutter (Shielded Voting DAO)](https://www.shutter.network/shielded-voting).
 
 These projects represent the forefront of privacy innovation in the Ethereum ecosystem. Our intention is not to critique, but to learn from the leaders who are already shaping the future of private, verifiable, and user-respecting blockchain experiences. We are deeply grateful for their ongoing efforts to make privacy usable and accessible for all.
 
@@ -54,25 +54,25 @@ Following the task, participants reflected on their **overall experience**, disc
 
 ## Thematic affinity mapping
 
-1. _Grouping similar sentiments like “Confusing trust boundary” or “Fear of revealing info unknowingly”_
+1. _Grouping similar sentiments like "Confusing trust boundary" or "Fear of revealing info unknowingly"_
 2. _Color coding for which product each feedback came from so that you can see patterns across categories_
 
-### **Pattern 1: Confusion Around What’s Actually Private**
+### **Pattern 1: Confusion Around What's Actually Private**
 
 _Behavior: Users frequently misunderstood what data or actions were protected versus exposed._
 
-- Many assumed “shielded” meant _full anonymity_, only to discover that votes or transactions were private _temporarily_ or _partially_.
+- Many assumed "shielded" meant _full anonymity_, only to discover that votes or transactions were private _temporarily_ or _partially_.
 - Participants were unsure when privacy applied. E.g., whether frontends, relayers, or RPCs could still leak information.
 
 **Quotes & Evidence:**
 
-> “I thought shielded would mean my vote would always be private… weird that I had to hover to see details.”
+> "I thought shielded would mean my vote would always be private… weird that I had to hover to see details."
 
 ![Snapshot UI](/articles/privacy-experience-report/snapshot-UI1.webp)
 
 Snapshot UI
 
-> “There are so many leaks if I’m using Alchemy… what is the point?”
+> "There are so many leaks if I'm using Alchemy… what is the point?"
 
 ![Privacy Pool Github](/articles/privacy-experience-report/Privacy-Pool-Github_1.webp)
 
@@ -80,28 +80,28 @@ Privacy Pools Github
 
 **Design implication:**
 
-→ Tools need **explicit, contextual privacy indicators** (e.g., _“Your address is hidden until reveal phase”_) and **plain-language explanations** of privacy boundaries.
+→ Tools need **explicit, contextual privacy indicators** (e.g., _"Your address is hidden until reveal phase"_) and **plain-language explanations** of privacy boundaries.
 
 ### **Pattern 2: Lack of Trust Transparency**
 
 _Behavior: Trust decisions were driven by brand reputation, not by verifiable or visible assurances._
 
-- Users “trusted” Flashbots or Railgun because they’d heard of them, not because the interface provided proof.
+- Users "trusted" Flashbots or Railgun because they'd heard of them, not because the interface provided proof.
 - Even technically advanced users questioned how much custody or data the service retained.
 
 **Quotes:**
 
-> “I trusted Shutter because the personal risk is low and I’ve heard of them, not because the UI proved anything.”
+> "I trusted Shutter because the personal risk is low and I've heard of them, not because the UI proved anything."
 
-> “I’ve heard of Railgun before, so I’d trust it a little bit more”
+> "I've heard of Railgun before, so I'd trust it a little bit more"
 
-> “If the last release was three months ago and not many stars, I don’t feel confident.”
+> "If the last release was three months ago and not many stars, I don't feel confident."
 
 ![Railgun Github](/articles/privacy-experience-report/Railgun-Github_1.webp)
 
 Railgun Github
 
-> “Only you and Fluidkey can see all your transactions… Fluidkey team? Operator? What does that mean?”
+> "Only you and Fluidkey can see all your transactions… Fluidkey team? Operator? What does that mean?"
 
 ![Fluidkey UI](/articles/privacy-experience-report/Fluidkey-UI_1.webp)
 
@@ -115,14 +115,14 @@ Fluidkey UI
 
 _Behavior: Participants found setup flows fragmented, verbose, or opaque, especially when required to buy ENS, deploy tokens, or manage RPCs._
 
-- Even power users noted “a ton of clicks and signatures” with little feedback on what each did.
+- Even power users noted "a ton of clicks and signatures" with little feedback on what each did.
 - Non-technical users struggled to understand why new wallets, seeds, or denominations were needed.
 
 **Quotes:**
 
-> “There were a ton of clicks and signatures, I didn’t even know what I was agreeing to.”
+> "There were a ton of clicks and signatures, I didn't even know what I was agreeing to."
 
-> “Why do I need to buy an ENS just to test?”
+> "Why do I need to buy an ENS just to test?"
 
 ![Snapshot UI](/articles/privacy-experience-report/Snapshot UI_2.webp)
 
@@ -132,7 +132,7 @@ Snapshot UI
 
 Snapshot UI
 
-> “I would never trust online generated seed, that’s the basic of crypto security.”
+> "I would never trust online generated seed, that's the basic of crypto security."
 
 ![Privacy Pool UI](/articles/privacy-experience-report/Privacy Pool UI.webp)
 
@@ -146,21 +146,21 @@ Privacy Pools UI
 
 _Behavior: Users struggled with hidden controls, unclear defaults, and missing confirmations._
 
-- Privacy options were buried (“tiny text in the Voting tab”).
-- Defaults often undermined privacy (“Any” = public).
-- Feedback was fleeting or unclear (“confirmation disappears too fast”).
+- Privacy options were buried ("tiny text in the Voting tab").
+- Defaults often undermined privacy ("Any" = public).
+- Feedback was fleeting or unclear ("confirmation disappears too fast").
 
 **Quotes:**
 
-> “Defaults matter, it should default to shielded.”
+> "Defaults matter, it should default to shielded."
 
-> “Where are the privacy controls? It’s just this tiny text.”
+> "Where are the privacy controls? It's just this tiny text."
 
 ![Snapshot/Shutter UI](/articles/privacy-experience-report/Snapshot_Shutter UI_1.webp)
 
 Snapshot/Shutter UI
 
-> “If it’s private by default, that’s perfect. I shouldn’t have to think about it.”
+> "If it's private by default, that's perfect. I shouldn't have to think about it."
 
 ![Flashbot UI](/articles/privacy-experience-report/Flashbot UI_1.webp)
 
@@ -179,13 +179,13 @@ _Behavior: Users feared doing irreversible or unverified actions (e.g., sending
 
 **Quotes:**
 
-> “There’s no testing mode. I wouldn’t send 1 ETH through something untested.”
+> "There's no testing mode. I wouldn't send 1 ETH through something untested."
 
 ![Flashbot UI](/articles/privacy-experience-report/Flashbot UI_2.webp)
 
 Flashbot UI
 
-> “I want to see the contract before confirming the transaction.”
+> "I want to see the contract before confirming the transaction."
 
 ![Etherscan of Privacy Pool tx](/articles/privacy-experience-report/Etherscan of Privacy Pool tx.webp)
 
@@ -195,7 +195,7 @@ Etherscan of Privacy Pools tx
 
 Privacy Pools contract on Etherscan
 
-> “I wouldn’t download something random, even on this machine.”
+> "I wouldn't download something random, even on this machine."
 
 ![Railgun UI](/articles/privacy-experience-report/Railgun UI_1.webp)
 
@@ -210,13 +210,13 @@ Railgun UI
 _Behavior: Motivation to use privacy tools varied by context._
 
 - Some wanted privacy for governance (voting), others only for large transfers or identity separation.
-- “Compliant privacy” was seen by technical users as “not real privacy.”
+- "Compliant privacy" was seen by technical users as "not real privacy."
 
 **Quotes:**
 
-> “Compliant privacy is like giving up, it’s not really privacy at all.”
+> "Compliant privacy is like giving up, it's not really privacy at all."
 
-> “For large fund transfers I’d plan ahead, so waiting isn’t a big issue.”
+> "For large fund transfers I'd plan ahead, so waiting isn't a big issue."
 
 ![Privacy Pool UI](/articles/privacy-experience-report/Privacy Pool UI_2.webp)
 
@@ -230,18 +230,18 @@ Privacy Pools UI
 
 _Behavior: Even advanced users struggled to articulate how features like stealth addresses, shielded voting, or relayers work._
 
-- Ambiguous labels (“Power user,” “Shielded,” “ASP”) created anxiety or alienation.
+- Ambiguous labels ("Power user," "Shielded," "ASP") created anxiety or alienation.
 - Users appreciated inline explanations and step-by-step guidance.
 
 **Quotes:**
 
-> “A normal user probably doesn’t know what stealth addresses are, even I’m not sure I could define it.”
+> "A normal user probably doesn't know what stealth addresses are, even I'm not sure I could define it."
 
 ![Fluidkey UI](/articles/privacy-experience-report/Fluidkey UI_3.webp)
 
 Fluidkey UI
 
-> “‘Power user’ makes me feel like maybe I’m not technical enough.”
+> "'Power user' makes me feel like maybe I'm not technical enough."
 
 ![Fluidkey UI](/articles/privacy-experience-report/Fluidkey UI_4.webp)
 
@@ -255,20 +255,20 @@ Fluidkey UI
 
 _Behavior: Across all interviews, users consistently valued:_
 
-- **Transparency:** showing what’s happening
+- **Transparency:** showing what's happening
 - **Control:** ability to verify and customize
 - **Safety nets:** test modes, confirmations, and clear recovery paths
 - **Reputation & longevity:** older, audited, widely used projects feel safer
 
 **Quotes:**
 
-> “Anything that makes me feel a little bit more safe is important, like links to audits, social proof.”
+> "Anything that makes me feel a little bit more safe is important, like links to audits, social proof."
 
 ![Fluidkey UI](/articles/privacy-experience-report/Fluidkey UI_5.webp)
 
 Fluidkey UI
 
-> “Older apps that have been around longer feel safer.”
+> "Older apps that have been around longer feel safer."
 
 **Design implication:**
 
@@ -280,7 +280,7 @@ _Summarize the themes we identified as pain points and opportunities_
 
 | Theme                         | Core Pain Point                 | Design Opportunity                        |
 | ----------------------------- | ------------------------------- | ----------------------------------------- |
-| 1. Clarity of privacy scope   | Users can’t tell what’s private | Add visible privacy indicators            |
+| 1. Clarity of privacy scope   | Users can't tell what's private | Add visible privacy indicators            |
 | 2. Trust verification         | Users rely on brand, not proof  | Include audits and on-chain verifiability |
 | 3. Technical friction         | Setup is complex                | Simplify and guide onboarding             |
 | 4. Default behaviors          | Wrong defaults expose users     | Privacy-by-default UI                     |
@@ -300,15 +300,15 @@ This research is an open invitation to the ecosystem. We hope designers, develop
 
 2. **Expand Quantitative Understanding**
 
-   Complement this qualitative study with large-scale quantitative analysis (We’re actively collecting responses at Devconnect! Fill out [the survey here](https://pad.ethereum.org/form/#/2/form/view/IFZv0NuHEXd-eqIBh0o+C88F9V6+WVcBGKEb1d2LJcE/) for us to better understand your perspective on privacy tools). Measure and prioritize privacy needs, attitudes, and usage barriers across user segments. Like technical vs. non-technical, high vs. low privacy motivation, guiding where investment will have the most impact.
+   Complement this qualitative study with large-scale quantitative analysis (We're actively collecting responses at Devconnect! Fill out [the survey here](https://pad.ethereum.org/form/#/2/form/view/IFZv0NuHEXd-eqIBh0o+C88F9V6+WVcBGKEb1d2LJcE/) for us to better understand your perspective on privacy tools). Measure and prioritize privacy needs, attitudes, and usage barriers across user segments. Like technical vs. non-technical, high vs. low privacy motivation, guiding where investment will have the most impact.
 
 3. **Prototype and Share Solutions**
 
-   Pilot “privacy-by-default” interfaces, testnet-safe flows, and verifiable trust cues. Publish learnings openly to accelerate shared progress.
+   Pilot "privacy-by-default" interfaces, testnet-safe flows, and verifiable trust cues. Publish learnings openly to accelerate shared progress.
 
 4. **Build an Open Privacy UX Community**
 
-   If you’re a designer, developer, or researcher passionate about privacy experience, contribute ideas, case studies, or experiments. Together, we can make privacy a _default expectation,_ but not an afterthought.
+   If you're a designer, developer, or researcher passionate about privacy experience, contribute ideas, case studies, or experiments. Together, we can make privacy a _default expectation,_ but not an afterthought.
 
 5. **Broaden Role and Feature Coverage**
    This study focused on specific user roles and product features. For instance, DAO managers in governance tools or deposit flows in privacy wallets. Future research should explore the full ecosystem of participants and functionalities to provide a more holistic view of the Privacy Experience (PX) across contexts.
diff --git a/content/articles/pse-february-2026.md b/content/articles/pse-february-2026.md
new file mode 100644
index 00000000..eb7673c7
--- /dev/null
+++ b/content/articles/pse-february-2026.md
@@ -0,0 +1,96 @@
+---
+authors: ["PSE Team"]
+title: "PSE February 2026 Newsletter"
+image: "/articles/pse-february-2026/feb-cover-image.jpg"
+tldr: "Updates from Private Writes, Private Proving, and Private Reads teams covering research progress, new releases, and ecosystem collaborations."
+date: "2026-02-19"
+tags: ["newsletter"]
+---
+
+Welcome to the February edition of the PSE newsletter! Here's what our teams have been working on.
+
+---
+
+## 🏗️ Private Writes
+
+### Private Transactions Research
+
+We published an ethresearch post summarizing our findings when trying to find an alternative wormhole construction. We will also dedicate this month to hardening sonobe, in order to let protocols using our library able to deploy to production.
+
+### Private Transfer Engineering
+
+We spent December and early January conducting user research and an initial exploration into zkWormholes. The wormholes exploration was dropped due to implementation tractability, but the research team is continuing to explore ideas for an updated proposal. We spoke with 35 teams in space and uncovered the technical problems they were facing. We built these findings into our 6 month roadmap which has now been published:
+
+Part 1 of the roadmap is to publish a state of private transfers report, which analyses and benchmarks different private transfer protocols. We'll also publish our benchmarks in a live dashboard.
+
+Part 2 of the roadmap focusses on exploring L2 changes: 1) Prototyping & benchmarking new precompiles that enable application builders on L2s. 2) Speccing a native feature such as a shielded pool, in order to explore native asset privacy, and also shared features that could be used by many dapps.
+
+We have now started executing on gathering benchmarks for the state of private transfers report, and prototyping L2 precompiles for cheaper private transfer protocols.
+
+### IPTF (Institutional Privacy Task Force)
+
+December focused on Q1 planning and preparation, with the team taking time off for holidays. January shifted to execution: we delivered a hands-on workshop for a major bank in Singapore, gave talks in Hong Kong, and advanced conversations with several institutions on tokenization and stablecoins. We shipped our first Private Bonds PoC with an accompanying [write-up](https://iptf.ethereum.org/building-private-bonds-on-ethereum/). The [iptf-map](https://github.com/ethereum/iptf-map) received 8 new patterns, 12 use case stubs, and infra improvements. Published three articles on [iptf.ethereum.org](https://iptf.ethereum.org/).
+
+---
+
+## 🪢 Private Proving
+
+### iO
+
+- We have developed GPU implementations of polynomial arithmetic and polynomial matrix operations that are useful for lattice-based cryptography. The code is available in our mxx repository. In particular, multiplying polynomial matrices on a GPU is about 10× faster than on a CPU.
+- We succeeded in reducing the circuit depth of modulo-q multiplication over BGG+ encodings from more than 150 to as low as 5 per multiplication. However, this low-depth implementation requires a large number of lookup tables, so we still cannot practically evaluate such circuits over real BGG+ encodings. We are currently working on improving both circuit efficiency and lookup table evaluation techniques for BGG+ encodings.
+- We have begun exploring more active collaborations with academic researchers. If you are a researcher in lattice-based cryptography and are interested in our work, please let us know.
+
+### Mopro
+
+We've upgraded Mopro to improve the developer experience. This includes merging `wasm-bindgen` into `mopro-ffi` and creating Noir provers for Swift, Kotlin, React Native, and Flutter. For Circom, we've built provers using `circom-witnesscalc` and `arkworks`, which supports collaborations on projects focused on private proving. Additionally, we've added mobile SDK documentation for Semaphore to boost its adoption in the mobile space.
+
+Moreover, we finalized a write-up exploring the potential of client-side GPUs and how it aligns with Ethereum Foundation's long-term quantum strategy. To coordinate these efforts, we've introduced a PSE roadmap for GPU acceleration, aimed at gathering the community to build a strong foundation for defending people's privacy in everyday life.
+
+### TLSNotary
+
+We released TLSNotary Alpha.14, delivering a cleaner, faster, and more reliable experience. This update improves communication between the Prover and Verifier, enhances error reporting, and introduces new cryptographic features. We also launched a simplified browser extension that is more efficient and easier to use, with over half the codebase removed and a smoother user experience. You can try it out at [https://demo.tlsnotary.org](https://demo.tlsnotary.org/).
+
+Beyond technical improvements, we've expanded our outreach with new blog posts at https://tlsnotary.org/blog. We invite you to join our next Office Hour to ask any TLSNotary questions and connect with the team: [Office Hours Calendar](https://calendar.google.com/calendar/u/0/embed?src=c_6fe3f25063cc550e019090bb40d3d60ad5f81b3570c5a2d62c2cda96e09ff24d@group.calendar.google.com).
+
+### zkID
+
+We made solid progress across OpenAC and revocation efforts within zkID. We created the 2026 roadmap and evaluated rewriting OpenAC circuits using Bellpepper and Arkworks. Based on this analysis, we decided to continue using Circom and focus on optimizing the existing circuits.
+
+The current Circom implementation was improved, feedback on the OpenAC paper was addressed, and research on the generalized predicates feature was initiated. We also continued work on OpenAC integrations. On the revocation side, we published the blog post ["Revocation in zkID: Merkle Tree-based Approaches"](https://pse.dev/blog/revocation-in-zkid-merkle-tree-based-approaches).
+
+Next, we will focus on implementing generalized predicates, continuing integrations, and publishing a revised version of the OpenAC paper.
+
+### Client-Side Proving
+
+The work on the CSP benchmarks repo focused on expanding coverage of popular hashing circuits, ensuring measurement correctness, and improving the contributor experience. The benchmark suite gained new Keccak-256 benchmarks across multiple stacks (including Binius64, Barretenberg, Circom, RISC Zero, and ProveKit), as well as Poseidon benchmarks for Circom, Plonky2, Barretenberg, Expander, and ProveKit. Several improvements to measurement reliability and reporting were implemented as well. Finally, we have added agent contribution instructions to streamline the automated contributions - feel free to vibe-code additional benchmarks and submit a PR!
+
+On the multilinear post-quantum systems research front, we updated the HyperPlonk-WHIR and Whirlaway codebases to track the latest versions of WHIR to incorporate all the latest performance improvements. After the updates, we [reran our benchmarks](https://hackmd.io/@clientsideproving/whir-based) against the existing baseline. Both systems demonstrated excellent prover performance against the baseline. The next steps are to align them with the 128-bit security level and research ways to reduce the proof sizes before prototyping the EVM verifier.
+
+---
+
+## 🧪 Private Reads
+
+### PIR
+
+We implemented and tested the Plinko scheme on ≥100GB dataset revealing the hint generation phase is intractable (hours, days due to iPRF), but hint generation is paralleizable on GPU, with preliminary benchs indicating 8 minutes hint generation time with 50 GPUs costing <$50 total. Delegating hint generation server-side would necessitate running it inside a TEE to preserve privacy.
+
+We [specc'd and reference-implemented](https://github.com/keewoolee/rms24) the related RMS and Plinko scheme, and [started](https://github.com/igor53627/rms24-rs/tree/main) production-grade implementation of RMS based on this spec.
+
+We established a spec-driven approach to our approach to PIR schemes. Specs and reference implementations prioritize correctness and clean abstractions. Production-grade implementations are then anchored on such specs.
+
+After RMS, we also specc'd and reference-implemented Plinko following the same methodology. Despite the performance issues of Plinko, we still see it viable for large-but-immutable datasets such as Ethereum archival data.
+
+We engaged a grantee to boost our specc'ing spree and take on an additional PIR scheme. FHE-native schemes in particular are of interest.
+
+We sketched an overall multi-engine multi-dataset system design that could potentially give us the flexibility of pairing schemes with different slices of Ethereum data such that the overall performance is UX friendly all while preserving the same privacy had there been only 1 engine serving the entire Ethereum data.
+
+### UBT
+
+We continue the implementation of the end-to-end UBT pipeline in Geth by adding the path that converts MPT state into UBT, then running witness generation and verification using keeper on top of the converted state. We have also started testing UBT conversion on mainnet to serve some usecases such as PIR server.
+
+### Arti
+
+We [kicked off](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3600) collaboration with Tor Project with the aim to get Arti Tor client embeddable in browser context. Significant [progress](https://github.com/voltrevo/arti/tree/wasm-arti-client) features a [working prototype](https://github.com/voltrevo/arti/blob/wasm-arti-client/examples/tor-fetch.js), and we're now smoothing the rough edges.
+
+We submitted [PR to integrate Tor-js into ethersjs](https://github.com/ethers-io/ethers.js/pull/5083) so wallets integrating Ethersjs can route RPC calls through Tor with minimal effort. Tor-js was intended as a temporary unblocker for Tor in browser until Arti is ready for browser embedding.
diff --git a/data/glossary.ts b/data/glossary.ts
new file mode 100644
index 00000000..5b370a70
--- /dev/null
+++ b/data/glossary.ts
@@ -0,0 +1,133 @@
+export interface GlossaryEntry {
+  term: string
+  definition: string
+  category?: string
+}
+
+export const glossaryTerms: Record<string, GlossaryEntry> = {
+  // Zero Knowledge
+  "zero-knowledge": {
+    term: "Zero-Knowledge Proof",
+    definition: "A cryptographic method that allows one party to prove to another that a statement is true without revealing any additional information beyond the validity of the statement itself.",
+    category: "Cryptography"
+  },
+  "zkp": {
+    term: "ZKP (Zero-Knowledge Proof)",
+    definition: "A cryptographic method that allows one party to prove to another that a statement is true without revealing any additional information beyond the validity of the statement itself.",
+    category: "Cryptography"
+  },
+  "zk-snark": {
+    term: "zk-SNARK",
+    definition: "Zero-Knowledge Succinct Non-Interactive Argument of Knowledge. A type of zero-knowledge proof that is small in size and quick to verify, commonly used in blockchain applications.",
+    category: "Cryptography"
+  },
+  "zk-stark": {
+    term: "zk-STARK",
+    definition: "Zero-Knowledge Scalable Transparent Argument of Knowledge. A type of zero-knowledge proof that doesn't require a trusted setup and is resistant to quantum computing attacks.",
+    category: "Cryptography"
+  },
+
+  // Privacy
+  "tor": {
+    term: "Tor",
+    definition: "The Onion Router - a network that enables anonymous communication by routing traffic through multiple encrypted layers, protecting users' privacy and location.",
+    category: "Privacy"
+  },
+  "mixnet": {
+    term: "Mixnet",
+    definition: "A routing protocol that creates hard-to-trace communications by mixing messages from multiple senders, making it difficult to link senders to recipients.",
+    category: "Privacy"
+  },
+  "mpc": {
+    term: "MPC (Multi-Party Computation)",
+    definition: "A cryptographic protocol that allows multiple parties to jointly compute a function over their inputs while keeping those inputs private.",
+    category: "Cryptography"
+  },
+  "fhe": {
+    term: "FHE (Fully Homomorphic Encryption)",
+    definition: "An encryption scheme that allows computations to be performed on encrypted data without decrypting it first, producing an encrypted result.",
+    category: "Cryptography"
+  },
+
+  // Blockchain
+  "rpc": {
+    term: "RPC (Remote Procedure Call)",
+    definition: "A protocol that allows a program to request a service from another program on a different computer or network, commonly used to interact with blockchain nodes.",
+    category: "Blockchain"
+  },
+  "l2": {
+    term: "Layer 2 (L2)",
+    definition: "A secondary framework or protocol built on top of an existing blockchain (Layer 1) to improve scalability and reduce transaction costs.",
+    category: "Blockchain"
+  },
+  "rollup": {
+    term: "Rollup",
+    definition: "A Layer 2 scaling solution that executes transactions outside the main chain but posts transaction data on Layer 1, inheriting its security.",
+    category: "Blockchain"
+  },
+  "evm": {
+    term: "EVM (Ethereum Virtual Machine)",
+    definition: "The runtime environment for smart contracts in Ethereum. It executes bytecode and maintains the state of the blockchain.",
+    category: "Blockchain"
+  },
+
+  // PSE Specific
+  "pse": {
+    term: "PSE (Privacy & Scaling Explorations)",
+    definition: "A multidisciplinary team supported by the Ethereum Foundation, focused on building open-source tools for privacy and scaling in the Ethereum ecosystem.",
+    category: "Organization"
+  },
+  "semaphore": {
+    term: "Semaphore",
+    definition: "A zero-knowledge protocol that allows users to prove their membership in a group and send signals (like votes or endorsements) without revealing their identity.",
+    category: "PSE Projects"
+  },
+  "bandada": {
+    term: "Bandada",
+    definition: "An infrastructure for managing privacy-preserving groups using Semaphore, enabling anonymous group membership and signaling.",
+    category: "PSE Projects"
+  },
+  "tlsn": {
+    term: "TLSNotary",
+    definition: "A protocol that allows users to prove that specific data was received from a particular website, enabling portable data verification without revealing all content.",
+    category: "PSE Projects"
+  },
+  "zupass": {
+    term: "Zupass",
+    definition: "A zero-knowledge identity and ticketing system that allows users to prove attributes about themselves without revealing unnecessary personal information.",
+    category: "PSE Projects"
+  },
+
+  // General Crypto
+  "merkle-tree": {
+    term: "Merkle Tree",
+    definition: "A tree data structure where every leaf node contains a hash of a data block, and every non-leaf node contains a hash of its children, used for efficient data verification.",
+    category: "Cryptography"
+  },
+  "hash": {
+    term: "Hash Function",
+    definition: "A mathematical function that converts input data of any size into a fixed-size output (hash), which is deterministic and practically impossible to reverse.",
+    category: "Cryptography"
+  },
+  "commitment": {
+    term: "Commitment Scheme",
+    definition: "A cryptographic primitive that allows one to commit to a chosen value while keeping it hidden, with the ability to reveal it later.",
+    category: "Cryptography"
+  }
+}
+
+// Helper function to find a term (case-insensitive)
+export function findGlossaryTerm(searchTerm: string): GlossaryEntry | undefined {
+  const normalized = searchTerm.toLowerCase().replace(/\s+/g, "-")
+  return glossaryTerms[normalized]
+}
+
+// Get all terms as an array
+export function getAllGlossaryTerms(): GlossaryEntry[] {
+  return Object.values(glossaryTerms)
+}
+
+// Get terms by category
+export function getTermsByCategory(category: string): GlossaryEntry[] {
+  return Object.values(glossaryTerms).filter(entry => entry.category === category)
+}
diff --git a/public/articles/pse-february-2026/feb-cover-image.jpg b/public/articles/pse-february-2026/feb-cover-image.jpg
new file mode 100644
index 00000000..fcda3e34
Binary files /dev/null and b/public/articles/pse-february-2026/feb-cover-image.jpg differ