diff --git a/articles/tlsnotary-updates.md b/articles/tlsnotary-updates.md
index 43bbb78..e2caa61 100644
--- a/articles/tlsnotary-updates.md
+++ b/articles/tlsnotary-updates.md
@@ -116,7 +116,7 @@ A key observation enabling our approach is that all private inputs from the Veri
 
 Malicious secure protocols typically aim to prevent _any_ leakage of any parties inputs, employing techniques such as authenticated garbling or variants of cut-and-choose, which add significant compute and/or communication overhead.
 
-For our needs, we implemented a novel\* variant of so-called Dual Execution, which we dubbed Dual Execution with Asymmetric Privacy (DEAP). Is there a better name for it? Probably. Nonetheless, you can read our informal [explanation of it here](https://docs.tlsnotary.org/mpc/deap.html).
+For our needs, we implemented a novel\* variant of so-called Dual Execution, which we dubbed Dual Execution with Asymmetric Privacy (DEAP). Is there a better name for it? Probably. Nonetheless, you can read our informal [explanation of it here](https://tlsnotary.org/docs/mpc/deap).
 
 The jist of it is this: During the TLS session one party, the Prover, acts as the Garbler while also committing to their inputs prior to learning the output of the circuit. Later, these commitments are used to prove the Prover acted honestly (or at least leakage was statistically bounded), and aborting otherwise.
 
diff --git a/data/projects/tlsn.ts b/data/projects/tlsn.ts
index bd5aab1..604dbd6 100644
--- a/data/projects/tlsn.ts
+++ b/data/projects/tlsn.ts
@@ -50,13 +50,13 @@ export const tlsn: ProjectInterface = {
     play: [
       {
         label: "Getting started",
-        url: "https://docs.tlsnotary.org/quick_start/index.html",
+        url: "https://tlsnotary.org/docs/quick_start/",
       },
     ],
     learn: [
       {
         label: "Documentation",
-        url: "https://docs.tlsnotary.org",
+        url: "https://tlsnotary.org/docs",
       },
     ],
   },