diff --git a/astro-i18next.config.ts b/astro-i18next.config.ts
index d191ee33b..2b3e6b322 100644
--- a/astro-i18next.config.ts
+++ b/astro-i18next.config.ts
@@ -2,6 +2,6 @@
 export default {
   defaultLocale: "en",
   showDefaultLocale: true,
-  locales: ["en", "zh"],
+  locales: ["en", "zh", "es"],
   load: ["server", "client"],
 }
diff --git a/public/locales/en/translation.json b/public/locales/en/translation.json
index 73586261b..e5b4c44e5 100644
--- a/public/locales/en/translation.json
+++ b/public/locales/en/translation.json
@@ -1,4 +1,15 @@
 {
+  "rightSidebar": {
+    "onThisPage": "On This Page",
+    "more": "More",
+    "editThisPage": "Edit this page",
+    "joinOurCommunity": "Join our community",
+    "feedback": "Feedback"
+  },
+  "ui": {
+    "whatsNext": "What's Next",
+    "readMore": "Read More"
+  },
   "landing": {
     "test": "test",
     "search": {
diff --git a/public/locales/es/translation.json b/public/locales/es/translation.json
index 261ba69ce..8c177c20d 100644
--- a/public/locales/es/translation.json
+++ b/public/locales/es/translation.json
@@ -1,5 +1,148 @@
 {
+  "rightSidebar": {
+    "onThisPage": "En esta página",
+    "more": "Más",
+    "editThisPage": "Editar esta página",
+    "joinOurCommunity": "Únete a nuestro Discord",
+    "feedback": "Feedback"
+  },
+  "ui": {
+    "whatsNext": "¿Qué sigue?",
+    "readMore": "Leer Más"
+  },
+  "landing": {
+    "test": "test",
+    "search": {
+      "title": "Bienvenido a la Documentación de Scroll",
+      "placeholder": "Buscar Documentación de Scroll..."
+    },
+    "newUserCTA": {
+      "title": "Nuevo en Scroll y los ZK Rollups?",
+      "description": "Aprende lo básico en la Guía de Inicio"
+    },
+    "resourcesCTA": {
+      "title": "Recursos Útiles"
+    },
+    "nodesCTA": {
+      "title": "Necesitas correr tu propio Nodo de Scroll?",
+      "description": "Consulte la Guía del Operador de Nodos para obtener más información sobre la puesta en marcha y el mantenimiento de los Nodos de Scroll.",
+      "buttonText": "Guía del Operador de Nodos"
+    },
+    "TutorialsCTA": {
+      "title": "Ver tutoriales",
+      "description": "Obtenga más información sobre la tecnología que estamos construyendo. Subimos constantemente nuevos vídeos a nuestro canal de YouTube.",
+      "buttonText": "Ver tutoriales"
+    },
+    "LinksCTA": {
+      "card1": {
+        "title": "¿Necesita ayuda para integrarse?",
+        "description": "Talk to an expert once we TODO: a url"
+      },
+      "card2": {
+        "title": "Discord",
+        "description": "Únete a nuestra Comunidad"
+      },
+      "card3": {
+        "title": "TODO: Discourse",
+        "description": "Really, join the community"
+      }
+    },
+    "NewsletterCTA": {
+      "title": "Stay updated on the latest Scroll news",
+      "placeholder": "Enter your email address",
+      "buttonText": "Sign up"
+    }
+  },
+  "sidebar": {
+    "gettingStarted": {
+      "gettingStarted": "Primeros Pasos",
+      "overview": "Vista General",
+      "scrollSepoliaTestnet": "Scroll Sepolia Testnet",
+      "userGuide": "Guía de Usuario",
+      "setup": "Configuración",
+      "faucet": "Faucet",
+      "bridge": "Bridge",
+      "transferTokens": "Transferencia de Tokens",
+      "commonErrors": "Errores Comunes",
+      "rollupExplorer": "Rollup Explorer",
+      "scrollSepoliaBlockExplorer": "Scroll Sepolia Explorer",
+      "sepoliaBlockExplorer": "Sepolia Explorer",
+      "community": "Comunidad",
+      "discord": "Discord",
+      "communityForum": "Forum de la Comunidad"
+    },
+    "developers": {
+      "developers": "Desarrolladores",
+      "buildingOnScroll": "Construyendo en Scroll",
+      "developerQuickstart": "Inicio rápido para Desarrolladores",
+      "verifyingSmartContracts": "Verificando Smart Contracts",
+      "scrollContracts": "Contratos de Scroll",
+      "ethereumAndScrollDifferences": "Diferencias entre Scroll y Ethereum",
+      "l1AndL2Bridging": "L1 y L2 Bridging",
+      "ethAndErc20TokenBridge": "ETH y ERC20 Token Bridge",
+      "erc721NftBridge": "ERC721 NFT Bridge",
+      "erc1155TokenBridge": "ERC1155 Token Bridge",
+      "theScrollMessenger": "El Scroll Messenger",
+      "transactionFeesOnScroll": "Comisiones de Transacciones en Scroll",
+      "l2Fee": "Comisión L2",
+      "l1Fee": "Comisión L1",
+      "gasOracle": "Gas Oracle",
+      "future": "Futuro",
+      "guides": "Guías",
+      "contractDeploymentTutorial": "Tutorial de Despliegue de Contratos",
+      "crossChainInteraction": "Interacción Cross-chain del Scroll Messenger",
+      "bridgingERC20TokenThroughCustomGateway": "Bridging de un ERC20 a través de una Gateway Personalizada",
+      "bridgingERC721NftThroughCustomGateway": "Bridging de un ERC721 NFT a través de una Gateway Personalizada",
+      "bridgingERC1155ThroughCustomGateway": "Bridging de un ERC1155 a través de una Gateway Personalizada",
+      "estimatingGasAndTxFees": "Estimación de las Tarifas de Gas y Tx",
+      "resources": "Recursos",
+      "rollupExplorer": "Rollup Explorer",
+      "scrollSepoliaBlockExplorer": "Scroll Sepolia Explorer",
+      "sepoliaBlockExplorer": "Sepolia Explorer"
+    },
+    "technology": {
+      "introduction": "Introducción",
+      "principles": "Principios",
+      "scrollArchitecture": "Arquitectura de Scroll",
+      "overview": "Vista General",
+
+      "scrollChain": "Scroll Chain",
+      "accountsAndState": "Cuentas y Estado",
+      "blocks": "Bloques",
+      "transactions": "Transacciones",
+      "rollupProcess": "Proceso del Rollup",
+      "evmDifferencesFromEthereum": "Diferencias de EVM respecto a Ethereum",
+
+      "bridge": "Bridge",
+      "crossDomainMessaging": "Cross-Domain Messaging",
+      "depositGateways": "Gateways de Depósito",
+      "withdrawGateways": "Gateways de Retiro",
+
+      "sequencer": "Secuenciador",
+      "executionNode": "Nodo de Ejecución",
+      "rollupNode": "Nodo Rollup",
+      "zkTrie": "zkTrie",
+
+      "zkevm": "zkEVM",
+      "introToZkevm": "Intro a la zkEVM",
+      "zkevmOverview": "Vista General de la zkEVM",
+      "bridgeOverview": "Vista General del Bridge",
+      "prover": "Prover",
+      "proofGeneration": "Proof Generation",
+      "cpuProverRepo": "CPU Prover Repo"
+    },
+    "learn": {
+      "ethereumAndProtocols": "Ethereum y Protocolos",
+      "theScalabilityProblem": "El Problema de la Escalabilidad",
+      "introToRollups": "Intro a los Rollups",
+      "zeroKnowledge": "Zero Knowledge",
+      "introToZeroKnowledge": "Intro a la Zero Knowledge",
+      "polynomialCommitmentSchemes": "Esquemas de Compromiso Polinómicos",
+      "kzgCommitmentScheme": "Esquema de Compromiso KZG",
+      "additionalResources": "Recursos Adicionales"
+    }
+  },
   "notTranslated": {
-    "notTranslated": "Esta página aún no ha sido traducida."
+    "notTranslated": "Esta página no ha sido traducida aún."
   }
 }
diff --git a/src/components/NavCard.astro b/src/components/NavCard.astro
index 8c8678504..dfcd8e10f 100644
--- a/src/components/NavCard.astro
+++ b/src/components/NavCard.astro
@@ -1,4 +1,5 @@
 ---
+import i18next, { t } from "i18next"
 export type Props = {
   icon: string
   name: string
@@ -17,7 +18,7 @@ const { icon, name, content, link } = Astro.props as Props
   <span class="navs-item-title">{name}</span>
   <span class="navs-item-content">{content}</span>
   <a class="navs-item-link" href={link}>
-    Read more
+    {t("ui.readMore")}
     <span class="link-icon"></span>
   </a>
 </div>
diff --git a/src/components/PageContent/WhatsNext.astro b/src/components/PageContent/WhatsNext.astro
index f201197a6..2e21d4258 100644
--- a/src/components/PageContent/WhatsNext.astro
+++ b/src/components/PageContent/WhatsNext.astro
@@ -1,10 +1,11 @@
 ---
+import i18next, { t } from "i18next"
 export type Props = { content: Record<string, string> }
 const { content = {} } = Astro.props as Props
 ---
 
 <section>
-  <h4>Whats Next</h4>
+  <h4>{t("ui.whatsNext")}</h4>
   <ul class="whats-next">
     {
       Object.keys(content).map((key) => (
diff --git a/src/components/RightSidebar/MoreMenu.astro b/src/components/RightSidebar/MoreMenu.astro
index 5909a56d4..b5191170e 100644
--- a/src/components/RightSidebar/MoreMenu.astro
+++ b/src/components/RightSidebar/MoreMenu.astro
@@ -1,10 +1,11 @@
 ---
+import i18next, { t } from "i18next"
 import * as CONFIG from "../../config"
 const { editHref } = Astro.props
 const showMoreSection = CONFIG.COMMUNITY_INVITE_URL || editHref
 ---
 
-{showMoreSection && <h2 class="heading">More</h2>}
+{showMoreSection && <h2 class="heading">{t("rightSidebar.more")}</h2>}
 <ul>
   {
     editHref && (
@@ -27,7 +28,7 @@ const showMoreSection = CONFIG.COMMUNITY_INVITE_URL || editHref
               </clipPath>
             </defs>
           </svg>
-          <span>Edit this page</span>
+          <span>{t("rightSidebar.editThisPage")}</span>
         </a>
       </li>
     )
@@ -56,7 +57,7 @@ const showMoreSection = CONFIG.COMMUNITY_INVITE_URL || editHref
               fill="currentColor"
             />
           </svg>
-          <span>Join our community</span>
+          <span>{t("rightSidebar.joinOurCommunity")}</span>
         </a>
       </li>
     )
diff --git a/src/components/RightSidebar/RightSidebar.astro b/src/components/RightSidebar/RightSidebar.astro
index 6b46c32f3..d26ad856c 100644
--- a/src/components/RightSidebar/RightSidebar.astro
+++ b/src/components/RightSidebar/RightSidebar.astro
@@ -1,4 +1,5 @@
 ---
+import i18next, { t } from "i18next"
 import TableOfContents from "./TableOfContents"
 import MoreMenu from "./MoreMenu.astro"
 import { Feedback } from "../PageContent/Feedback"
@@ -15,7 +16,7 @@ const { content, githubEditUrl, headings, clientSideToc } = Astro.props
     </div>
 
     <div>
-      <h2 class="heading feedback-title">Feedback</h2>
+      <h2 class="heading feedback-title">{t("rightSidebar.feedback")}</h2>
       <div class="feedback-wrapper">
         <Feedback client:idle />
       </div>
diff --git a/src/components/RightSidebar/TableOfContents/index.tsx b/src/components/RightSidebar/TableOfContents/index.tsx
index 37ab33571..f9e22ea1b 100644
--- a/src/components/RightSidebar/TableOfContents/index.tsx
+++ b/src/components/RightSidebar/TableOfContents/index.tsx
@@ -3,6 +3,8 @@ import { useStore } from "@nanostores/preact"
 import type { FunctionalComponent } from "preact"
 import { useState, useEffect, useRef } from "preact/hooks"
 import { shouldUpdateToc } from "./tocStore"
+import i18next, { t } from "i18next"
+
 export interface Heading {
   depth: number
   text: string
@@ -79,7 +81,7 @@ const TableOfContents: FunctionalComponent<{
 
   return (
     <>
-      <h2 className="heading">On this page</h2>
+      <h2 className="heading">{t("rightSidebar.onThisPage")}</h2>
       <ul ref={tableOfContents}>
         {headings
           .filter(({ depth }) => depth > 1 && depth < 4)
diff --git a/src/config/menu.ts b/src/config/menu.ts
index 36636386b..75d3c9f38 100644
--- a/src/config/menu.ts
+++ b/src/config/menu.ts
@@ -27,4 +27,14 @@ export const MENU: MenuItems = {
     { text: "技术", link: "/zh/technology", section: "technology" },
     { text: "学习", link: "/zh/learn", section: "learn" },
   ],
+  es: [
+    {
+      text: "¿Cómo empezar?",
+      link: "/es/getting-started/overview",
+      section: "gettingStarted",
+    },
+    { text: "Desarrolladores", link: "/es/developers", section: "developers" },
+    { text: "Tecnología", link: "/es/technology", section: "technology" },
+    { text: "Aprende", link: "/es/learn", section: "learn" },
+  ],
 }
diff --git a/src/config/sidebar.ts b/src/config/sidebar.ts
index 281d76fab..dff7ea04d 100644
--- a/src/config/sidebar.ts
+++ b/src/config/sidebar.ts
@@ -62,7 +62,7 @@ export const getSidebar = () => {
     ],
     developers: [
       {
-        section: "Developers",
+        section: t("sidebar.developers.developers"),
         contents: [
           { title: t("sidebar.developers.buildingOnScroll"), url: formatUrl("developers") },
           { title: t("sidebar.developers.developerQuickstart"), url: formatUrl("developers/developer-quickstart") },
@@ -125,7 +125,7 @@ export const getSidebar = () => {
         ],
       },
       {
-        section: "Guides",
+        section: t("sidebar.developers.guides"),
         contents: [
           {
             title: t("sidebar.developers.contractDeploymentTutorial"),
@@ -154,7 +154,7 @@ export const getSidebar = () => {
         ],
       },
       {
-        section: "Resources",
+        section: t("sidebar.developers.resources"),
         contents: [
           { title: t("sidebar.developers.rollupExplorer"), url: "https://scroll.io/rollupscan" },
           { title: t("sidebar.developers.scrollSepoliaBlockExplorer"), url: "https://sepolia-blockscout.scroll.io/" },
@@ -164,8 +164,8 @@ export const getSidebar = () => {
     ],
     technology: [
       {
-        section: "Overview",
-        contents: [{ title: t("Scroll Architecture"), url: formatUrl("technology") }],
+        section: t("sidebar.technology.overview"),
+        contents: [{ title: t("sidebar.technology.scrollArchitecture"), url: formatUrl("technology") }],
       },
       {
         section: t("sidebar.technology.scrollChain"),
diff --git a/src/content/docs/es/article-components.mdx b/src/content/docs/es/article-components.mdx
new file mode 100644
index 000000000..96b4a2f63
--- /dev/null
+++ b/src/content/docs/es/article-components.mdx
@@ -0,0 +1,164 @@
+---
+section: gettingStarted
+title: "Article Components"
+date: Last Modified
+lang: "en"
+permalink: "/article-components"
+excerpt: "Learn more about the topics of Ethereum Scalability and Zero Knowledge Cryptography"
+whatsnext: { "Next Up Page 1": "/", "Second Next Up Page": "/" }
+---
+
+import ClickToZoom from "../../../components/ClickToZoom.astro"
+import priceAggr from "../../../assets/images/contract-devs/price-aggr.png"
+import ToggleElement from "../../../components/ToggleElement.astro"
+import Aside from "../../../components/Aside.astro"
+import MarkmapView from "../../../components/MarkmapView/index.astro"
+
+This is body text right under the article title. It typically is just paragraph text that's pretty straightforward. Then there's **bold text**, and _italic text_, and **_bold-italic text_**, and `inline-code` and **`bold inline code`** and even _`italic inline code`_ and **_`bold italic inline code`_**. And of course don't forget [links](#), and [**bold links**](#), and [_italic links_](#), and [**_bold-italic links_**](#).
+
+## Markdown Components (also an H2 Heading)
+
+- We've also got unordered lists!
+- They can have multiple items.
+  - And some sub-items.
+  - That get into details
+- That's an unordered list.
+
+What else do we have?
+
+1. Of course there's also ordered lists.
+1. They look like this.
+1. They're pretty useful.
+
+### H3 Heading
+
+#### H4 Heading
+
+##### H5 Heading
+
+Let's see a horizontal rule.
+
+---
+
+We define the Square-Fibonacci sequence[^1], a variation of the Fibonacci sequence:
+
+### Math
+
+- Let $f_0 = 1, f_1 = 1$
+- For $$i \geq 2$$, define $f_{i} := (f_{i-2})^2 + (f_{i-1})^2 \mod q$
+  - Where $q$ is a large prime integer. We use this modulus to bound the size of each element, so that it can be represented by some predetermined number of bits.
+
+### Tables
+
+| Syntax    | Description |
+| --------- | ----------- |
+| Header    | Title       |
+| Paragraph | Text        |
+
+### Blockquotes
+
+> #### Success
+>
+> Vitae reprehenderit at aliquid error voluptates eum dignissimos.
+
+### Footnotes
+
+Here's a simple footnote,[^1] and here's a longer one.[^bignote]
+
+[^1]: This is the first footnote.
+[^bignote]: Here's one with multiple paragraphs and code.
+
+### Callout that worked in MD, but might not in MDX?
+
+:::tip[Did you know?]
+Astro helps you build faster websites with “Islands Architecture”.
+:::
+
+## Imported MDX Components
+
+### Callouts
+
+<Aside type="note" title="note">
+  {" "}
+  Astro helps you build faster websites with “Islands Architecture”.{" "}
+</Aside>
+<Aside type="caution" title="caution">
+  {" "}
+  Astro helps you build faster websites with “Islands Architecture”.{" "}
+</Aside>
+<Aside type="danger" title="danger">
+  {" "}
+  Astro helps you build faster websites with “Islands Architecture”.{" "}
+</Aside>
+
+<Aside type="tip" title="tip">
+  For .md file you can use this code.
+</Aside>
+
+```
+:::tip[Did you know?]
+ Astro helps you build faster websites with “Islands Architecture”.
+:::
+```
+
+### Images zoom
+
+<ClickToZoom src={priceAggr} />
+
+### Toggle
+
+<ToggleElement anchor="Why build on Scroll?">
+  <div slot="title">Why build on Scroll?</div>
+  <p>
+    Scroll enables creators to turn their content into interactive, explorable experiences. With Scroll, you can create
+    rich, interactive stories that engage readers, provide a better user experience, and help you stand out from the
+    crowd.
+  </p>
+</ToggleElement>
+<ToggleElement anchor="How does Scroll work?">
+  <div slot="title">How does Scroll work?</div>
+  <p>
+    Scroll combines powerful technologies like WebGL and WebRTC to create immersive, interactive experiences. The
+    platform allows you to build 3D environments, add interactivity, and embed content from popular web services to
+    create a unique, engaging experience for your audience.
+  </p>
+</ToggleElement>
+<ToggleElement anchor="What can I build with Scroll?">
+  <div slot="title">What can I build with Scroll?</div>
+  <p>
+    You can build a wide range of experiences with Scroll, from interactive articles to immersive product demos and
+    virtual tours. Scroll is designed to help you create engaging, interactive experiences that elevate your content and
+    captivate your audience.
+  </p>
+</ToggleElement>
+
+### Markmap
+
+#### Referenced File
+
+<MarkmapView src="/samples/markmap.md" />
+
+<MarkmapView>
+[](#markmap)markmap
+===================
+
+- beautiful2
+- useful
+- easy
+- interactive
+
+</MarkmapView>
+
+### Mermaid
+
+```mermaid
+stateDiagram
+    Step --> StepState
+    Step --> CellManager
+    ConstraintBuilder --> CellManager
+    CellManager --> ProofSystem(Halo2)
+    StepState --> ExecutionState
+    StepState --> step_context
+    ExecutionState --> ConstraintBuilder
+    step_context --> ConstraintBuilder
+```
diff --git a/src/content/docs/es/developers/_images/enforcedTxData.png b/src/content/docs/es/developers/_images/enforcedTxData.png
new file mode 100644
index 000000000..55b8c612e
Binary files /dev/null and b/src/content/docs/es/developers/_images/enforcedTxData.png differ
diff --git a/src/content/docs/es/developers/_images/enforcedTxSepoliascan.png b/src/content/docs/es/developers/_images/enforcedTxSepoliascan.png
new file mode 100644
index 000000000..c23a1e435
Binary files /dev/null and b/src/content/docs/es/developers/_images/enforcedTxSepoliascan.png differ
diff --git a/src/content/docs/es/developers/_images/injectedProviderMM.png b/src/content/docs/es/developers/_images/injectedProviderMM.png
new file mode 100644
index 000000000..816517512
Binary files /dev/null and b/src/content/docs/es/developers/_images/injectedProviderMM.png differ
diff --git a/src/content/docs/es/developers/_images/mmNetworkSelection.png b/src/content/docs/es/developers/_images/mmNetworkSelection.png
new file mode 100644
index 000000000..e86176f9b
Binary files /dev/null and b/src/content/docs/es/developers/_images/mmNetworkSelection.png differ
diff --git a/src/content/docs/es/developers/_images/verify1.png b/src/content/docs/es/developers/_images/verify1.png
new file mode 100644
index 000000000..b27db86bb
Binary files /dev/null and b/src/content/docs/es/developers/_images/verify1.png differ
diff --git a/src/content/docs/es/developers/developer-quickstart.mdx b/src/content/docs/es/developers/developer-quickstart.mdx
new file mode 100644
index 000000000..2fd9a3eea
--- /dev/null
+++ b/src/content/docs/es/developers/developer-quickstart.mdx
@@ -0,0 +1,222 @@
+---
+section: developers
+date: Last Modified
+title: "Inicio rápido para desarrolladores"
+lang: "es"
+permalink: "developers/developer-quickstart"
+excerpt: "Scroll Developer Quickstart te ayuda a adquirir testnet Ether, configurar tu red y acceder a todas tus herramientas favoritas"
+whatsnext: { "Verifica Tus Smart Contracts": "/es/developers/verifying-smart-contracts" }
+---
+
+import Aside from "../../../../components/Aside.astro"
+import ClickToZoom from "../../../../components/ClickToZoom.astro"
+import networkSelection from "./_images/mmNetworkSelection.png"
+import injectedProviderMM from "./_images/injectedProviderMM.png"
+
+Con Scroll, tus herramientas favoritas para la creación y prueba de smart contracts funcionan de manera intuitiva.
+
+Dado que Scroll es equivalente en código de bytes con la EVM, sólo tendrás que dirijir tus herramientas de creación favoritas a un proveedor RPC de Scroll Sepolia Testnet.
+
+Si tienes algún problema, ponte en contacto con nosotros en [nuestro Discord](https://discord.gg/scroll).
+
+## Adquiriendo Testnet Ether
+
+Para empezar a construir en Scroll, primero tendrás que adquirir algunos ETH de testnet. Consulta la página [Faucet](/es/user-guide/faucet) para obtener consejos sobre la obtención de tokens de la testnet Sepolia. Después de esto, podrás transferir sus testnet ETH a la Scroll Sepolia Testnet (Layer 2) utilizando nuestro [Bridge](/es/user-guide/bridge).
+
+Para obtener más información, consulta la página de [Setup](/es/user-guide/bridge) de la Guía del usuario.
+
+## Configuración de red
+
+Utiliza la siguiente tabla para configurar sus herramientas de Ethereum para la Scroll Sepolia Testnet.
+
+| Nombre de red      | Scroll Sepolia Testnet                                                        | Sepolia Testnet                                                              |
+| ------------------ | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
+| RPC URL            | [https://sepolia-rpc.scroll.io/](https://sepolia-rpc.scroll.io/)              | [https://eth-sepolia-public.unifra.io](https://eth-sepolia-public.unifra.io) |
+| Chain ID           | 534351                                                                        | 11155111                                                                     |
+| Currency Symbol    | ETH                                                                           | ETH                                                                          |
+| Block Explorer URL | [https://sepolia-blockscout.scroll.io](https://sepolia-blockscout.scroll.io/) | [https://sepolia.etherscan.io](https://sepolia.etherscan.io)                 |
+
+## Configura tus herramientas
+
+<Aside type="tip" title="">
+  Para configurar las herramientas de verificación de un lanzamiento de smart contract, consulta [Verificando Smart
+  Contracts](/es/developers/verifying-smart-contracts).
+</Aside>
+
+### Hardhat
+
+Modifica tu archivo de configuración de Hardhat `hardhat.config.ts` para que se dirija al RPC público de Scroll Sepolia Testnet.
+
+```jsx
+...
+
+const config: HardhatUserConfig = {
+  ...
+  networks: {
+    scrollSepolia: {
+      url: "https://sepolia-rpc.scroll.io/" || "",
+      accounts:
+        process.env.PRIVATE_KEY !== undefined ? [process.env.PRIVATE_KEY] : [],
+    },
+  },
+};
+
+...
+```
+
+### Foundry
+
+Para desplegar utilizando el RPC público de Scroll Sepolia Testnet, ejecuta:
+
+```bash
+forge create ... --rpc-url=https://sepolia-rpc.scroll.io/ --legacy
+```
+
+### Remix Web IDE
+
+Después de compilar tus contratos, la forma más fácil de desplegar usando Remix es [configurando Metamask](/es/user-guide/setup#metamask) y seleccionando la red **Scroll Sepolia Testnet**.
+
+<ClickToZoom src={networkSelection} />
+
+Ahora, en la pestaña "Deploy and Run Transactions", utiliza el desplegable "Environment" y selecciona "Injected Provider - MetaMask."
+
+<ClickToZoom src={injectedProviderMM} />
+
+Conecta tu wallet y selecciona el Scroll Sepolia Testnet. Tu cuenta debería seleccionarse automáticamente en Remix, y despues, puedes hacer clic en "Deploy."
+
+### Truffle
+
+Asumiendo que ya tienes un entorno de Truffle configurado, ve al [archivo de configuración](https://trufflesuite.com/docs/truffle/reference/configuration/) de Truffle, `truffle.js`. Asegúrate de tener instalado HDWalletProvider: `npm install @truffle/hdwallet-provider@1.4.0`
+
+```js
+const HDWalletProvider = require("@truffle/hdwallet-provider")
+...
+module.exports = {
+  networks: {
+    scrollSepolia: {
+      provider: () =>
+        new HDWalletProvider(process.env.PRIVATE_KEY, "https://sepolia-rpc.scroll.io/"),
+      network_id: '*',
+    },
+  }
+}
+```
+
+### Brownie
+
+Para añadir la Scroll Sepolia Testnet, ejecuta el siguiente comando:
+
+```bash
+brownie networks add Ethereum scrollSepolia host=https://sepolia-rpc.scroll.io/ chainid=534351
+```
+
+Para establecer esta red como predeterminada, añade lo siguiente en el archivo de configuración del proyecto:
+
+```yaml
+networks:
+  default: scrollSepolia
+```
+
+Otra forma de añadir el Scroll Sepolia Testnet es crear un archivo `yaml` y ejecutar un comando para añadirlo.
+
+Este es un ejemplo de un archivo yaml llamado `network-config.yaml`.
+
+```yaml
+live:
+- name: Ethereum
+ networks:
+ - chainid: 534351
+   explorer: https://sepolia-blockscout.scroll.io/
+   host: https://sepolia-rpc.scroll.io
+   id: scrollSepolia
+   name: Scroll Sepolia Testnet
+```
+
+Para añadir la Scroll Sepolia Testnet a la lista de redes, ejecuta el siguiente comando:
+
+```bash
+brownie networks import ./network-config.yaml
+```
+
+Para desplegar en Scroll, ejecuta el siguiente comando. En este ejemplo, `token.py` es el script para desplegar el smart contract. Sustitúyelo por el nombre de tu script:
+
+```bash
+brownie run token.py --network scrollSepolia
+```
+
+### ethers.js
+
+Configuración de un proveedor de Scroll Sepolia Testnet en un script de `ethers`:
+
+```jsx
+import { ethers } from "ethers"
+
+const provider = new ethers.providers.JsonRpcProvider("https://sepolia-rpc.scroll.io/")
+```
+
+### scaffold-eth
+
+Para desplegar usando Scaffold-eth, necesitarás dirigir tus configuraciones de Hardhat y React a la Testnet de Scroll Sepolia.
+
+#### Configure el Hardhat
+
+En el archivo `packages/hardhat/hardhat.config.js`, añadirás la red y la seleccionarás como red por defecto.
+
+```jsx
+...
+//
+// Select the network you want to deploy to here:
+//
+const defaultNetwork = "scrollSepolia";
+...
+module.exports = {
+...
+	networks: {
+...
+          scrollSepolia: {
+            url: "https://sepolia-rpc.scroll.io/",
+            accounts: {
+              mnemonic: mnemonic(),
+            },
+          },
+	}
+...
+}
+```
+
+Asegúrate de también agregar fondos en la wallet de despliegue. Ejecuta `yarn generate` para crear la wallet y `yarn account` para verificar sus fondos. Una vez tengas fondos, ejecuta `yarn deploy --network scrollSepolia` para desplegarlo en la Scroll Sepolia testnet.
+
+<Aside type="danger" title="alerta">
+  En algunos forks de proyectos, querrás desactivar la verificación de contratos, pues esta depende de Etherscan. Esto puede ser
+  comentado en `packages/hardhat/deploy/00_deploy_your_contract.js`.
+</Aside>
+
+#### Configura el Frontend
+
+Para configurar tu frontend, tienes que añadir la Scroll Sepolia Testnet como opción de red, y luego seleccionarla como predeterminado.
+
+Para añadir la red, modifica `packages/react-app/src/constants.js`.
+
+```jsx
+...
+export const NETWORKS = {
+...
+  scrollSepolia: {
+    name: "scrollSepolia",
+    color: "#e9d0b8",
+    chainId: 534351,
+    rpcUrl: "https://sepolia-rpc.scroll.io/",
+    blockExplorer: "https://sepolia-blockscout.scroll.io",
+  },
+...
+}
+```
+
+A continuación, en `packages/react-app/src/App.jsx` modifica
+
+```jsx
+...
+/// 📡 What chain are your contracts deployed to?
+const initialNetwork = NETWORKS.scrollSepolia;
+...
+```
diff --git a/src/content/docs/es/developers/ethereum-and-scroll-differences.mdx b/src/content/docs/es/developers/ethereum-and-scroll-differences.mdx
new file mode 100644
index 000000000..d34ceabd8
--- /dev/null
+++ b/src/content/docs/es/developers/ethereum-and-scroll-differences.mdx
@@ -0,0 +1,103 @@
+---
+section: developers
+date: Last Modified
+title: "Diferencias entre Scroll y Ethereum"
+lang: "es"
+permalink: "developers/ethereum-and-scroll-differences"
+whatsnext: { "L1 y L2 Bridging": "/es/developers/l1-and-l2-bridging" }
+excerpt: "Hay una serie de detalles técnicos que difieren entre el EVM de Ethereum mainnet y el diseño modificado de Scroll para un zkEVM. A continuación puedes ver esas diferencias tal y como existen ahora."
+---
+
+import Aside from "../../../../components/Aside.astro"
+
+Ciertos detalles técnicos difieren entre el EVM de Ethereum mainnet y el diseño de una zkEVM modificado por Scroll. A continuación puedes ver esas diferencias tal y como existen en Scroll Sepolia.
+
+Los colaboradores de código abierto y los desarrolladores de infraestructura pueden ponerse en contacto con nuestro equipo para obtener ayuda adicional.
+
+<Aside type="tip" title="No te preocupes!">
+  Para el desarrollador Solidity promedio, estos detalles no afectarán la experiencia de desarrollador.
+</Aside>
+
+## Opcodes de la EVM
+
+| Opcode                      | Equivalente en Solidity | Comportamiento en Scroll                                                                                            |
+| --------------------------- | ----------------------- | ---------------------------------------------------------------------------------------------------------- |
+| `BLOCKHASH`                 | `block.blockhash`       | Regresa un `keccak(chain_id \|\| block_number)` por los últimos 256 bloques.                                      |
+| `COINBASE`                  | `block.coinbase`        | Regresa el address del pre-deploy del `Fee Vault`. Observa [Contractos de Scroll](/es/developers/scroll-contracts). |
+| `DIFFICULTY` / `PREVRANDAO` | `block.difficulty`      | Regresa 0.                                                                                                 |
+| `BASEFEE`                   | `block.basefee`         | Deshabilitado.[^eip1559] Si se encuentra el opcode, la transacción se revertirá.                        |
+| `SELFDESTRUCT`              | `selfdestruct`          | Deshabilitado. Si se encuentra el opcode, la transacción se revertirá.[^willadpot]                      |
+
+[^eip1559]: Actualmente hemos deshabilitado la EIP-1559 en Scroll.
+[^willadpot]: Cambiará para adoptar la solución de Ethereum en el futuro.
+
+## Los precompilados de la EVM
+
+Los precompilados `SHA2-256` (address `0x2`), `RIPEMD-160` (address `0x3`), y `blake2f` (address `0x9`) actualmente no estan soportados. Las llamadas a estos contratos precompilados se revertirán. Planeamos habilitar estos tres precompilados en un futuro hard fork.
+
+El precompilado `modexp` esta habilitado pero solo soporta entradas con un tamaño igual o menor a 32 bytes (i.e. `u256`).
+
+El precompilado `ecPairing` esta soportado, pero el número de puntos (sets, pairs) esta limitado a 4, en lugar de 6.
+
+Los todos otros precompilados EVM estan habilitados: `ecRecover`, `identity`, `ecAdd`, `ecMul`.
+
+## State Account
+
+### **Campos Adicionales**
+
+Hemos añadido 2 campos adicionales al objeto `StateAccount` actual: `PoseidonCodehash` y `CodeSize`.
+
+```go
+type StateAccount struct {
+	Nonce    uint64
+	Balance  *big.Int
+	Root     common.Hash // merkle root of the storage trie
+	KeccakCodeHash []byte // still the Keccak codehash
+	// added fields
+	PoseidonCodeHash []byte // the Poseidon codehash
+	CodeSize uint64
+}
+```
+
+### **CodeHash**
+
+En relación con esto, mantenemos dos tipos de codehash para cada bytecode de contrato: hash de Keccak y hash de Poseidon.
+
+`KeccakCodeHash` se mantiene para conservar la compatibilidad con `EXTCODEHASH`. `PoseidonCodeHash` se utiliza para verificar la corrección de los bytecodes cargados en la zkEVM, donde el hasheo de Poseidon es mucho más eficiente.
+
+### CodeSize
+
+A la hora de verificar el "EXTCODESIZE", resulta costoso cargar todos los datos del contrato en la zkEVM. En su lugar, almacenamos el tamaño del contrato durante la creación del mismo. De esta manera, no necesitamos cargar el código - una storage proof es suficiente para verificar este opcode.
+
+## Tiempo de Bloques
+
+El Testnet de Sepolia apunta a tener un tiempo de bloque constante de 3 segundos. Esto es más corto y consistente que los 12 segundos utilizados en Ethereum en condiciones ideales.
+
+Esto se eligió por dos razones:
+
+- Tener un tiempo de bloque más rápido y constante se traduce en una respuesta más rápida y una mejor experiencia de usuario.
+- A medida que optimizamos los circuitos de la zkEVM en nuestras redes de prueba, incluso si mantenemos un límite de gas menor por bloque o lote, podemos alcanzar un rendimiento superior al de Ethereum.
+
+## EIPs Futuros
+
+Seguimos de cerca todas las EIP emergentes adoptadas por Ethereum y las adoptamos cuando es conveniente. Si estás interesado en más detalles, ponte en contacto con nosotros en [nuestro foro de la comunidad](https://community.scroll.io) o en [Scroll Discord](https://discord.gg/scroll).
+
+## Versión del compilador de la EVM
+
+Para garantizar que no se produzca ningún comportamiento inesperado en sus contratos, recomendamos utilizar `london` como versión de referencia al compilar sus smart contracts.
+
+Puedes leer con más detalle las diferencias entre el hard fork de Shanghai y London en la [Ethereum Execution spec](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md) y cómo la nueva instrucción `PUSH0` [afecta al compilador de Solidity](https://blog.soliditylang.org/2023/05/10/solidity-0.8.20-release-announcement/).
+
+## Comisiones de Transacciones
+
+La comisión aplicada a las transacciones de Scroll Sepolia consta de dos partes:
+
+- **Comisión de gas en L2:** similar a L1, el importe de la comisión de ejecución en L2 es igual a `L2_gas_price * L2_gas_used`, cubriendo los siguientes costos:
+  - Costo de ejecución y almacenamiento del secuenciador en L2
+  - Costo de verificación y finalización de la prueba de validez en L1
+  - Costo del prover
+- **Comisión de datos en L1:** comisión adicional sobre la comisión de gas en L2. La comisión de datos en L1 sólo se cobra a las transacciones iniciadas en L2, no a las iniciadas en L1. La tarifa cubre el costo del envío de datos a L1 para la disponibilidad de datos. Dado que agrupamos los datos y los guardamos en L1 (el concepto del rollup), la comisión de transferencia a L1 se calcula en función del tamaño de los datos de la tx.
+
+Para obtener más información, consulta [Comisiones de Transacciones en Scroll](/es/developers/transaction-fees-on-scroll).
+
+---
diff --git a/src/content/docs/es/developers/guides/bridge-erc20-through-the-custom-gateway.mdx b/src/content/docs/es/developers/guides/bridge-erc20-through-the-custom-gateway.mdx
new file mode 100644
index 000000000..154103898
--- /dev/null
+++ b/src/content/docs/es/developers/guides/bridge-erc20-through-the-custom-gateway.mdx
@@ -0,0 +1,354 @@
+---
+section: developers
+date: Last Modified
+title: "Bridging de un ERC20 a través de una Gateway Personalizada"
+lang: "es"
+permalink: "developers/guides/bridge-erc20-through-the-custom-gateway"
+excerpt: "Esta guía explica cómo utilizar el bridge de Scroll para las ERC20 que necesitan funcionalidades personalizadas utilizando el Custom Gateway.."
+---
+
+import Aside from "../../../../../components/Aside.astro"
+
+En esta guía se explica cómo utilizar el bridge de Scroll para los ERC20 que necesitan una funcionalidad personalizada mediante el uso de una Gateway Personalizada.
+
+<Aside type="tip" title="¿Necesitas una lógica personalizada?">
+  Recuerda que, en muchos contextos, no necesitarás utilizar la Gateway personalizada para añadir funciones adicionales a tu token o a 
+  tu lógica de bridging. Consulta el artículo sobre [ETH y ERC20 Token Bridge](/es/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge#deposit-eth-and-erc20-tokens-from-l1) para más información.
+</Aside>
+
+## Paso 1: Lanza un token en Sepolia
+
+En primer lugar, necesitamos un token para hacer bridging. No hay necesidad de una implementación ERC20 en particular para que un token sea compatible con L2. Si ya tienes un token, puedes saltarte este paso. Si deseas desplegar un nuevo token, utiliza el siguiente contrato de un token ERC20 que emite 1 millón de tokens al deployer cuando se lanza.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.16;
+
+import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
+
+contract L1Token is ERC20 {
+  constructor() ERC20("My Token L1", "MTL1") {
+    _mint(msg.sender, 1_000_000 ether);
+  }
+}
+```
+
+## Paso 2: Lanzar el token contraparte en Scroll Sepolia testnet
+
+A continuación, lanzarás un token homólogo a este token en Scroll, que representará al token original en Sepolia. Este token puede implementar una lógica personalizada para que coincida con la del token en L1 o incluso añadir funciones adicionales más allá de las del token en L1.
+
+Para que funcione:
+
+- El token debe implementar la interfaz `IScrollStandardERC20` para ser compatible con el bridge.
+- El contrato debe proporcionar la dirección de la gateway y las direcciones del token homólogo (el token L1 que acabamos de lanzar) bajo las funciones `gateway()` y `counterpart()`. También debe permitir que la gateway en L2 llame a las funciones token `mint()` y `burn()`, que se llaman cuando se deposita y se retira un token.
+
+A continuación se muestra un ejemplo completo de un token compatible con el bridge. Al constructor se le pasa la dirección oficial de la Gateway Personalizada de Scroll (`0x31C994F2017E71b82fd4D8118F140c81215bbb37`) y la dirección del token lanzado en Sepolia.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.16;
+
+import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
+import "@scroll-tech/contracts@0.1.0/libraries/token/IScrollERC20Extension.sol";
+
+contract L2Token is ERC20, IScrollERC20Extension {
+  // Almacenamos la gateway y la dirección del token L1 para proporcionar las funciones gateway() y counterpart() que se necesitan desde la interfaz Scroll Standard ERC20
+  address _gateway;
+  address _counterpart;
+
+  // En el constructor pasaremos como parámetros la Gateway Personalizada L2 y como parámetros la dirección del token L1
+  constructor(address gateway_, address counterpart_) ERC20("My Token L2", "MTL2") {
+    _gateway = gateway_;
+    _counterpart = counterpart_;
+  }
+
+  function gateway() public view returns (address) {
+    return _gateway;
+  }
+
+  function counterpart() external view returns (address) {
+    return _counterpart;
+  }
+
+  // Permitimos la emisión sólo a la Gateway para que pueda emitir nuevos tokens cuando se conecte desde L1.
+  function transferAndCall(address receiver, uint256 amount, bytes calldata data) external returns (bool success) {
+    transfer(receiver, amount);
+    data;
+    return true;
+  }
+
+  // Permitimos la emisión sólo a la Gateway para que pueda emitir nuevos tokens cuando se conecte desde L1.
+  function mint(address _to, uint256 _amount) external onlyGateway {
+    _mint(_to, _amount);
+  }
+
+  // Al igual que en la emisión, la Gateway puede quemar tokens al pasar de L2 a L1.
+  function burn(address _from, uint256 _amount) external onlyGateway {
+    _burn(_from, _amount);
+  }
+
+  modifier onlyGateway() {
+    require(gateway() == _msgSender(), "Ownable: caller is not the gateway");
+    _;
+  }
+}
+```
+
+## Paso 3: Adición del token al Scroll Bridge
+
+Debes ponerte en contacto con el equipo de Scroll para añadir el token al contrato `L2CustomERC20Gateway` en Scroll y al contrato `L1CustomERC20Gateway` en L1. Además, sigue las instrucciones del repositorio [token lists](https://github.com/scroll-tech/token-list) para añadir su token al frontend oficial del Scroll bridge.
+
+## Paso 4: Depósito de tokens
+
+Una vez que tu token haya sido aprobado por el equipo de Scroll, deberías poder depositar tokens desde L1. Para ello, primero debes aprobar la dirección del contrato `L1CustomGateway` en Sepolia (`0x31C994F2017E71b82fd4D8118F140c81215bbb37`). Luego, deposita los tokens llamando a la función `depositERC20` desde el contrato `L1CustomGateway`. Esto se puede hacer usando [nuestro bridge](https://scroll.io/bridge), [Etherscan Sepolia](https://sepolia.etherscan.io/address/0x31C994F2017E71b82fd4D8118F140c81215bbb37#writeProxyContract), o un smart contract.
+
+## Paso 5: Retiro de tokens
+
+Deberás seguir pasos similares para enviar tokens de vuelta de L2 a L1. En primer lugar, aprueba la dirección `L2CustomGateway` (`0x058dec71E53079F9ED053F3a0bBca877F6f3eAcf`) y, después retira los tokens llamando al comando `withdrawERC20` del contrato `L2CustomGateway`.
+
+## Modo Alternativo: Lanzar y configurar un contrato de gateway personalizada
+
+Añadir tu token al bridge oficial de Scroll (como se ha descrito anteriormente) es el método recomendado para conectar tokens hacia y desde Scroll. Este método hará que sean más fáciles de descubrir y más seguros para los holders. Sin embargo, requerirá la aprobación del equipo de Scroll. Si deseas lanzar un token personalizado sin el proceso de aprobación oficial, puedes lanzar una gateway personalizada tú mismo. Para ello, tendrás que desplegar un contrato `L1CustomERC20Gateway` en L1 y un `L2CustomERC20Gateway` en L2.
+
+### Lanzamiento de una Gateway Personalizada en L1
+
+Empecemos lanzando el siguiente contrato en Sepolia.
+
+```solidity
+// SPDX-License-Identifier: MIT
+
+// Aunque es posible utilizar otras versiones de Solidity, recomendamos utilizar la versión 0.8.16 porque es en la que se auditaron nuestros contratos
+pragma solidity =0.8.16;
+
+import "@openzeppelin/contracts/access/Ownable.sol";
+
+import { IL2ERC20Gateway } from "@scroll-tech/contracts@0.1.0/L2/gateways/IL2ERC20Gateway.sol";
+import { IL1ScrollMessenger } from "@scroll-tech/contracts@0.1.0/L1/IL1ScrollMessenger.sol";
+import { IL1ERC20Gateway } from "@scroll-tech/contracts@0.1.0/L1/gateways/IL1ERC20Gateway.sol";
+
+import { ScrollGatewayBase } from "@scroll-tech/contracts@0.1.0/libraries/gateway/ScrollGatewayBase.sol";
+import { L1ERC20Gateway } from "@scroll-tech/contracts@0.1.0/L1/gateways/L1ERC20Gateway.sol";
+
+// Este contrato se utilizará para enviar y recibir tokens de L2
+contract L1CustomERC20Gateway is L1ERC20Gateway, Ownable {
+  // Los tokens deben ser mapeados para "vincularlos" a un token que represente el token original en el original. Este evento se emitirá cuando se actualice el mapeado de tokens para tokens ERC20.
+  event UpdateTokenMapping(address indexed l1Token, address indexed oldL2Token, address indexed newL2Token);
+
+  mapping(address => address) public tokenMapping;
+
+  constructor() {}
+
+  // Esta función debe llamarse una vez después de haber desplegado el contrato L1 y L2
+  function initialize(address _counterpart, address _router, address _messenger) external {
+    require(_router != address(0), "zero router address");
+
+    ScrollGatewayBase._initialize(_counterpart, _router, _messenger);
+  }
+
+  /// Esta función devuelve la dirección del token en L2
+  function getL2ERC20Address(address _l1Token) public view override returns (address) {
+    return tokenMapping[_l1Token];
+  }
+
+  // Actualiza el mapeo de tokens que "vincula" un token con otro de la otra cadena.
+  function updateTokenMapping(address _l1Token, address _l2Token) external onlyOwner {
+    require(_l2Token != address(0), "token address cannot be 0");
+
+    address _oldL2Token = tokenMapping[_l1Token];
+    tokenMapping[_l1Token] = _l2Token;
+
+    emit UpdateTokenMapping(_l1Token, _oldL2Token, _l2Token);
+  }
+
+  // Callback antes de retirar un token en L1
+  function _beforeFinalizeWithdrawERC20(
+    address _l1Token,
+    address _l2Token,
+    address,
+    address,
+    uint256,
+    bytes calldata
+  ) internal virtual override {
+    require(msg.value == 0, "nonzero msg.value");
+    require(_l2Token != address(0), "token address cannot be 0");
+    require(_l2Token == tokenMapping[_l1Token], "l2 token mismatch");
+  }
+
+  // Los tokens que han sido transferidos pueden ser "cancelados" o anulados. Esta callback es llamada antes de que eso ocurra.
+  function _beforeDropMessage(address, address, uint256) internal virtual override {
+    require(msg.value == 0, "nonzero msg.value");
+  }
+
+  // Función interna que mantiene la lógica del depósito
+  function _deposit(
+    address _token,
+    address _to,
+    uint256 _amount,
+    bytes memory _data,
+    uint256 _gasLimit
+  ) internal virtual override nonReentrant {
+    address _l2Token = tokenMapping[_token];
+    require(_l2Token != address(0), "no corresponding l2 token");
+
+    // 1. Transfiere el token a este contrato.
+    address _from;
+    (_from, _amount, _data) = _transferERC20In(_token, _amount, _data);
+
+    // 2. Genera el mensaje pasado a L2CustomERC20Gateway.
+    bytes memory _message = abi.encodeCall(
+      IL2ERC20Gateway.finalizeDepositERC20,
+      (_token, _l2Token, _from, _to, _amount, _data)
+    );
+
+    // 3. Envía el mensaje a L1ScrollMessenger.
+    IL1ScrollMessenger(messenger).sendMessage{ value: msg.value }(counterpart, 0, _message, _gasLimit, _from);
+
+    emit DepositERC20(_token, _l2Token, _from, _to, _amount, _data);
+  }
+}
+```
+
+### Lanzamiento de una Gateway personalizada en L2
+
+Ahora vamos a lanzar el contrato homólogo en Scroll.
+
+```solidity
+// SPDX-License-Identifier: MIT
+
+pragma solidity =0.8.16;
+
+import "@openzeppelin/contracts/access/Ownable.sol";
+
+import "@scroll-tech/contracts@0.1.0/L2/gateways/L2ERC20Gateway.sol";
+import { IL2ScrollMessenger } from "@scroll-tech/contracts@0.1.0/L2/IL2ScrollMessenger.sol";
+import { IL1ERC20Gateway } from "@scroll-tech/contracts@0.1.0/L1/gateways/IL1ERC20Gateway.sol";
+import { ScrollGatewayBase } from "@scroll-tech/contracts@0.1.0/libraries/gateway/ScrollGatewayBase.sol";
+import "@scroll-tech/contracts@0.1.0/libraries/token/IScrollERC20Extension.sol";
+
+import { IL2ERC20Gateway } from "@scroll-tech/contracts@0.1.0/L2/gateways/IL2ERC20Gateway.sol";
+
+// Este contrato se utilizará para enviar y recibir tokens de L1
+contract L2CustomERC20Gateway is L2ERC20Gateway, ScrollGatewayBase, Ownable {
+  event UpdateTokenMapping(address indexed l2Token, address indexed oldL1Token, address indexed newL1Token);
+
+  // solhint-disable-next-line var-name-mixedcase
+  mapping(address => address) public tokenMapping;
+
+  constructor() {}
+
+  // Al igual que con la versión L1 de la Gateway, debe ejecutarse una vez que se hayan desplegado las gateways en L1 y L2.
+  function initialize(address _counterpart, address _router, address _messenger) external {
+    require(_router != address(0), "zero router address");
+
+    ScrollGatewayBase._initialize(_counterpart, _router, _messenger);
+  }
+
+  /// Devuelve la dirección del token que representa el token en L2
+  function getL1ERC20Address(address _l2Token) external view override returns (address) {
+    return tokenMapping[_l2Token];
+  }
+
+  // Esto devuelve la dirección del token L2
+  function getL2ERC20Address(address) public pure override returns (address) {
+    revert("unimplemented");
+  }
+
+  // Esta función finaliza el depósito de tokens en L2 cuando el depósito no se ha finalizado debido a que no se ha enviado suficiente gas desde L1.
+  function finalizeDepositERC20(
+    address _l1Token,
+    address _l2Token,
+    address _from,
+    address _to,
+    uint256 _amount,
+    bytes calldata _data
+  ) external payable override onlyCallByCounterpart nonReentrant {
+    require(msg.value == 0, "nonzero msg.value");
+    require(_l1Token != address(0), "token address cannot be 0");
+    require(_l1Token == tokenMapping[_l2Token], "l1 token mismatch");
+
+    IScrollERC20Extension(_l2Token).mint(_to, _amount);
+
+    _doCallback(_to, _data);
+
+    emit FinalizeDepositERC20(_l1Token, _l2Token, _from, _to, _amount, _data);
+  }
+
+  // Igual que en la versión L1 de este contrato, esta función "vincula" un token con otro token de la otra cadena.
+  function updateTokenMapping(address _l2Token, address _l1Token) external onlyOwner {
+    require(_l1Token != address(0), "token address cannot be 0");
+
+    address _oldL1Token = tokenMapping[_l2Token];
+    tokenMapping[_l2Token] = _l1Token;
+
+    emit UpdateTokenMapping(_l2Token, _oldL1Token, _l1Token);
+  }
+
+  // Función interna que mantiene la lógica de retirada
+  function _withdraw(
+    address _token,
+    address _to,
+    uint256 _amount,
+    bytes memory _data,
+    uint256 _gasLimit
+  ) internal virtual override nonReentrant {
+    address _l1Token = tokenMapping[_token];
+    require(_l1Token != address(0), "no corresponding l1 token");
+
+    require(_amount > 0, "withdraw zero amount");
+
+    // 1. Extrae el remitente real si esta llamada es desde L2GatewayRouter.
+    address _from = msg.sender;
+    if (router == msg.sender) {
+      (_from, _data) = abi.decode(_data, (address, bytes));
+    }
+
+    // 2. Quema los tokens
+    IScrollERC20Extension(_token).burn(_from, _amount);
+
+    // 3. Genera el mensaje pasado a L1StandardERC20Gateway.
+    bytes memory _message = abi.encodeCall(
+      IL1ERC20Gateway.finalizeWithdrawERC20,
+      (_l1Token, _token, _from, _to, _amount, _data)
+    );
+
+    // 4. Envía el mensaje a L2ScrollMessenger
+    IL2ScrollMessenger(messenger).sendMessage{ value: msg.value }(counterpart, 0, _message, _gasLimit);
+
+    emit WithdrawERC20(_l1Token, _token, _from, _to, _amount, _data);
+  }
+}
+```
+
+### Configure su contrato Gateway en Sepolia
+
+Una vez desplegados los contratos, llama a las siguientes funciones para inicializar los contratos y vincularlos a los tokens correspondientes y a la gateway al otro lado del bridge.
+
+Primero, llama a la función `initialize` en el contrato `MyL1Gateway` con los siguientes parámetros:
+
+- `_counterpart`: La dirección de `MyL2Gateway` que acabamos de lanzar en Scroll.
+- `_router`: Coloca `0x13FBE0D0e5552b8c9c4AE9e2435F38f37355998a`, el contrato `L1GatewayRouter` de Sepolia.
+- `_messenger`: Coloca `0x50c7d3e7f7c656493D1D76aaa1a836CedfCBB16A`, el contrato `L1ScrollMessenger` de Sepolia.
+
+Una gateway personalizada puede alojar múltiples bridges de tokens. En este caso, sólo permitiremos el bridging entre L1Token y L2Token llamando a la función `updateTokenMapping` en el contrato `MyL1Gateway` con los siguientes parámetros:
+
+- `_l1Token`: La dirección del contrato `L1Token` que lanzamos previamente en Sepolia.
+- `_l2Token`: La dirección del contrato `L2Token` que lanzamos previamente en Scroll.
+
+### Configura tu contrato Gateway en Scroll
+
+Ahora cambiemos a la cadena Scroll e inicialicemos `MyL2Gateway`, siguiendo pasos similares.
+
+Primero, llama a la función `initialize` de `MyL2Gateway`:
+
+- `_counterpart`: La dirección de `MyL1Gateway` que acabamos de lanzar en Sepolia.
+- `_router`: Coloca `0x9aD3c5617eCAa556d6E166787A97081907171230`, el contrato `L2GatewayRouter` de Scroll.
+- `_messenger`: Coloca `0xBa50f5340FB9F3Bd074bD638c9BE13eCB36E603d`, el contrato `L2ScrollMessenger` de Scroll.
+
+A continuación, llama a `updateTokenMapping` en el contrato `MyL2Gateway`:
+
+- `_l2Token`: La dirección del contrato `L2Token` que lanzamos previamente en Scroll.
+- `_l1Token`: La dirección del contrato `L1Token` que lanzamos previamente en Sepolia.
+
+### Bridging de tokens
+
+Ahora podemos llamar a `depositERC20` desde `MyL1Gateway` y a `withdrawERC20` desde `MyL2Gateway` igual que con el bridge oficial de Scroll.
diff --git a/src/content/docs/es/developers/guides/contract-deployment-tutorial.mdx b/src/content/docs/es/developers/guides/contract-deployment-tutorial.mdx
new file mode 100644
index 000000000..d9a682864
--- /dev/null
+++ b/src/content/docs/es/developers/guides/contract-deployment-tutorial.mdx
@@ -0,0 +1,85 @@
+---
+section: developers
+date: Last Modified
+title: "Tutorial de Despliegue de Contratos"
+lang: "es"
+permalink: "developers/guides/contract-deployment-tutorial"
+excerpt: "La Testnet de Scroll Sepolia permite a la comunidad desplegar smart contracts en Scroll. En este tutorial, te enseñaremos a desplegar un contrato en Scroll Sepolia."
+whatsnext: { "Interacción Cross-chain del Scroll Messenger": "/es/developers/guides/scroll-messenger-cross-chain-interaction" }
+---
+
+import Aside from "../../../../../components/Aside.astro"
+
+La Testnet de Scroll Sepolia permite a cualquiera desplegar un smart contract en Scroll. En este tutorial, aprenderás a desplegar un contrato en Scroll Sepolia utilizando herramientas comunes para desarrollar en Ethereum. Este [demo repo](https://github.com/scroll-tech/scroll-guides/tree/main/contract-deploy-demo) ilustra el despliegue de contratos con [Hardhat](https://hardhat.org/) y [Foundry](https://github.com/foundry-rs/foundry).
+
+<Aside type="tip" title="¿Tienes Testnet ETH?">
+  Antes de empezar a desplegar el contrato, tienes que solicitar tokens de la testnet a través de un faucet de Sepolia y utilizar la función
+[bridge](https://scroll.io/bridge) para transferir algunos ETH de prueba de _Sepolia_ a _Scroll Sepolia_. Como alternativa puedes
+  adquirir directamente ETH de Scroll Sepolia. Consulta nuestras guías [Faucet](/es/user-guide/faucet/) y [Bridge](/es/user-guide/bridge/)
+  para obtener ayuda.
+</Aside>
+
+## Despliegue de contratos con Hardhat
+
+1. Si aún no lo has hecho, instala [nodejs](https://nodejs.org/en/download/) y [yarn](https://classic.yarnpkg.com/lang/en/docs/install).
+2. Clona el repositorio e instala las dependencias:
+
+   ```shell
+   git clone https://github.com/scroll-tech/scroll-guides.git
+   cd scroll-guides/contract-deploy-demo
+   yarn install
+   ```
+
+3. Crea un archivo `.env` siguiendo el ejemplo `.env.example` en el directorio raíz. Cambia `PRIVATE_KEY` por la clave privada de tu propia cuenta en el `.env`.
+
+4. Ejecuta `yarn compile` para compilar el contrato.
+
+5. Ejecuta `yarn deploy:scrollTestnet` para desplegar el contrato en la Scroll Sepolia Testnet.
+
+6. Ejecuta `yarn test` para realizar las pruebas hardhat.
+
+## Despliegue de contratos con Foundry
+
+1. Clona el repositorio:
+
+   ```shell
+   git clone https://github.com/scroll-tech/scroll-guides.git
+   cd scroll-guides/contract-deploy-demo
+   ```
+
+2. Instala el Foundry:
+
+   ```shell
+   curl -L https://foundry.paradigm.xyz | bash
+   foundryup
+   ```
+
+3. Ejecuta `forge build` para construir el proyecto.
+
+4. Despliega tu contrato con Foundry:
+
+   ```bash
+   forge create --rpc-url https://sepolia-rpc.scroll.io/ \
+     --value <lock_amount> \
+     --constructor-args <unlock_time> \
+     --private-key <your_private_key> \
+     --legacy \
+     contracts/Lock.sol:Lock
+   ```
+
+   - `<lock_amount>` es la cantidad de `ETH` de prueba que se bloqueará en el contrato. Intenta establecer una cantidad pequeña, como `0.0000001ether`.&#x20;
+   - `<unlock_time>` es la marca de tiempo Unix después de la cual los fondos bloqueados en el contrato estarán disponibles para su retirada. Intenta ponerlo en algún timestamp Unix en el futuro, como `1696118400` (este timestamp Unix corresponde al 1 de Octubre de 2023).
+
+   Por ejemplo:
+
+   ```bash
+   forge create --rpc-url https://sepolia-rpc.scroll.io/ \
+     --value 0.00000000002ether \
+     --constructor-args 1696118400 \
+     --private-key 0xabc123abc123abc123abc123abc123abc123abc123abc123abc123abc123abc1 \
+     --legacy contracts/Lock.sol:Lock
+   ```
+
+## Preguntas y Feedback
+
+Gracias por participar y desarrollar en la Scroll Sepolia Testnet. Si tienes algún problema, únete a nuestro [Discord](https://discord.gg/scroll) y pregúntanos en el canal `#testnet-devs`.
diff --git a/src/content/docs/es/developers/guides/estimating-gas-and-tx-fees.mdx b/src/content/docs/es/developers/guides/estimating-gas-and-tx-fees.mdx
new file mode 100644
index 000000000..68629e130
--- /dev/null
+++ b/src/content/docs/es/developers/guides/estimating-gas-and-tx-fees.mdx
@@ -0,0 +1,227 @@
+---
+section: developers
+date: Last Modified
+title: "Estimating Gas and Tx Fees"
+lang: "en"
+permalink: "developers/guides/estimating-gas-and-transaction-fees"
+excerpt: "Since Scroll is an L2 rollup, part of the transaction lifecycle is committing some data to L1 for security. To pay for this, all transaction incurs an additional fee called the L1 fee"
+---
+
+import Aside from "../../../../../components/Aside.astro"
+import ClickToZoom from "../../../../../components/ClickToZoom.astro"
+import txFeesProjectStructure from "../../../../../assets/images/developers/txFeesProjectStructure.png"
+
+{/* TODO: Update for Sepolia, test and publish to sidebar. */}
+
+:::warning[This article is out of date.]
+This page has not been updated and tested against the latest Scroll Sepolia release. Please use with caution.
+:::
+
+Since Scroll is an L2 rollup, part of the transaction lifecycle is committing some data to L1 for security. To pay for this, all transaction incurs an additional fee called the _L1 fee_.
+
+In this guide, we will go over how to estimate the L1 fee on Scroll and calculate final transaction fee estimations through a hands-on code example you can find [here](https://github.com/scroll-tech/scroll-guides/tree/main/gas-estimation-demo).
+
+## The formula
+
+In short, the transaction fee on Scroll, at any given moment, can be calculated as
+
+```
+totalFee = (l2GasPrice * l2GasUsed) + l1Fee
+```
+
+An important distinction we need to make is that `l1Fee` is separated from the `l2Fee`.
+
+For a more comprehensive explanation and details on the formula, check the documentation on [how Transaction Fees work on Scroll](../developers/transaction-fees-on-scroll-l2/).
+
+## Interfacing with values
+
+To fetch these values and calculate the final fee, we’ll interact with Scroll’s public RPC and pre-deployed Smart Contract L1GasOracle.sol, which is deployed at [`TODO: 0x5300000000000000000000000000000000000002`](TODO: https://blockscout.scroll.io/address/0x5300000000000000000000000000000000000002)
+
+For our example codebase, we make a Hardhat project and fetch values using the [Ethers.js](https://docs.ethers.org/v6/) library.
+
+`l2GasUsed` - We get this using the [estimateGas](https://docs.ethers.org/v6/api/providers/#Provider-estimateGas) method, which queries our RPC with the TX data to get an estimate of the gas to be used.
+
+`l2GasPrice` - For this, we’ll use the [getFeeData](https://docs.ethers.org/v6/api/providers/#Provider-getFeeData) method, which will get the current market conditions on the L2
+
+The Gas Oracle smart contract exposes multiple key fields we need to figure out the cost of the transaction. `overhead()` , `scalar()` , `l1BaseFee()` and `getL1GasUsed(bytes memory data)`
+
+But it also exposes the `getL1Fee(bytes memory data)` function, which abstracts all these complexities and allows us to get the fee in just one function call.
+
+## Hands-on example
+
+### Project structure
+
+First of all, let’s quickly go over the key folders inside our project structure.
+
+It’s a standard Hardhat project, but most of our work is inside the c*ontracts* and _scripts_ folders.
+
+<ClickToZoom src={txFeesProjectStructure} />
+
+<Aside type="tip" title="">
+  This tutorial will review the critical parts of the code, using the example code as an easy way to get an overview of
+  what’s done in the project. Some code, like error handling, will be excluded for simplicity.
+</Aside>
+
+### The smart contract
+
+First, we need a Smart Contract to interact with to showcase the gas estimation. For that, we’ll create a `ExampleContract.sol`.
+
+```solidity
+pragma solidity ^0.8.17;
+
+contract ExampleContract {
+  uint public exampleVariable;
+
+  function setExampleVariable(uint _exampleVariable) external {
+    exampleVariable = _exampleVariable;
+  }
+}
+```
+
+<Aside type="tip" title="">
+  Remember the `setExampleVariable` method signature since we’ll use it later as an example
+</Aside>
+
+Once deployed, we fill the `EXAMPLE_CONTRACT_ADDRESS` value in our `.env` file. For the example project, it’s already deployed at `TODO: 0xc37ee92c73753B46eB865Ee156d89741ad0a8777` and pre-filled, so nothing has to be done here.
+
+### Estimating the fees
+
+The central part of the example lives in the `/scripts/gasEstimation.ts` file.
+
+We’ll do just four things:
+
+1. Create a dummy transaction using the ExampleContract
+2. Estimate the L2 fee of that transaction
+3. Estimate the L1 fee of that transaction
+4. Emit an actual transaction to Scroll and compare the values
+
+#### Creating the dummy transaction
+
+The goal of this step is to create an **(RLP) Serialized Unsigned Transaction** to be used later on as the parameter for calling the oracle gas estimation method.
+
+1. Let’s populate our transaction with the needed values to estimate its cost by calling `buildPopulatedExampleContractTransaction`. This will fill the `data`, `to`, `gasPrice`, `type` and `gasLimit` fields:
+
+```typescript
+export async function buildPopulatedExampleContractTransaction(
+  exampleContractAddress: string,
+  newValueToSet: number
+): Promise<ContractTransaction> {
+  const exampleContract = await ethers.getContractAt("ExampleContract", exampleContractAddress)
+
+  return exampleContract.setExampleVariable.populateTransaction(newValueToSet)
+}
+```
+
+2. Now, let’s trim it down to the basic fields using `buildUnsignedTransaction`. We won’t be signing it.
+
+```typescript
+export async function buildUnsignedTransaction(signer: HardhatEthersSigner, populatedTransaction: ContractTransaction): Promise<UnsignedTransaction> {
+  const nonce = await signer.getNonce();
+
+  return {
+    data: populatedTransaction.data,
+    to: populatedTransaction.to,
+    gasPrice: populatedTransaction.gasPrice,
+    type: populatedTransaction.type,
+    gasLimit: populatedTransaction.gasLimit,
+    nonce,
+  };
+```
+
+<Aside type="tip" title="">
+  Make sure that the nonce is a valid one!
+</Aside>
+
+3. With the output of the previous function, we serialize it using `getSerializedTransaction`
+
+```typescript
+export function getSerializedTransaction(tx: UnsignedTransaction) {
+  return serialize(tx)
+}
+```
+
+#### Estimating the L2 fee
+
+This step is pretty standard and the same as on Ethereum. We’ll use the `estimateL2Fee` function which takes the populated transaction as an input and returns an estimate of the total gas it will use by multiplying the current gas price and gas needed to be used.
+
+```typescript
+export async function estimateL2Fee(tx: ContractTransaction): Promise<bigint> {
+  const gasToUse = await ethers.provider.estimateGas(tx)
+  const feeData = await ethers.provider.getFeeData()
+  const gasPrice = feeData.gasPrice
+
+  return gasToUse * gasPrice
+}
+```
+
+#### Estimating the L1 fee of that transaction
+
+This step is very straightforward. Using the output of the `getSerializedTransaction` function, we query the oracle and get the estimated fee in return.
+
+```typescript
+export async function estimateL1Fee(
+  gasOraclePrecompileAddress: string,
+  unsignedSerializedTransaction: string
+): Promise<bigint> {
+  const l1GasOracle = await ethers.getContractAt("IL1GasPriceOracle", gasOraclePrecompileAddress)
+
+  return l1GasOracle.getL1Fee(unsignedSerializedTransaction)
+}
+```
+
+#### Emitting the transaction and comparing estimated vs actual values
+
+**Emitting the transaction**
+
+We’ll create a call to our contract using the same values used for the dummy transaction.
+
+```typescript
+const tx = await exampleContract.setExampleVariable(newValueToSetOnExampleContract)
+const txReceipt = await tx.wait(5)
+```
+
+**Calculating the L2 fee**
+
+Using the transaction receipt we can see the amount of gas used by the transaction
+
+```typescript
+const l2Fee = txReceipt.gasUsed * txReceipt.gasPrice
+```
+
+**Getting the amount used to pay for the L1 fee**
+
+To do this, we’ll compare the _balance of the account before_ the transaction execution, the _account balance after_ the execution and then subtract the L2 fee.
+
+```typescript
+const totalFee = signerBalanceBefore - signerBalanceAfter
+const l1Fee = totalFee - l2Fee
+```
+
+**Comparing the values**
+
+Fee markets are constantly moving and unpredictable. Since the values estimated may differ from the actual execution, let’s check how much they differ.
+
+We can run all the code that we previously wrote by typing `yarn gas:estimate` command in our [project](https://github.com/scroll-tech/scroll-guides/tree/main/gas-estimation-demo) that will run the [`gasEstimation.ts`](https://github.com/scroll-tech/scroll-guides/blob/main/gas-estimation-demo/scripts/gasEstimation.ts) script and give us the output below:
+
+```bash
+Estimated L1 fee (wei): 208705598167252
+Estimated L2 fee (wei): 26416000000
+Estimated total fee (wei):  208732014167252
+
+Actual L1 fee (wei): 210830909757550
+Actual L2 fee (wei): 26416000000
+Actual total fee (wei):  210857325757550
+
+(actual fee - estimated fee)
+Difference L1 fee (wei): 2125311590298 (1.0183299389002531%)
+Difference L2 fee (wei): 0 (0%)
+Difference total fee (wei): 2125311590298 (1.0182010645453987%)
+```
+
+We can see above that the estimated values (in wei) differ by around 1%, but keep in mind that during spikes in gas prices, this difference may increase. Be sure to account for this in your front end for users!
+
+<Aside type="tip" title="">
+  For more details about what happens when gas fluctuates on L1 and about the limits set there, check out the [lifecycle
+  of a transaction on the Gas
+  Fees](../developers/transaction-fees-on-scroll-l2/l1-fee.md#what-happens-if-gas-fluctuates-on-l1).
+</Aside>
diff --git a/src/content/docs/es/developers/guides/scroll-messenger-cross-chain-interaction.mdx b/src/content/docs/es/developers/guides/scroll-messenger-cross-chain-interaction.mdx
new file mode 100644
index 000000000..fa0c65f71
--- /dev/null
+++ b/src/content/docs/es/developers/guides/scroll-messenger-cross-chain-interaction.mdx
@@ -0,0 +1,120 @@
+---
+section: developers
+date: Last Modified
+title: "Interacción Cross-chain del Scroll Messenger"
+lang: "es"
+permalink: "developers/guides/scroll-messenger-cross-chain-interaction"
+excerpt: "En este ejemplo, lanzaremos un smart contract de ejemplo en Sepolia o en Scroll Sepolia testnet e interactuaremos con él desde la cadena opuesta."
+whatsnext: { "Bridging de un ERC20 a través de una Gateway Personalizada": "/es/developers/guides/bridge-erc20-through-the-custom-gateway" }
+---
+
+import Aside from "../../../../../components/Aside.astro"
+
+En este ejemplo, lanzaremos un smart contract de ejemplo en Sepolia o Scroll e interactuaremos con él desde la cadena opuesta. Utilizaremos el `ScrollMessenger` que está desplegado tanto en
+Sepolia como en Scroll.
+
+## Despliegue de los contratos
+
+### Smart Contract de Destino
+
+Empecemos por desplegar el smart contract de destino. Usaremos el contrato Greeter para este
+ejemplo, pero puedes usar cualquier otro contrato. Despliégalo en Sepolia o en Scroll. En Scroll, L1
+y L2 usan la misma API, así que depende de ti.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.16;
+
+// Este contrato Greeter interactuará con el ScrollMessenger a través del bridge
+contract Greeter {
+  string public greeting = "Hello World!";
+
+  // Esta función será llamada por executeFunctionCrosschain en el Operador de Smart Contract
+  function setGreeting(string memory greeting_) public {
+    greeting = greeting_;
+  }
+}
+```
+
+Ahora ejecutaremos `setGreeting` de forma cross-chain.
+
+### Operador de Smart Contract
+
+Cambia a la otra cadena y despliega el `GreeterOperator`. De modo que, si desplegaste el contrato `Greeter` en L1, despliega el `GreeterOperator` en L2 o viceversa.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.16;
+
+// La interfaz de Scroll Messenger es la misma tanto en L1 como en L2, permite enviar transacciones entre cadenas
+// Importémoslo directamente de la librería Scroll Contracts
+import "@scroll-tech/contracts@0.1.0/libraries/IScrollMessenger.sol";
+
+// El GreeterOperator es capaz de ejecutar la función Greeter a través del bridge
+contract GreeterOperator {
+  // Esta función ejecutará setGreeting en el contrato Greeter
+  function executeFunctionCrosschain(
+    address scrollMessengerAddress,
+    address targetAddress,
+    uint256 value,
+    string memory greeting,
+    uint32 gasLimit
+  ) public payable {
+    IScrollMessenger scrollMessenger = IScrollMessenger(scrollMessengerAddress);
+    // sendMessage es capaz de ejecutar cualquier función codificando el abi mediante la función encodeWithSignature
+    scrollMessenger.sendMessage{ value: msg.value }(
+      targetAddress,
+      value,
+      abi.encodeWithSignature("setGreeting(string)", greeting),
+      gasLimit,
+      msg.sender
+    );
+  }
+}
+```
+
+## Llamada a una función Cross-Chain
+
+Pasamos el mensaje ejecutando `executeFunctionCrosschain` y pasando los siguientes parámetros:
+
+- `scrollMessengerAddress`: Esto dependerá de dónde hayas desplegado el contrato `GreeterOperator`.
+  - Si lo desplegaste en Sepolia utiliza `0x50c7d3e7f7c656493D1D76aaa1a836CedfCBB16A`. Si lo has desplegado en Scroll utiliza `0xBa50f5340FB9F3Bd074bD638c9BE13eCB36E603d`.
+- `targetAddress`: La dirección del contrato `Greeter` en la cadena opuesta.
+- `value`: En este caso es `0` porque el `setGreeting` no es de tipo `payable`.
+- `greeting`: Es el parámetro que se enviará a través del mensaje. Prueba pasar `"¡Este mensaje fue ejecutado de manera crosschain!"`.
+- `gasLimit`:
+  - Si estás enviando el mensaje de L1 a L2, alrededor de un límite de gas de `5000` debería ser más que suficiente.
+  - Si estás enviando el mensaje de L2 a L1, pasa `0`, ya que la transacción se completará ejecutando una transacción adicional en L1.
+
+### Retransmisión del mensaje al enviar de L2 a L1
+
+Cuando se pasa una transacción de L2 a L1, se debe enviar un "ejecutar transacción de retirada" adicional en L1. Para ello, debe llamar a `relayMessageWithProof` en el contrato L1 Scroll Messenger
+desde un wallet EOA.
+
+Puedes hacerlo directamente en [Etherscan Sepolia](https://sepolia.etherscan.io/address/0x50c7d3e7f7c656493d1d76aaa1a836cedfcbb16a#writeProxyContract#F3).
+Para ello, necesitarás pasar una prueba de inclusión Merkle Tree para la transacción eviada a través del bridge al igual que otros parámetros que puedes obtener consultando la API del Scroll Bridge.
+
+{/* TODO: finish looking into API issues */}
+
+Estamos ultimando los detalles de la API, pero por ahora, pero puedes obtener estos datos consultándolos en el siguiente endpoint:
+
+```bash
+curl "https://sepolia-api-bridge.scroll.io/api/claimable?page_size=10&page=1&address=GREETER_OPERATOR_ADDRESS_ON_L2"
+```
+
+Sustituya `GREETER_OPERATOR_ADDRESS_ON_L2` por la dirección de su contrato GreeterOperator tal y como se lanzó en L2. Puedes leer más información sobre Ejecutar transacciones de retirada de fondos
+en el artículo [el Scroll Messenger](/es/developers/l1-and-l2-bridging/the-scroll-messenger).
+
+<Aside type="danger" title="API Experimental">
+  Esta API se ha creado para nuestra IU del Bridge. Aún no está finalizada y puede cambiar en el futuro. Actualizaremos esta guía
+  cuando la API esté finalizada.
+</Aside>
+
+<Aside type="caution" title="Cualquiera puede ejecutar su mensaje L2 → L1">
+  Puedes ejecutar `relayMessageWithProof` directamente y sin necesidad de permisos adicionales, por lo que cualquiera puede llamarlo en tu nombre en caso que alguien esté dispuesto a pagar el gas de L1. Esta característica permite una infraestructura de soporte adicional, incluidas herramientas para automatizar este proceso para
+  aplicaciones y usuarios.
+</Aside>
+
+Tras ejecutar y confirmar la transacción tanto en L1 como en L2, el nuevo estado de `greeting` en el contrato `Greeter` debería ser `"¡Este mensaje fue ejecutado de manera crosschain!"`. Enviar un mensaje de una cadena a la otra debería llevar unos 20 minutos después de que se confirmen las transacciones en la cadena de origen.
+
+Felicitaciones, ¡ya has ejecutado una transacción de una cadena a la otra utilizando nuestro bridge nativo!
diff --git a/src/content/docs/es/developers/index.mdx b/src/content/docs/es/developers/index.mdx
new file mode 100644
index 000000000..266f16cf7
--- /dev/null
+++ b/src/content/docs/es/developers/index.mdx
@@ -0,0 +1,94 @@
+---
+section: developers
+date: Last Modified
+title: "Construyendo en Scroll"
+lang: "es"
+permalink: "developers/"
+excerpt: "Construir en Scroll se siente igual que en Ethereum, y puedes llevar contigo tus herramientas y contratos favoritos."
+whatsnext: { "Inicio rápido para desarrolladores": "/es/developers/developer-quickstart" }
+---
+
+import Aside from "../../../../components/Aside.astro"
+import ToggleElement from "../../../../components/ToggleElement.astro"
+
+**¡Bienvenido a la documentación para desarrolladores de Scroll!**
+
+Scroll es su propia red de capa 2 construida sobre Ethereum (más concretamente, un "zero-knowledge rollup").
+
+Si tienes experiencia en el desarrollo en Ethereum, su código, dependencias y herramientas funcionarán con Scroll desde el primer momento. 
+
+Esto es posible porque nuestra red es compatible con el bytecode de la EVM y está diseñada para que se sienta igual que desarrollar en Ethereum.
+
+<Aside type="tip" title="¿Eres nuevo con los zero knowledge rollups?">
+Scroll obtiene su seguridad y velocidad ejecutando transacciones fuera de la cadena, y produciendo también una prueba criptográfica que demuestra que las transacciones 
+se ejecutaron correctamente. Esta prueba criptográfica se verifica en un smart contract en la Capa 1, asegurando que todo el código ejecutado en la Capa 2 de Scroll se 
+comporta como si fuera ejecutado en la Capa 1 de Ethereum.
+
+[Aprende más sobre la arquitectura de Scroll→](/es/technology)
+
+</Aside>
+
+## Primeros Pasos
+
+**¿Desea desarrollar en Scroll Sepolia Testnet?**
+
+- Para lo esencial: Consulta el [Inicio rápido para desarrolladores](/es/developers/developer-quickstart)
+- Para un tutorial sobre el despliegue de tu primer smart contract en Scroll, lee nuestro 
+[tutorial de despliegue de contratos](/es/developers/guides/contract-deployment-tutorial)
+- También tenemos varias [direcciones de contratos desplegados](/es/developers/scroll-contracts) para poder utilizar.
+
+## ¿Por qué Construir en Scroll?
+
+<ToggleElement anchor="throughput">
+  <div slot="title">Rendimiento - Scroll crea más espacio de bloques seguros para Ethereum.</div>
+  <p>
+    Los Rollups ZK permiten una mayor actividad en la red, minimizando la congestión. Al heredar la seguridad de Ethereum,
+    que verifica el comportamiento de la red utilizando zero-knowledge proofs, Scroll puede procesar más transacciones sin comprometer la descentralización.
+  </p>
+</ToggleElement>
+
+<ToggleElement anchor="cost">
+  <div slot="title">Costo - Scroll ahorra gastos de gas a los usuarios.</div>
+  <p>
+    En Ethereum, la competencia por el espacio de bloque se traduce en mayores costos por transacción, ya que cada
+    transacción hace una oferta para ser incluida en el siguiente bloque. Scroll aprovecha los recientes avances en
+    zero-knowledge proofs y aceleración de hardware para aumentar enormemente la seguridad del espacio de bloque y minimizar
+    los costos de transacción para los usuarios. 
+  </p>
+</ToggleElement>
+<ToggleElement anchor="speed">
+  <div slot="title">Velocidad - Scroll proporciona información a los usuarios con mayor rapidez.</div>
+  <p>
+    Tras el merge, los bloques de Ethereum se confirman de forma fiable cada 12 segundos. Los bloques de Scroll se mintean cada 3 segundos, y
+    en favor de las operaciones de menor riesgo, se puede suponer que las transacciones son definitivas una vez incluidas en un bloque. 
+    Esto abre nuevas posibilidades para la interacción en la cadena en aplicaciones sociales y de juegos.
+  </p>
+</ToggleElement>
+<ToggleElement anchor="alignment">
+  <div slot="title">Alineamiento - Scroll se basa en la visión de Ethereum.</div>
+  <p>
+    Scroll se basa en la visión de Ethereum. Nuestra filosofía es construir Ethereum, no fragmentarlo. La descentralización,
+    el ideal permissionless, la resistencia a la censura, y la autonomía de la comunidad son el núcleo de lo que hacemos y 
+    del roadmap que estamos construyendo. Creemos en el software de código abierto y colaboramos estrechamente con el 
+    equipo Privacy and Scaling Explorations de la Fundación Ethereum para apoyar su trabajo en un zkEVM que algún día podría ser el corazón de Ethereum.
+  </p>
+  <p>
+    También trabajamos con DAOs de gobernanza y otros protocolos de código abierto para asegurarnos de que, a medida que se despliegan las aplicaciones,
+    trabajamos para aumentar su impacto, ya sea en bienes públicos, infraestructura básica o la próxima generación de casos de uso de zero-knowledge.
+  </p>
+</ToggleElement>
+<ToggleElement anchor="community">
+  <div slot="title">Comunidad - Scroll reúne a usuarios y builders.</div>
+  <p>
+    Estamos conscientes de los retos de construir de manera abierta y conseguir la participación de los usuarios antes del lanzamiento de la mainnet. 
+    Scroll cuenta con una comunidad de Discord de más de 100.000 usuarios deseosos de probar aplicaciones en nuestra testnet.
+    Estamos contentos de conectar a creadores con usuarios que puedan aportar feedback del mundo real.
+  </p>
+</ToggleElement>
+
+## Gracias por construir con nosotros
+
+Estamos trabajando para traer más integraciones e infraestructura de apoyo a la red, y estamos trabajando con entusiasmo hacia el lanzamiento de nuestra Mainnet.
+
+Únete a nuestra creciente comunidad de desarrolladores. Puedes encontrarnos en [Discord](https://discord.gg/scroll), 
+unirte a nuestro [foro de debate](https://community.scroll.io/) o seguir nuestro progreso en [Twitter](https://twitter.com/Scroll_ZKP).
diff --git a/src/content/docs/es/developers/l1-and-l2-bridging.mdx b/src/content/docs/es/developers/l1-and-l2-bridging.mdx
new file mode 100644
index 000000000..2b3c4b72d
--- /dev/null
+++ b/src/content/docs/es/developers/l1-and-l2-bridging.mdx
@@ -0,0 +1,35 @@
+---
+section: developers
+date: Last Modified
+title: "L1 y L2 Bridging"
+lang: "es"
+permalink: "developers/l1-and-l2-bridging"
+whatsnext: { "ETH y ERC20 Token Bridge": "/es/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge" }
+excerpt: "Visión general de la arquitectura de puentes de Scroll"
+---
+
+import ClickToZoom from "../../../../components/ClickToZoom.astro"
+import L1GatewayWHITE from "../../../../assets/images/developers/L1GatewayWHITE.png"
+import withdrawWHITE from "../../../../assets/images/developers/withdrawWHITE.png"
+
+El bridge de Scroll permite la transferencia de ETH, tokens ERC20, NFTs y mensajes arbitrarios entre L1 y L2. Sirve como un mecanismo seguro para mover diversos activos entre L1 y L2.
+
+Para facilitar la transferencia de ETH y tokens ERC20, el bridge de Scroll utiliza el Gateway Router. Este contrato garantiza el paso fluido de estos activos entre L1 y L2, permitiendo a los usuarios transferir sus tokens nativos de Ethereum sin problemas.
+
+La Gateways de ERC721 y de ERC1155 permiten la transferencia de tokens no fungibles entre las dos redes, permitiendo a los usuarios mover sus NFTs entre L1 y L2.
+
+Además de las transferencias de tokens, el contrato Scroll Messenger permite la interacción de contratos cross-chain. Esto significa que los contratos de una red pueden interactuar con los contratos de la otra red a través del contrato Scroll Messenger. Esta funcionalidad amplía las posibilidades para las aplicaciones descentralizadas y los smart contracts al permitirles operar sin problemas en ambas redes.
+
+## Arquitectura de la Gateway L1
+
+<ClickToZoom src={L1GatewayWHITE} />
+
+Hay muchos puntos de entrada de los usuarios al bridge de Scroll. El que decidas usar dependerá de lo que quieras hacer y cómo quieras hacerlo. Si quieres enviar ETH o tokens ERC20, deberías usar el `GatewayRouter` . Si quieres enviar NFTs, deberías usar el `L1ERC721Gateway` o el `L1ERC1155Gateway`. Si deseas enviar datos arbitrarios, utiliza el `L1ScrollMessenger`. Todas las transferencias del Gateway utilizan el Scroll Messenger para enviar activos a de una cadena a la otra, cuyo trabajo consiste en anexar las transacciones a la cola de mensajes para su inclusión en L2.
+
+## Arquitectura de la Gateway L2
+
+<ClickToZoom src={withdrawWHITE} />
+
+En cuanto a los posibles puntos de entrada accesibles sin necesidad de permisos, la Arquitectura de la Gateway en L2 es muy similar a la de L1. La diferencia es que cuando se envía un mensaje desde L2, si se llama a la función `appendMessage`, el mensaje se almacenará en un merkle tree binario que únicamente permite añadir datos (también conocido como withdraw tree) en la `L2MessageQueue`. Cuando se envía un nuevo mensaje a la `L2MessageQueue`, el relayer lo detecta y lo almacena en la base de datos. Cuando el bloque finaliza, generará una prueba de el nuevo merkle path y la pasará al nodo L1geth para que la ejecute en el `L1ScrollMessenger` . Todas las raíces de retirada finalizadas se almacenarán en el contrato de rollup para que podamos verificar la prueba con ellas. En las próximas versiones de Scroll, el Relayer no será necesario, ya que todos los usuarios podrán finalizar la transacción en L1.
+
+En las próximas secciones, exploraremos los aspectos técnicos del puente, incluida la API de smart contract necesaria para utilizar sus capacidades. En la sección Guías para desarrolladores se ofrecen guías detalladas con ejemplos de código para ayudar a desarrolladores y usuarios a comprender e implementar estas funcionalidades.
diff --git a/src/content/docs/es/developers/l1-and-l2-bridging/enforced-transactions.mdx b/src/content/docs/es/developers/l1-and-l2-bridging/enforced-transactions.mdx
new file mode 100644
index 000000000..21e2bc15e
--- /dev/null
+++ b/src/content/docs/es/developers/l1-and-l2-bridging/enforced-transactions.mdx
@@ -0,0 +1,57 @@
+---
+section: developers
+date: Last Modified
+title: "Enforced transactions"
+lang: "en"
+permalink: "developers/l1-and-l2-bridging/enforced-transactions"
+excerpt: "The Enforced Transaction contract enables sending transactions between L1 and L2 the sendTransaction function."
+---
+
+import Aside from "../../../../../components/Aside.astro"
+
+The Enforced Transaction contract enables sending transactions between L1 and L2 the **`sendTransaction`** function. This contract shares similarities with the Scroll Messenger contract as it allows sending arbitrary data from one layer to the other. However, it distinguishes itself by enabling the relaying of signed transactions and the ability to set the sender (CALLER or msg.sender) on the receiving transaction on Scroll.
+
+## Enforced Transactions API
+
+Please visit the [npm library](https://www.npmjs.com/package/@scroll-tech/contracts?activeTab=code) for the complete Scroll contract API documentation.
+
+### sendTransaction
+
+```solidity
+function sendTransaction(address _target, uint256 _value, uint256 _gasLimit, bytes calldata _data) public payable;
+```
+
+Add an enforced transaction to L2 from an EOA account sender.
+
+| Parameter  | Description                                                |
+| ---------- | ---------------------------------------------------------- |
+| \_target   | The address of target contract to call in L2.              |
+| \_value    | The value passed.                                          |
+| \_gasLimit | The maximum gas should be used for this transaction in L2. |
+| \_data     | The calldata passed to target contract.                    |
+
+### sendTransaction
+
+```solidity
+function sendTransaction(
+  address _sender,
+  address _target,
+  uint256 _value,
+  uint256 _gasLimit,
+  bytes calldata _data,
+  bytes memory _signature,
+  address _refundAddress
+) public payable;
+```
+
+Add an enforced transaction to L2 by relaying a signature from the sender.
+
+| Parameter       | Description                                                     |
+| --------------- | --------------------------------------------------------------- |
+| \_sender        | The address of sender who will initiate this transaction in L2. |
+| \_target        | The address of target contract to call in L2.                   |
+| \_value         | The value passed                                                |
+| \_gasLimit      | The maximum gas should be used for this transaction in L2.      |
+| \_data          | The calldata passed to target contract.                         |
+| \_signature     | The signature for the transaction.                              |
+| \_refundAddress | The address to refund exceeded fee.                             |
diff --git a/src/content/docs/es/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx b/src/content/docs/es/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx
new file mode 100644
index 000000000..b217c16c9
--- /dev/null
+++ b/src/content/docs/es/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx
@@ -0,0 +1,161 @@
+---
+section: developers
+date: Last Modified
+title: "ERC1155 Token Bridge"
+lang: "es"
+permalink: "developers/l1-and-l2-bridging/erc1155-token-bridge"
+whatsnext: { "El Scroll Messenger": "/es/developers/l1-and-l2-bridging/the-scroll-messenger" }
+excerpt: "El bridging de tokens ERC1155 de L1 a L2 se realiza a través del L1ERC1155Gateway."
+---
+
+import Aside from "../../../../../components/Aside.astro"
+
+## Depósito de tokens ERC1155 de L1
+
+El bridging de tokens ERC1155 de L1 a L2 se realiza a través de la `L1ERC1155Gateway`. Al igual que en el bridging de ERC721, no se utiliza un router, sino la función `depositERC1155` directamente en la Gateway.
+
+<Aside type="tip" title="">
+  **`depositERC1155`** es una función de tipo `payable`, y la cantidad de ETH enviada a esta función se utilizará para pagar las comisiones
+  en L2. Si la cantidad no es suficiente, la transacción no será enviada. Todo el exceso de ETH será enviado de vuelta al remitente.
+  Un importe de `0.00001 ETH` debería ser más que suficiente para procesar un depósito de tokens.
+</Aside>
+
+### Creación de un token ScrollERC1155 en L2
+
+De forma similar al bridging de ERC721, para realizar el bridging de tokens ERC1155 es necesario lanzar un contrato compatible con el estándar `IScrollERC1155` y asignarlo a una `L1ERC1155Gateway` y una `L2ERC1155Gateway` en L1 y L2 respectivamente. Este contrato tiene que conceder permiso a la Gateway en L2 para emitir cuando un token es depositado y quemar cuando el token es retirado.
+
+La siguiente interfaz es el `IScrollERC1155` necesario para desplegar tokens ERC1155 compatibles con el `L2ERC1155Gateway` en L2.
+
+```solidity
+interface IScrollERC1155 {
+  /// @notice Return the address of Gateway the token belongs to.
+  function gateway() external view returns (address);
+
+  /// @notice Return the address of counterpart token.
+  function counterpart() external view returns (address);
+
+  /// @notice Mint some token to recipient's account.
+  /// @dev Gateway Utilities, only gateway contract can call
+  /// @param _to The address of recipient.
+  /// @param _tokenId The token id to mint.
+  /// @param _amount The amount of token to mint.
+  /// @param _data The data passed to recipient
+  function mint(address _to, uint256 _tokenId, uint256 _amount, bytes memory _data) external;
+
+  /// @notice Burn some token from account.
+  /// @dev Gateway Utilities, only gateway contract can call
+  /// @param _from The address of account to burn token.
+  /// @param _tokenId The token id to burn.
+  /// @param _amount The amount of token to burn.
+  function burn(address _from, uint256 _tokenId, uint256 _amount) external;
+
+  /// @notice Batch mint some token to recipient's account.
+  /// @dev Gateway Utilities, only gateway contract can call
+  /// @param _to The address of recipient.
+  /// @param _tokenIds The token id to mint.
+  /// @param _amounts The list of corresponding amount of token to mint.
+  /// @param _data The data passed to recipient
+  function batchMint(
+    address _to,
+    uint256[] calldata _tokenIds,
+    uint256[] calldata _amounts,
+    bytes calldata _data
+  ) external;
+
+  /// @notice Batch burn some token from account.
+  /// @dev Gateway Utilities, only gateway contract can call
+  /// @param _from The address of account to burn token.
+  /// @param _tokenIds The list of token ids to burn.
+  /// @param _amounts The list of corresponding amount of token to burn.
+  function batchBurn(address _from, uint256[] calldata _tokenIds, uint256[] calldata _amounts) external;
+}
+```
+
+### Añadiendo un token ERC1155 al Scroll Bridge
+
+Todos los activos pueden ser transferidos de forma segura y sin intermediarios a través de contratos Gateway desplegados por cualquier desarrollador. Sin embargo, Scroll también gestiona un contrato Gateway ERC1155 en el que todos los NFTs creados por la comunidad son bienvenidos. Formar parte de la Gateway gestionada por Scroll significa que no necesitarás desplegar los contratos Gateway, y tu token aparecerá en el frontend de Scroll. Para formar parte de la Gateway de Scroll, debes ponerte en contacto con el equipo de Scroll para añadir el token a los contratos de la Gateway en L1 y L2. Para ello, sigue las instrucciones del repositorio [token lists](https://github.com/scroll-tech/token-list) para añadir tu token al frontend oficial de Scroll.
+
+## Retiro de tokens ERC1155 de L2
+
+El contrato `L2ERC1155Gateway` se utiliza para enviar tokens de L2 a L1. Antes de realizar el bridging, el contrato `L2ERC1155Gateway` tiene que ser aprobado por el contrato de tokens. Una vez hecho esto, se puede llamar a `withdrawERC1155` para realizar el bridging de activos.
+
+<Aside type="tip" title="">
+  **`withdrawERC1155`** es una función de tipo `payable`, y la cantidad de ETH enviada a esta función se utilizará para pagar las comisiones de L1. Si la cantidad no es suficiente, la transacción no será enviada. Todo el exceso de ETH será devuelto al remitente. Las tasas
+  dependen de la actividad de L1 pero `0.005 ETH` debería ser suficiente para procesar una retirada de tokens.
+</Aside>
+
+<Aside type="caution" title="">
+  **Asegúrate de que la transacción no se revertirá en L1** mientras envías desde L2. No hay forma de recuperar los tokens enviados por el bridge si
+  tu transacción revierte en L1. Todos los activos se queman en L2 cuando se envía la transacción, y es imposible recuperarlos
+  de nuevo.
+</Aside>
+
+## API de L1ERC1155Gateway
+
+Visita la [librería de npm](https://www.npmjs.com/package/@scroll-tech/contracts?activeTab=code) para consultar la documentación completa de la API de los contratos de Scroll.
+
+### depositERC1155
+
+```solidity
+function depositERC1155(
+  address _token,
+  address _to,
+  uint256 _tokenId,
+  uint256 _amount,
+  uint256 _gasLimit
+) external payable;
+```
+
+Deposita tokens ERC1155 desde L1 en la cuenta de un destinatario en L2.
+
+| Parámetro | Descripción                                       |
+| --------- | ------------------------------------------------- |
+| token     | Dirección del contrato de tokens ERC1155 en L1.      |
+| to        | Dirección de la cuenta del destinatario en L2.         |
+| tokenId   | Id del NFT a depositar.                            |
+| amount    | Cantidad de tokens a depositar.                  |
+| gasLimit  | Límite de gas necesario para completar el depósito en L2. |
+
+### updateTokenMapping
+
+```solidity
+function updateTokenMapping(address _l1Token, address _l2Token) external;
+```
+
+Actualiza el mapping que conecta un contrato de tokens ERC1155 de L1 a L2.
+
+| Parámetro | Descripción                                       |
+| --------- | ------------------------------------------------- |
+| \_l1Token | Dirección del token ERC1155 en L1.           |
+| \_l2Token | Dirección del token ERC1155 correspondiente en L2. |
+
+## API de L2ERC1155Gateway
+
+### withdrawERC1155
+
+```solidity
+function withdrawERC1155(address token, address to, uint256 tokenId, uint256 amount, uint256 gasLimit) external payable;
+```
+
+Envía tokens ERC1155 desde L2 a la cuenta de un destinatario en L1.
+
+| Parámetro | Descripción                                                              |
+| --------- | ------------------------------------------------------------------------ |
+| token     | Dirección del contrato de tokens ERC1155 en L2.                             |
+| to        | Dirección de la cuenta del destinatario en L1.                                |
+| tokenId   | Id del NFT a retirar.                                                  |
+| amount    | Cantidad de tokens a retirar.                                        |
+| gasLimit  | No se utiliza, pero se incluye por posibles consideraciones de compatibilidad futura. |
+
+### updateTokenMapping
+
+```solidity
+function updateTokenMapping(address _l1Token, address _l2Token) external;
+```
+
+Actualiza el mapping que conecta un contrato de tokens ERC1155 de L2 a L1.
+
+| Parámetro | Descripción                                       |
+| --------- | ------------------------------------------------- |
+| \_l1Token | Dirección del token ERC1155 en L1.            |
+| \_l2Token | Dirección del token ERC1155 correspondiente en L2. |
diff --git a/src/content/docs/es/developers/l1-and-l2-bridging/erc721-nft-bridge.mdx b/src/content/docs/es/developers/l1-and-l2-bridging/erc721-nft-bridge.mdx
new file mode 100644
index 000000000..2a3ed76c5
--- /dev/null
+++ b/src/content/docs/es/developers/l1-and-l2-bridging/erc721-nft-bridge.mdx
@@ -0,0 +1,131 @@
+---
+section: developers
+date: Last Modified
+title: "ERC721 NFT Bridge"
+lang: "es"
+permalink: "developers/l1-and-l2-bridging/erc721-nft-bridge"
+excerpt: "El bridging de NFTs de L1 a L2 se realiza a través del contrato L1ERC721Gateway en lugar de utilizar un router."
+whatsnext: { "ERC1155 Token Bridge": "/es/developers/l1-and-l2-bridging/erc1155-token-bridge" }
+---
+
+import Aside from "../../../../../components/Aside.astro"
+
+## Depósito de tokens ERC721 de L1
+
+El bridging de NFTs de L1 a L2 se realiza a través del contrato `L1ERC721Gateway` en lugar de utilizar un router. De forma similar al bridging de tokens ERC20, utilizamos la función `depositERC721` para enviar tokens a L2, y posteriormente podemos recuperarlos de vuelta a L1 utilizando `withdrawERC721` en el contrato `L2ERC721Gateway` desplegado en L2.
+
+Los contratos NFT tanto en L1 como en L2 deben lanzarse y conectarse a través de las Gateways para permitir el bridging. Esto significa que las transacciones de depósito y retirada se revertirán si falta un contrato en L1 o L2 o si no se asigna a través de la función `updateTokenMapping`.
+
+<Aside type="tip" title="">
+  **`depositERC721`** es una función de tipo `payable`. La cantidad de ETH enviada a esta función se utilizará para pagar las comisiones de la L2. Si
+  la cantidad no es suficiente, la transacción no será enviada. Todo el exceso de ETH será devuelto al remitente. `0.00001
+  ETH` debería ser más que suficiente para procesar un depósito de tokens.
+</Aside>
+
+### Creación de un token ScrollERC721 en L2
+
+Para depositar un token ERC721 en L2, debe lanzarse un contrato de token compatible con el estándar `IScrollERC721` y asignarse a una `L1ERC721Gateway` y una `L2ERC721Gateway` en L1 y L2, respectivamente. Este contrato tiene que conceder permiso a la Gateway en L2 para emitir cuando un token es depositado y quemar cuando el token es retirado.
+
+La siguiente interfaz es la `IScrollERC721` que es necesaria para desplegar tokens ERC721 compatibles con el `L2ERC721Gateway` en L2.
+
+```solidity
+interface IScrollERC721 {
+  /// @notice Return the address of Gateway the token belongs to.
+  function gateway() external view returns (address);
+
+  /// @notice Return the address of counterpart token.
+  function counterpart() external view returns (address);
+
+  /// @notice Mint some token to recipient's account.
+  /// @dev Gateway Utilities, only gateway contract can call
+  /// @param _to The address of recipient.
+  /// @param _tokenId The token id to mint.
+  function mint(address _to, uint256 _tokenId) external;
+
+  /// @notice Burn some token from account.
+  /// @dev Gateway Utilities, only gateway contract can call
+  /// @param _tokenId The token id to burn.
+  function burn(uint256 _tokenId) external;
+}
+```
+
+### Añadiendo NFTs ERC721 al Scroll Bridge
+
+Todos los activos pueden ser transferidos de forma segura y sin permisos a través de contratos Gateway desplegados por cualquier desarrollador. Sin embargo, Scroll también gestiona un contrato Gateway ERC721 en donde todos los NFTs creados por la comunidad son bienvenidos. Formar parte del Gateway gestionado por Scroll significa que no necesitarás desplegar los contratos Gateway, y tu token aparecerá en el frontend de Scroll. Para formar parte de la Gateway gestionada por Scroll, debe ponerse en contacto con el equipo de Scroll para añadir el NFT en los contratos Gateway L1 y L2. Para ello, sigue las instrucciones del repositorio [token lists](https://github.com/scroll-tech/token-list) para añadir un nuevo token al frontend oficial de Scroll.
+
+## Retiro de tokens ERC721 de Scroll
+
+El contrato `L2ERC721Gateway` se utiliza para enviar tokens de L2 a L1. Antes de realizar el bridging, el contrato `L2ERC721Gateway` tiene que ser aprobado por el contrato del NFT. Una vez hecho esto, se puede llamar a `withdrawERC721` para realizar el bridging de activos.
+
+<Aside type="tip" title="">
+  **`withdrawERC721`** es una función de tipo `payable`, y la cantidad de ETH enviada a esta función se utilizará para pagar las tasas de L1. Si la cantidad no es suficiente, la transacción no será enviada. Todo el exceso de ETH será devuelto al remitente. Las tasas
+  dependen de la actividad de L1 pero `0.005 ETH` debería ser suficiente para procesar una retirada de tokens.
+</Aside>
+
+<Aside type="caution" title="">
+  **Asegúrate de que la transacción no se revertirá en L1** mientras envías desde L2. No hay forma de recuperar el NFT puenteado si
+  tu transacción revierte en L1. Todos los activos se queman en L2 cuando se envía la transacción, y es imposible recuperarlos
+  de nuevo.
+</Aside>
+
+## API de L1ERC721Gateway 
+
+Visita [librería de npm](https://www.npmjs.com/package/@scroll-tech/contracts?activeTab=code) para consultar la documentación completa de la API de los contratos de Scroll.
+
+### depositERC721
+
+```solidity
+function depositERC721(address _token, address _to, uint256 _tokenId, uint256 _gasLimit) external payable;
+```
+
+Depósito de un NFT ERC721 desde L1 a la cuenta de un destinatario en L2.
+
+| Parámetro | Descripción                                       |
+| --------- | ------------------------------------------------- |
+| token     | Dirección del contrato ERC721 NFT en L1.         |
+| to        | Dirección de la cuenta del destinatario en L2.         |
+| tokenId   | Id del NFT a depositar.                            |
+| gasLimit  | Límite de gas necesario para completar el depósito en L2. |
+
+### updateTokenMapping
+
+```solidity
+function updateTokenMapping(address _l1Token, address _l2Token) external;
+```
+
+Actualización del mapping que conecta un contrato NFT de L1 a L2.
+
+| Parámetro | Descripción                                      |
+| --------- | ------------------------------------------------ |
+| \_l1Token | Dirección del token ERC721 en L1.               |
+| \_l2Token | Dirección del token ERC721 correspondiente en L2. |
+
+## API de L2ERC721Gateway 
+
+### withdrawERC721
+
+```solidity
+function depositERC721(address _token, address _to, uint256 _tokenId, uint256 _gasLimit) external payable;
+```
+
+Envío de un ERC721 NFT desde L2 a la cuenta de un destinatario en L1.
+
+| Parámetro | Descripción                                                              |
+| --------- | ------------------------------------------------------------------------ |
+| token     | Dirección del contrato de tokens ERC721 NFT en L2.                          |
+| to        | Dirección de la cuenta del destinatario en L1.                                |
+| tokenId   | Id del NFT a depositar.                                                   |
+| gasLimit  | No se utiliza, pero se incluye por posibles consideraciones de compatibilidad futura. |
+
+### updateTokenMapping
+
+```solidity
+function updateTokenMapping(address _l1Token, address _l2Token) external;
+```
+
+Actualización del mapping que conecta un contrato NFT de L2 a L1.
+
+| Parámetro | Descripción                                      |
+| --------- | ------------------------------------------------ |
+| \_l2Token | Dirección del token ERC721 en L2.               |
+| \_l1Token | Dirección del token ERC721 correspondiente en L1. |
diff --git a/src/content/docs/es/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx b/src/content/docs/es/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx
new file mode 100644
index 000000000..2e7e0b40b
--- /dev/null
+++ b/src/content/docs/es/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx
@@ -0,0 +1,206 @@
+---
+section: developers
+date: Last Modified
+title: "ETH y ERC20 Token Bridge"
+lang: "es"
+permalink: "developers/l1-and-l2-bridging/eth-and-erc20-token-bridge"
+whatsnext: { "ERC721 NFT Bridge": "/es/developers/l1-and-l2-bridging/erc721-nft-bridge" }
+excerpt: "El Gateway Router permite puentear tokens ETH y ERC20 de L1 a L2 utilizando las funciones depositETH y depositERC20 respectivamente."
+---
+
+import Aside from "../../../../../components/Aside.astro"
+
+## Depositar ETH y tokens ERC20 de L1
+
+El Gateway Router permite hacer bridging de ETH y tokens ERC20 desde L1 a L2 utilizando las funciones `depositETH` y `depositERC20`. Permite a cualquier usuario realizar envíos sin restricciones de acceso mediante un contrato desplegado en L1. Ten en cuenta que los tokens ERC20 tendrán una dirección diferente en L2, así que puedes utilizar la función `getL2ERC20Address` para consultar la nueva dirección.
+
+<Aside type="tip" title="">
+  **`depositETH`** y **`depositERC20`** son funciones de tipo `payable`, la cantidad de ETH enviada a estas funciones se utilizará
+para pagar la comisión en L2. Si la cantidad no es suficiente, la transacción no será enviada. Todo el exceso de ETH se devolverá al
+  al remitente. Una cantidad de `0,00001` ETH debería ser más que suficiente para procesar un depósito de tokens.
+</Aside>
+
+Al enviar tokens ERC20, no tienes que preocuparte de seleccionar la Gateway correcta. Esto se debe a que el `L1GatewayRouter` elegirá el punto de entrada subyacente correcto para enviar el mensaje:
+
+- **`L1StandardERC20Gateway`:** Esta Gateway permite cualquier depósito de tokens ERC20 y será seleccionada por defecto por la `L1GatewayRouter` para un token ERC20 que no necesite lógica personalizada en L2. En el primer bridging de tokens, se creará un nuevo token en L2 que implemente el ScrollStandardERC20. Para hacer bridging de un token, llama a la función `depositERC20` en el `L1GatewayRouter`.
+- **`L1CustomERC20Gateway`:** Esta Gateway será seleccionada por el `L1GatewayRouter` para tokens con lógica personalizada. Para que un pair de token L1/L2 funcione en el bridge de ERC20 personalizado de Scroll, el contrato de token en L2 tiene que implementar `IScrollStandardERC20`. Además, el token debe conceder la capacidad `mint` y `burn` a la `L2CustomERC20Gateway`.
+
+  Visita la guía [Bridge ERC20 a través de una Gateway Personalizada](/developers/developer-guides/bridge-erc20-through-the-custom-gateway) para ver un ejemplo paso a paso de cómo hacer bridging de un token personalizado.
+
+Todos los contratos Gateway formarán el mensaje y lo enviarán al `L1ScrollMessenger` que puede enviar mensajes arbitrarios a L2. El `L1ScrollMessenger` pasa el mensaje a la `L1MessageQueue`. Cualquier usuario puede enviar mensajes directamente al Messenger para ejecutar datos arbitrarios en L2. Esto significa que pueden ejecutar cualquier función en L2 desde una transacción realizada en L1 a través del bridge. Aunque una aplicación podría pasar directamente mensajes a los contratos de tokens existentes, el Gateway abstrae los detalles y simplifica las transferencias y llamadas.
+
+<Aside type="tip" title="">
+  Los usuarios también pueden omitir el `L1ScrollMessenger` y enviar mensajes directamente a la `L1MessageQueue`. Si se envía un mensaje
+  a través de `L1MessageQueue`, el remitente de la transacción será la dirección del usuario que envía la transacción, no la
+  dirección del `L1ScrollMessenger`. Más información sobre el envío de mensajes arbitrarios en [ El Scroll
+  Messenger](/es/developers/l1-and-l2-bridging/the-scroll-messenger).
+</Aside>
+
+Cuando se crea un nuevo bloque en L1, el Watcher detectará el mensaje en la `L1MessageQueue` y lo pasará al servicio Relayer, que enviará la transacción a L2 a través del nodo l2geth. Finalmente, el nodo l2geth pasará la transacción al contrato `L2ScrollMessagner` para su ejecución en L2.
+
+## Retiro de ETH y ERC20 tokens desde L2
+
+La Gateway L2 es muy similar a la Gateway L1. Podemos retirar tokens ETH y ERC20 de vuelta a L1 utilizando las funciones `withdrawETH` y `withdrawERC20`. La dirección del contrato se despliega en L2. Usamos la función `getL1ERC20Address` para conseguir la dirección del token en L1.
+
+<Aside type="tip" title="">
+  **`withdrawETH`** y **`withdrawERC20`** son funciones de tipo `payable`, y la cantidad de ETH enviada a estas funciones será
+utilizada para pagar las comisiones en L1. Si la cantidad no es suficiente, la transacción no será enviada. Todo el exceso de ETH será enviado
+  al remitente. Las tasas dependerán de la actividad de L1, pero `0,005 ETH` debería ser suficiente para procesar una retirada de tokens.
+</Aside>
+
+<Aside type="caution" title="">
+  **Asegúrate de que las transacciones no se revertirán en L1** mientras envías desde L2. No hay forma de recuperar ETH,
+  tokens, o NFTs si tu transacción revierte en L1. Todos los activos se queman en Scroll cuando se envía la transacción, y
+  es imposible volver recuperarlos.
+</Aside>
+
+## Creación de un token ERC20 con lógica personalizada en L2
+
+Si un token necesita una lógica personalizada en L2, deberá de hacer bridging a través de `L1CustomERC20Gateway` y `L2CustomERC20Gateway` respectivamente. El token personalizado en L2 deberá dar permiso a la Gateway para emitir nuevos tokens cuando se produzca un depósito y para quemarlos cuando se retiren.
+
+La siguiente interfaz es el `IScrollStandardERC20` necesario para desplegar tokens compatibles con el `L2CustomERC20Gateway` en L2.
+
+```solidity
+interface IScrollStandardERC20 {
+  /// @notice Return the address of Gateway the token belongs to.
+  function gateway() external view returns (address);
+
+  /// @notice Return the address of counterpart token.
+  function counterpart() external view returns (address);
+
+  /// @dev ERC677 Standard, see https://github.com/ethereum/EIPs/issues/677
+  /// Defi can use this method to transfer L1/L2 token to L2/L1,
+  /// and deposit to L2/L1 contract in one transaction
+  function transferAndCall(address receiver, uint256 amount, bytes calldata data) external returns (bool success);
+
+  /// @notice Mint some token to recipient's account.
+  /// @dev Gateway Utilities, only gateway contract can call
+  /// @param _to The address of recipient.
+  /// @param _amount The amount of token to mint.
+  function mint(address _to, uint256 _amount) external;
+
+  /// @notice Mint some token from account.
+  /// @dev Gateway Utilities, only gateway contract can call
+  /// @param _from The address of account to burn token.
+  /// @param _amount The amount of token to mint.
+  function burn(address _from, uint256 _amount) external;
+}
+```
+
+### Añadir un token L2 ERC20 personalizado al Scroll Bridge
+
+Los tokens pueden hacer bridging de forma segura y sin intermediarios a través de contratos Gateway desplegados por cualquier desarrollador. Sin embargo, Scroll también gestiona un Router ERC20 y un Gateway donde todos los tokens creados por la comunidad son bienvenidos. Formar parte del Gateway gestionado por Scroll significa que no necesitarás desplegar los contratos Gateway, y tu token aparecerá en el frontend de Scroll. Para formar parte de la Gateway de Scroll, debe ponerse en contacto con el equipo de Scroll para añadir el token a los contratos del bridge en L1 y L2. Para ello, siga las instrucciones del repositorio [token lists](https://github.com/scroll-tech/token-list) para añadir tu nuevo token al frontend oficial de Scroll.
+
+## API de la Gateway L1
+
+Visita la biblioteca [npm library](https://www.npmjs.com/package/@scroll-tech/contracts?activeTab=code) para consultar la documentación completa de la API de contratos de Scroll.
+
+### depositETH
+
+```solidity
+function depositETH(address _to, uint256 _amount, uint256 _gasLimit) public payable;
+```
+
+Envía ETH desde L1 a L2.
+
+| Parámetro | Descripción                                                                                                                 |
+| --------- | --------------------------------------------------------------------------------------------------------------------------- |
+| to        | Dirección de la cuenta del destinatario en L2.                                                                                   |
+| amount    | Cantidad de token a transferir, en wei.                                                                                    |
+| gasLimit  | Límite de gas necesario para completar el depósito en la L2. De 4000 a 10000 de gas debería ser suficiente para procesar la transacción. |
+
+### depositERC20
+
+```solidity
+function depositERC20(address _token, address _to, uint256 _amount, uint256 _gasLimit) payable;
+```
+
+Envía ERC20 tokens desde L1 a L2.
+
+| Parámetro | Descripción                                                                                                                 |
+| --------- | --------------------------------------------------------------------------------------------------------------------------- |
+| token     | Dirección del token en L1.                                                                                                    |
+| to        | Dirección de la cuenta del destinatario en L2.                                                                                   |
+| amount    | Cantidad de token a transferir, en wei.                                                                                    |
+| gasLimit  | Límite de gas necesario para completar el depósito en la L2. De 4000 a 10000 de gas debería ser suficiente para procesar la transacción. |
+
+### getL2ERC20Address
+
+```solidity
+function getL2ERC20Address(address _l1Token) external view returns (address);
+```
+
+Devuelve la dirección de token L2 correspondiente dada la dirección de token L1.
+
+| Parámetro | Descripción              |
+| --------- | ------------------------ |
+| \_l1Token | Dirección del token l1. |
+
+### updateTokenMapping
+
+```solidity
+function updateTokenMapping(address _l1Token, address _l2Token) external;
+```
+
+Actualiza el mapping que conecta un token ERC20 de L1 a L2.
+
+| Parámetro | Descripción                                     |
+| --------- | ----------------------------------------------- |
+| \_l1Token | Dirección del token ERC20 en L1.           |
+| \_l2Token | Dirección del token ERC20 correspondiente en L2. |
+
+## API de la Gateway L2
+
+### withdrawETH
+
+```solidity
+function withdrawETH(address to, uint256 amount, uint256 gasLimit) external payable;
+```
+
+Envia ETH desde L2 a L1.
+
+| Parámetro | Descripción                                                                                             |
+| --------- | ------------------------------------------------------------------------------------------------------- |
+| to        | Dirección de la cuenta del destinatario en L1.                                                               |
+| amount    | Cantidad de token a transferir, en wei.                                                                |
+| gasLimit  | Límite de gas necesario para completar el depósito en L1. Esto es opcional, envíe 0 si no desea establecerlo. |
+
+### withdrawERC20
+
+```solidity
+function withdrawERC20(address token, address to, uint256 amount, uint256 gasLimit) external payable;
+```
+
+Envia tokens ERC20 desde L2 a L1.
+
+| Parámetro | Descripción                                                                                             |
+| --------- | ------------------------------------------------------------------------------------------------------- |
+| token     | Dirección del token en L2.                                                                                |
+| to        | Dirección de la cuenta del destinatario en L1.                                                               |
+| amount    | Cantidad de token a transferir, en wei.                                                                |
+| gasLimit  | Límite de gas necesario para completar el depósito en L1. Esto es opcional, envíe 0 si no desea establecerlo. |
+
+### getL1ERC20Address
+
+```solidity
+function getL1ERC20Address(address l2Token) external view returns (address);
+```
+
+Devuelve la dirección de token L1 correspondiente dada una dirección de token L2.
+
+| Parámetro | Descripción                  |
+| --------- | ---------------------------- |
+| l2Token   | Dirección del token L2. |
+
+### updateTokenMapping
+
+```solidity
+function updateTokenMapping(address _l1Token, address _l2Token) external;
+```
+
+Actualizar el mapping que conecta un contrato ERC20 de L2 a L1.
+
+| Parámetro | Descripción                                     |
+| --------- | ----------------------------------------------- |
+| \_l2Token | Dirección del token ERC20 en L2.           |
+| \_l1Token | Dirección del token ERC20 correspondiente en L1. |
diff --git a/src/content/docs/es/developers/l1-and-l2-bridging/the-scroll-messenger.mdx b/src/content/docs/es/developers/l1-and-l2-bridging/the-scroll-messenger.mdx
new file mode 100644
index 000000000..ac180915b
--- /dev/null
+++ b/src/content/docs/es/developers/l1-and-l2-bridging/the-scroll-messenger.mdx
@@ -0,0 +1,139 @@
+---
+section: developers
+date: Last Modified
+title: "El Scroll Messenger"
+lang: "es"
+permalink: "developers/l1-and-l2-bridging/the-scroll-messenger"
+whatsnext: { "Comisiones de Transacciones en Scroll": "/es/developers/transaction-fees-on-scroll/" }
+excerpt: "La documentación de Scroll Messenger para el paso arbitrario de mensajes entre L1 y L2."
+---
+
+import Aside from "../../../../../components/Aside.astro"
+
+Los contratos Scroll Messenger permiten enviar mensajes arbitrarios de L1 a L2 o viceversa. Esto permite ejecutar funciones en otra cadena de forma segura y sin tener que pedirle permisos a un intermediario. Para enviar un mensaje de L1 a L2, utiliza
+el smart contract  desplegado en L1, `L1ScrollMessenger`. Para enviar un mensaje de L2 a L1, utiliza el contrato desplegado en L2, `L2ScrollMessenger`.
+
+<Aside type="caution" title="">
+  Cuando se envía una transacción a través del **Scroll Messenger** desplegado en L1 y L2, el remitente de la transacción resultante
+  (`CALLER` o `msg.sender`) será la dirección del contrato de Messenger desplegado en la cadena receptora.
+  <br />
+  En futuras versiones de Scroll, las transacciones forzadas desde el L1 permitirán establecer el remitente en L2 como el EOA original
+  original en L1. También permitirá a terceros retransmitir transacciones firmadas de forma segura.
+</Aside>
+
+## Finalización de transacciones en L1
+
+Cualquier transacción procedente de L2 necesita ser finalizada usando la función `relayMessageWithProof` en el contrato Scroll Messenger. Llamamos a este proceso "ejecución de una transacción de tipo Retiro", y es necesario tanto para enviar mensajes arbitrarios como para transferir activos a través de una gateway o del router. Cuando utilices `relayMessageWithProof`, tendrás que proporcionar una prueba de inclusión del Merkle Tree que demuestre que tu transacción está incluida en el trie de mensajes de "retiro", junto con otros parámetros. La producción de esta prueba y estos valores se puede hacer localmente y sin permisos, pero por el momento, la forma más fácil de recuperar estos parámetros es a través de nuestra API backend alojada en https://sepolia-api-bridge.scroll.io/api/.
+
+<Aside type="danger" title="API Experimental">
+  Esta API se ha creado para nuestra IU del Bridge. Aún no está finalizada y puede cambiar en el futuro. Actualizaremos esta guía
+  cuando la API esté finalizada.
+</Aside>
+
+Proporciona la dirección de la EOA o del contrato responsable de iniciar la transacción original en L2 al endpoint `/claimable`. La API te proporcionará toda la información necesaria para concluir con éxito la transacción en L1.
+Echa un vistazo al siguiente ejemplo:
+
+```bash
+https://sepolia-api-bridge.scroll.io/api/claimable?address=0x031407eaaffFB4f1EC2c999bE4477E52C81de3c5&page_size=10&page=1
+```
+
+La API debería devolverte los datos de su transacción en el siguiente formato:
+
+```json
+{
+  "errcode": 0,
+  "errmsg": "",
+  "data": {
+    "result": [
+      {
+        "hash": "0xa476850306d6ee52b127628ded34dcf2343570873cce9c5383bd497db48d4f9b",
+        "amount": "",
+        "to": "",
+        "isL1": false,
+        "l1Token": "",
+        "l2Token": "",
+        "blockNumber": 748,
+        "blockTimestamp": null,
+        "finalizeTx": {
+          "hash": "",
+          "amount": "",
+          "to": "",
+          "isL1": false,
+          "blockNumber": 0,
+          "blockTimestamp": null
+        },
+        "claimInfo": {
+          "from": "0x031407eaaffFB4f1EC2c999bE4477E52C81de3c5",
+          "to": "0x1039057185CFe192d16c03F5656225821A193FD5",
+          "value": "0",
+          "nonce": "9",
+          "batch_hash": "0x49a18d72dbceeb957f918947b532db452c031f528e7e6bf329007066638c5e50",
+          "message": "0xa413686200000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000005686f6c6973000000000000000000000000000000000000000000000000000000",
+          "proof": "0x69b4ee6cf9a38bed79668ddd347fef2bdff44c3760c9309fa41decfd60202d22ad3228b676f7d3cd4284a5443f17f1962b36e491b30a40b2405849e597ba5fb5b4c11951957c6f8f642c4af61cd6b24640fec6dc7fc607ee8206a99e92410d3079f53171df5c0661d2afe86c4d97b6f34278daf6a0ea9baff5b4fc979d5629a5",
+          "batch_index": "93"
+        },
+        "createdTime": null
+      }
+    ],
+    "total": 1
+  }
+}
+```
+
+El objeto `claimInfo` bajo el json `result` devuelto tiene toda la información necesaria para ejecutar su transacción en L1. Los parámetros que necesita `relayMessageWithProof` son: `from`, `to`, `value`, `nonce`, `message` y `proof`. Introduzca estos datos en
+la función `relayMessageWithProof` en L1 para ejecutar y finalizar tu transacción en L1.
+
+<Aside type="tip" title="">
+  Todas las transacciones L2 se agrupan en lotes: debes esperar a que finalice el lote que incluye tu transacción antes de llamar a `relayMessageWithProof`. El índice del lote de tu transacción se devuelve en el valor `batch_index` en el endpoint `/claimable`, y puedes seguir el progreso en el [Scroll Rollup
+  Explorer](https://scroll.io/rollupscan?page=1&per_page=10).
+</Aside>
+
+## API del Messenger
+
+Visita la [librería de npm](https://www.npmjs.com/package/@scroll-tech/contracts?activeTab=code) para consultar la documentación completa de la API de los contratos de Scroll.
+
+### sendMessage
+
+```solidity
+function sendMessage(
+  address target,
+  uint256 value,
+  bytes calldata message,
+  uint256 gasLimit,
+  address refundAddress
+) external payable;
+```
+
+Envía datos arbitrarios de una cadena a otra. Nos permite ejecutar funciones entre cadenas.
+
+| Parámetros    | Descripción                                                                                                         |
+| ------------- | ------------------------------------------------------------------------------------------------------------------- |
+| target        | Dirección de la cuenta que recibe el mensaje. El receptor puede ser un smart contract o una EOA. |
+| value         | Cantidad de ETH pasado al llamar al contrato destino.                                                        |
+| message       | Contenido del mensaje. Este es el calldata arbitrario a ejecutar.                                          |
+| gasLimit      | Límite de gas necesario para completar la retransmisión del mensaje en la cadena correspondiente.                                        |
+| refundAddress | Dirección de la cuenta que recibirá la comisión reembolsada.                                                      |
+
+### relayMessageWithProof
+
+```solidity
+function relayMessageWithProof(
+  address from,
+  address to,
+  uint256 value,
+  uint256 nonce,
+  bytes memory message,
+  L2MessageProof memory proof
+) external;
+```
+
+Retransmite un mensaje L2 => L1 con prueba de mensaje.
+
+| Parámetros | Descripción                                                  |
+| --------- | ------------------------------------------------------------ |
+| from      | Dirección del remitente del mensaje.                    |
+| to        | Dirección del destinatario del mensaje.                 |
+| value     | El msg.value pasado a la llamada del mensaje.                    |
+| nonce     | Nonce del mensaje para evitar ataques de tipo replay.             |
+| message   | Contenido del mensaje.                                  |
+| proof     | Prueba utilizada para verificar la corrección de la transacción. |
diff --git a/src/content/docs/es/developers/scroll-contracts.mdx b/src/content/docs/es/developers/scroll-contracts.mdx
new file mode 100644
index 000000000..a43981fe5
--- /dev/null
+++ b/src/content/docs/es/developers/scroll-contracts.mdx
@@ -0,0 +1,100 @@
+---
+section: developers
+date: Last Modified
+title: "Contratos de Scroll Sepolia"
+lang: "es"
+permalink: "developers/scroll-contracts"
+whatsnext: { "Diferencias entre Scroll y Ethereum": "/es/developers/ethereum-and-scroll-differences" }
+excerpt: "The network info and contract addresses you need to start with Scroll Sepolia Testnet."
+---
+
+import Aside from "../../../../components/Aside.astro"
+
+## Información de la Red
+
+| Nombre de Red       | Scroll Sepolia Testnet                                                        | Sepolia Testnet                                                              |
+| ------------------ | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
+| RPC URL            | [https://sepolia-rpc.scroll.io/](https://sepolia-rpc.scroll.io/)              | [https://eth-sepolia-public.unifra.io](https://eth-sepolia-public.unifra.io) |
+| Chain ID           | 534351                                                                        | 11155111                                                                     |
+| Currency Symbol    | ETH                                                                           | ETH                                                                          |
+| Block Explorer URL | [https://sepolia-blockscout.scroll.io](https://sepolia-blockscout.scroll.io/) | [https://sepolia.etherscan.io](https://sepolia.etherscan.io)                 |
+
+## Contratos de Scroll Sepolia
+
+### Rollup
+
+- L1 Rollup (Scroll Chain): `0x2D567EcE699Eabe5afCd141eDB7A4f2D0D6ce8a0`
+
+### ETH y ERC20 Bridge
+
+- L1 ERC20 Gateway Router: `0x13FBE0D0e5552b8c9c4AE9e2435F38f37355998a`
+- L2 ERC20 Gateway Router: `0x9aD3c5617eCAa556d6E166787A97081907171230`
+
+### Contratos de Bridge Avanzados
+
+- Scroll Messenger
+  - L1 Messenger: `0x50c7d3e7f7c656493D1D76aaa1a836CedfCBB16A`
+  - L2 Messenger: `0xBa50f5340FB9F3Bd074bD638c9BE13eCB36E603d`
+- ETH Bridge
+  - L1 ETH Gateway: `0x8A54A2347Da2562917304141ab67324615e9866d`
+  - L2 ETH Gateway: `0x91e8ADDFe1358aCa5314c644312d38237fC1101C`
+  - L1 WETH Gateway: `0x3dA0BF44814cfC678376b3311838272158211695`
+  - L2 WETH Gateway: `0x481B20A927206aF7A754dB8b904B052e2781ea27`
+- ERC20 Bridge
+  - L1 ERC20 Standard Gateway: `0x65D123d6389b900d954677c26327bfc1C3e88A13`
+  - L2 ERC20 Standard Gateway: `0xaDcA915971A336EA2f5b567e662F5bd74AEf9582`
+  - L1 ERC20 Custom Gateway: `0x31C994F2017E71b82fd4D8118F140c81215bbb37`
+  - L2 ERC20 Custom Gateway: `0x058dec71E53079F9ED053F3a0bBca877F6f3eAcf`
+- ERC721 Bridge
+  - L1 ERC721 Gateway: `0xEF27A5E63aa3f1B8312f744b9b4DcEB910Ba77AC`
+  - L2 ERC721 Gateway: `0x179B9415194B67DC3c0b8760E075cD4415785c97`
+- ERC1155 Bridge
+  - L1 ERC1155 Gateway: `0xa5Df8530766A85936EE3E139dECE3bF081c83146`
+  - L2 ERC1155 Gateway: `0xe17C9b9C66FAF07753cdB04316D09f52144612A5`
+- Gas Oracle
+  - L2 Gas Oracle (Implementado en Sepolia): `0x247969F4fad93a33d4826046bc3eAE0D36BdE548`
+
+### L2 Predeploys
+
+- Message Queue: `0x5300000000000000000000000000000000000000`
+- Gas Price Oracle: `0x5300000000000000000000000000000000000002`
+- Whitelist: `0x5300000000000000000000000000000000000003`
+- WETH L2: `0x5300000000000000000000000000000000000004`
+- Transaction Fee Vault: `0x5300000000000000000000000000000000000005`
+
+## Protocolos en Sepolia
+
+### Uniswap v3
+
+- Frontend website: [https://uniswap-showcase.sepolia.scroll.xyz/](https://uniswap-showcase.sepolia.scroll.xyz/)
+- Main Contracts
+  - Core Factory: `0xB856587fe1cbA8600F75F1b1176E44250B11C788`
+  - NFT Position Manager: `0xbbAd0e891922A8A4a7e9c39d4cc0559117016fec`
+  - Router: `0x17AFD0263D6909Ba1F9a8EAC697f76532365Fb95`
+- Additional Contracts
+  - multicall2Address: `0x8c181f4B9040F1a2C941EfD3b608712cF86F1957`
+  - proxyAdminAddress: `0xD4A9910732b6f301F6F210Ebe7a3dBf16d9E9DD4`
+  - tickLensAddress: `0x9804Da978427a49929f2E6Ea32A9594F03f9296e`
+  - nftDescriptorLibraryAddressV1_3_0: `0x45Bd3B62B7A3aA53371c98049b0f7A9C1A4B5a6c`
+  - nonfungibleTokenPositionDescriptorAddressV1_3_0: `0x24d4E4a572Dc1e0dbF92a0d7768Ac80df516b2C2`
+  - descriptorProxyAddress: `0xa8986417d0EAe50607696b9b0cb7ec5aFBE67765`
+  - v3MigratorAddress: `0x38E33D067F03a5cDc02C301b2c306cb0414549Bf`
+  - v3StakerAddress: `0xe7b82794Cab21e665a3e6f8ea562d392AA6E0619`
+  - quoterV2Address: `0xd5dd33650Ef1DC6D23069aEDC8EAE87b0D3619B2`
+
+### Aave
+
+Observa este [Github gist](https://gist.github.com/dghelm/7fe68f0a524f30846e1142721c081d84).
+
+## Contratos Útiles Adicionales
+
+- Multicall3: `0xcA11bde05977b3631167028862bE2a173976CA11`
+
+## Tokens
+
+<Aside type="note" title="">
+  Los tokens transferidos desde Sepolia utilizando el bridge nativo pueden añadirse al repositorio
+  [token-list](https://github.com/scroll-tech/token-list).
+</Aside>
+
+- Gho Token: `0xD9692f1748aFEe00FACE2da35242417dd05a8615`
diff --git a/src/content/docs/es/developers/transaction-fees-on-scroll.mdx b/src/content/docs/es/developers/transaction-fees-on-scroll.mdx
new file mode 100644
index 000000000..d7d231764
--- /dev/null
+++ b/src/content/docs/es/developers/transaction-fees-on-scroll.mdx
@@ -0,0 +1,174 @@
+---
+section: developers
+date: Last Modified
+title: "Comisiones de Transacciones en Scroll"
+lang: "es"
+permalink: "developers/transaction-fees-on-scroll"
+whatsnext: { "Tutorial de Despliegue de Contratos": "/es/developers/guides/contract-deployment-tutorial" }
+excerpt: "Aprende cómo funcionan las comisiones de las transacción en L1 y L2 de Scroll "
+---
+
+import Aside from "../../../../components/Aside.astro"
+
+## Vista General
+
+Las comisiones de Scroll Sepolia Testnet son notablemente menores a las de su capa de soporte. Para usuarios y desarrolladores, las comisiones por transacción en Scroll parecen funcionar de forma similar a las de la mainnet de Ethereum, y las herramientas, wallets y código existentes probablemente funcionarán como si lo fueran. Sin embargo, la comisión por transacción que se muestra en la billetera no es la imagen completa, a menos que el software conozca específicamente los cálculos de comisiones de Scroll.
+
+Debido al diseño de los rollups L2, los costos de transacción dependen de los costos de la L1. Para aprovechar la seguridad de Ethereum, Scroll debe tener en cuenta el costo de los datos de las transacciones y las pruebas que deben almacenarse y verificarse en la L1.
+
+Para lograr esto, Scroll Sepolia introduce algunas nuevas dimensiones en el cálculo de la comisión de transacción que no existen en Ethereum. El costo final de una transacción se construye a partir de varias partes:
+
+- **Comisión de L2**
+  - Calculada de la misma manera que en la L1, igual a `gas_price * gas_used`.
+- **Comisión de L1**
+  - Esta comisión adicional cubre el envío de datos a L1 para la disponibilidad de datos. Las transacciones iniciadas en el L1 no pagan esta comisión.
+  - Se calcula en función del tamaño de los datos de llamada de la transacción.
+  - El ETH se deduce automáticamente del saldo del usuario en Scroll para el pago de comisión
+
+En un plano general, la **comisión de L2** es el costo de ejecutar su transacción en el secuenciador L2, y la **comisión de L1** es el costo de guardar esa transacción en L1.
+
+En resumen, `totalTxFee = l2Fee + l1Fee`, todo ello denominado en ETH, el token de gas nativo de la red Scroll.
+
+<Aside type="note" title="¿Dónde se envían las comisiones de las transacciones?">
+Todas las comisiones de transferencia se recogen en el saldo del contrato `L2ScrollFeeVault`. Este contrato también realiza un seguimiento de la cantidad que hemos retirado históricamente a L1 utilizando `totalProcessed()(uint256)`.
+
+El productor del bloque no recibe ninguna recompensa directa, y el opcode `COINBASE` devuelve la dirección de la vault de la comisión.
+
+</Aside>
+
+## Comisiones de L2
+
+Las transacciones en Scroll, como en Ethereum, deben pagar el costo de ejecutar sus cálculos y almacenar los datos que producen.
+
+### Cálculo de la comisión de ejecución
+
+La comisión de ejecución de L2 es sencilla de calcular:
+
+```javascript
+l2TransactionExecutionFee = l2TransactionGasUsed * l2TransactionGasPrice
+```
+
+La comisión total depende de lo que haga la transacción (`l2TransactionGasUsed`), así como de las condiciones actuales del mercado (`l2TransactionGasPrice`). Los usuarios fijan el precio del gas, y el "gas utilizado" se evalúa llamando al endpoint `estimateGas` en un nodo Scroll.
+
+En otras palabras, la comisión de ejecución se calcula exactamente igual que antes de [EIP1559](https://eips.ethereum.org/EIPS/eip-1559) Ethereum.
+
+## Comisiones de L1
+
+La calldata de cada transacción deben confirmarse en Ethereum, lo que conlleva una comisión adicional por transacción, denominada "comisión de L1". De lo contrario, no se podría reconstruir Scroll a partir únicamente de datos de L1.
+
+Las transacciones no se guardan de 1 en 1, sino en lotes de bloques (y bloques de transacciones). El costo de una transacción individual se calcula en función de los bytes ceros y no ceros de su payload.
+
+### Estimación de la Comisión de Datos de L1
+
+Scroll tiene un `L1GasPriceOracle` pre-lanzado, accesible en Scroll Sepolia en ([`0x5300000000000000000000000000000000000000000000000002`](https://sepolia-blockscout.scroll.io/address/0x5300000000000000000000000000000000000002)). Proporciona un método `getL1Fee` para estimar la comisión de datos L1 para la raw data de una transacción dada.
+
+```solidity
+function getL1Fee(bytes memory _data) external view override returns (uint256);
+```
+
+<Aside type="note" title="¿Qué pasa si sube el precio del gas en L1?">
+
+Una vez que el secuenciador ha procesado una transacción, la comisión de L1 de un usuario queda bloqueada, y cualquier fluctuación no afectará a lo que paga el usuario.
+
+<br />
+Debido a los cortos tiempos de bloque de Scroll, cualquier cambio de gas en L1 entre el envío de una transacción y su inclusión en un bloque
+debería ser mínimo. El secuenciador absorberá cualquier cambio en los costos de gas en L1 entre la inclusión de una transacción en un bloque y
+cuando el secuenciador guarde los datos en L1.
+
+</Aside>
+
+### Cálculo de la Comisión de Datos en L1 con el Gas Oracle
+
+Como ya se ha mencionado, el `L1GasPriceOracle` se utiliza para estimar la comisión en L1 dados la raw data de la transacción. Se trata de un **push oracle**, actualizado por un relayer ejecutado por Scroll.
+
+La tarifa de datos se basa en múltiples factores:
+
+- Los bytes que son `ceros` y `no ceros` de una transacción codificada RLP con Firma
+- `l1BaseFee` - Comisión base actual en el L1
+- `overhead` - Sobrecarga de gas adicional de una transacción de compromiso de datos
+- `scalingFactor` - Factor de escala utilizado para tener en cuenta los picos de precios.
+- `PRECISION` - Constante utilizada para escalar la comisión final
+
+Para calcular la comisión por datos L1 se realizan los siguientes pasos:
+
+1. Se leen tres campos `l1BaseFee`, `overhead`, `scalar` del contrato `L1GasPriceOracle`. Los slots para estos campos en el contrato son:
+
+   | Campo     | Slot |
+   | --------- | ---- |
+   | l1BaseFee | 1    |
+   | overhead  | 2    |
+   | scalar    | 3    |
+
+2. Se cuenta el número de bytes cero y bytes no cero de la transacción.
+3. Se Calcula la comisión de datos de L1, dados `TX_DATA_ZERO_GAS = 4` y `TX_DATA_NON_ZERO_GAS = 16`[^eip-2028] y `PRECISION = 1e9`:
+
+   ```javascript
+   l1Gas = zeros * TX_DATA_ZERO_GAS + (nonzeros + 4) * TX_DATA_NON_ZERO_GAS
+   l1GasFee = ((l1Gas + overhead) * l1BaseFee * scalar) / PRECISION
+   ```
+
+   Reservamos 4 bytes adicionales en la sección de bytes no-ceros para guardar el número de bytes en la transacción codificada con RLP.
+
+[^eip-2028]: Para más información, véase [EIP-2028](https://eips.ethereum.org/EIPS/eip-2028).
+
+### API de L1GasPriceOracle
+
+#### overhead
+
+```solidity
+function overhead() external view returns (uint256);
+```
+
+Devuelve el exceso de comisión de L1 actual
+
+#### scalar
+
+```solidity
+function scalar() external view returns (uint256);
+```
+
+Devuelve el escalar de comisión de L1 actual
+
+#### l1BaseFee
+
+```solidity
+function l1BaseFee() external view returns (uint256);
+```
+
+Devuelve la última comisión base de L1 conocida
+
+#### getL1Fee
+
+```solidity
+function getL1Fee(bytes memory _data) external view returns (uint256);
+```
+
+Calcula la parte de la comisión de L1 en función del tamaño de la transacción de entrada codificada en RLP, la comisión base L1 actual y los distintos parámetros dinámicos.
+
+**Devuelve:** La comisión de L1 que debe pagarse por la transacción
+
+| Parámetro | Descripción                                                 |
+| --------- | ----------------------------------------------------------- |
+| data      | Transacción firmada totalmente codificada en RLP para obtener la comisión de L1. |
+
+#### getL1GasUsed
+
+```solidity
+function getL1GasUsed(bytes memory data) external view returns (uint256);
+```
+
+Calcula la cantidad de gas de L1 utilizado para una transacción. Añade el exceso que representa la sobrecarga de gas por transacción de publicar la transacción y las state roots en L1. Añade 74 bytes de relleno para tener en cuenta el hecho de que la entrada no tiene una firma.
+
+**Devuelve:** Cantidad de gas de L1 utilizado para publicar la transacción.
+
+| Parámetro | Descripción                                                 |
+| --------- | ----------------------------------------------------------- |
+| data      | Transacción firmada totalmente codificada en RLP para obtener la comisión L1. |
+
+## Roadmap Futuro
+
+En la actualidad, el cálculo necesario para la generación de pruebas es completado y financiado por Scroll y varios socios.
+
+A medida que la red de probadores se descentralice, será necesario incorporar incentivos a la generación de pruebas en el protocolo para que el sistema sea sostenible y escalable.
+
+Esperamos que el costo final del gas incluya el costo de esta generación de pruebas. Con una mayor optimización del protocolo, este costo para el usuario debería ser mínimo, ya que cada prueba cubre muchas transacciones.
diff --git a/src/content/docs/es/developers/verifying-smart-contracts.mdx b/src/content/docs/es/developers/verifying-smart-contracts.mdx
new file mode 100644
index 000000000..411e01387
--- /dev/null
+++ b/src/content/docs/es/developers/verifying-smart-contracts.mdx
@@ -0,0 +1,87 @@
+---
+section: developers
+date: Last Modified
+title: "Verificando Smart Contracts"
+lang: "es"
+permalink: "developers/verifying-smart-contracts"
+whatsnext: { "Scroll Contracts": "/es/developers/scroll-contracts" }
+excerpt: "Verifique fácilmente sus smart contracts con herramientas para desarrolladores compatibles con Scroll o con la Blockscout Web API."
+---
+
+import Aside from "../../../../components/Aside.astro"
+import ClickToZoom from "../../../../components/ClickToZoom.astro"
+import verify1 from "./_images/verify1.png"
+import CodeSample from "../../../../components/CodeSample/CodeSample.astro"
+
+Después de desplegar tus smart contracts, es importante verificar tu código en [nuestro block explorer](https://sepolia-blockscout.scroll.io/). Esto se puede hacer de forma automatizada utilizando tus herramientas de desarrollo o la IU web de Blockscout.
+
+<Aside type="danger" title="Alerta">
+  Nuestra instancia de Blockscout tiene actualmente un comportamiento inconsistente en la verificación de contratos con Foundry. Estamos trabajando en
+  junto con otras mejoras de estabilidad. No dudes en pedir ayuda en [nuestro
+  Discord](https://discord.com/channels/853955156100907018/1028102371894624337)
+</Aside>
+
+## Uso de las herramientas para desarrolladores
+La mayoría de las herramientas de smart contracts tienen plugins para verificar tus contratos fácilmente en Etherscan. Blockscout soporta las APIs de verificación de contratos de Etherscan, y es sencillo utilizar estas herramientas con la Scroll Sepolia Testnet.
+
+### Hardhat
+
+Primero, modifica `hardhat.config.ts` para que apunte al RPC de Scroll y a `sepolia-blockscout.scroll.io/api`. Se requiere un valor `apyKey` ficticio, cualquier valor servirá.
+
+```javascript
+...
+
+const config: HardhatUserConfig = {
+  ...
+  networks: {
+    scrollSepolia: {
+      url: 'https://sepolia-rpc.scroll.io' || '',
+      accounts:
+        process.env.PRIVATE_KEY !== undefined ? [process.env.PRIVATE_KEY] : [],
+    },
+  },
+  etherscan: {
+    apiKey: {
+      scrollSepolia: 'abc',
+    },
+    customChains: [
+      {
+        network: 'scrollSepolia',
+        chainId: 534351,
+        urls: {
+          apiURL: 'https://sepolia-blockscout.scroll.io/api',
+          browserURL: 'https://sepolia-blockscout.scroll.io/',
+        },
+      },
+    ],
+  },
+}
+
+...
+```
+
+Ahora puedes verificar el smart contract ejecutando el siguiente comando.
+
+```solidity
+npx hardhat verify --network scrollSepolia <contract address> <space separated constructor parameters>
+```
+
+Por ejemplo, así es como debería verse un smart contract que recibe dos parámetros tipo uint en el constructor:
+
+```solidity
+npx hardhat verify --network scrollSepolia 0xD9880690bd717189cC3Fbe7B9020F27fae7Ac76F 123 456
+```
+
+<Aside type="danger" title="Alerta">
+  Es posible que recibas un error que indica que `etherscan.apiKey.trim no es una función` . Si es así, es necesario actualizar
+  `@nomiclabs/hardhat-etherscan` para poder soportar chains personalizadas. Intenta ejecutar `npm update
+  @nomiclabs/hardhat-etherscan`.
+</Aside>
+
+### Foundry
+
+Cuando se utiliza Foundry, la función `verify-contract` ayuda a automatizar el proceso de verificación de los contratos.
+
+```bash
+forge verify-contract <Contract Address> <Space separated params> <Solidity file>:<Contract name> --chain-id 534351 --verifier-url <https://sepolia-blockscout.scroll.io/api> --verifier blockscout
+```
diff --git a/src/content/docs/es/getting-started/overview.md b/src/content/docs/es/getting-started/overview.md
new file mode 100644
index 000000000..c5e53feae
--- /dev/null
+++ b/src/content/docs/es/getting-started/overview.md
@@ -0,0 +1,44 @@
+---
+section: gettingStarted
+date: Last Modified
+title: "Vista General de Scroll"
+lang: "es"
+permalink: "docs/conceptual-overview/"
+excerpt: "ZK Rollups and Scroll"
+whatsnext: { "Guía de Usuario": "/es/user-guide/", "Construyendo en Scroll": "/es/developers/" }
+---
+
+#### ¡Bienvenido a la documentación de Scroll!
+
+Scroll es una solución de escalabilidad centrada en la seguridad de Ethereum, que utiliza innovaciones en el diseño de escalado y pruebas de “zero-knowledge” para construir una nueva capa en Ethereum. La red de Scroll es más accesible, más receptiva y puede soportar a más usuarios a la vez que Ethereum por sí solo, y si alguna vez has utilizado o desarrollado una aplicación en Ethereum, te sentirás como en casa.
+
+¿Quieres probar la Scroll Sepolia Testnet? Echa un vistazo a nuestra. [Guía de Usuario](/es/user-guide/).
+
+## ¿Qué está construyendo Scroll?
+
+Scroll está construyendo la tecnología para escalar Ethereum.
+
+Aunque Ethereum es la principal red de blockchain para alimentar aplicaciones descentralizadas, su popularidad también conlleva costos más altos, lo que crea una barrera para la adopción de la próxima ola de usuarios y desarrolladores.
+
+Aprovechando investigaciones punteras en pruebas de “zero-knowledge” ("zk"), Scroll está construyendo una red de segunda capa (Layer 2 rollup) en Ethereum. El equipo, en colaboración de código abierto con otros en la comunidad de Ethereum, ha creado un "zkEVM" que permite que toda la actividad en la red, que se comporta de manera similar a Ethereum, esté asegurada por smart contracts en Ethereum. La red publica todas las transacciones en Ethereum, y el zkEVM crea y publica "pruebas" criptográficas de que la red de Scroll sigue las reglas de Ethereum.
+
+En última instancia, los smart contracts de Ethereum verifican que cada transacción en Scroll sea válida para estas pruebas, brindando a la red una increíble seguridad, descentralización y resistencia a la censura. Este nivel de seguridad y escalabilidad para Ethereum solo es posible gracias a avances recientes en criptografía de “zero-knowledge”, diseño de protocolos blockchain y aceleración de hardware.
+
+<!-- TODO: Confirm Architecture page exists -->
+
+Para obtener más información sobre nuestra arquitectura, consulta. [Arquitectura de Scroll](/es/technology/).
+
+## ¿Puedo usar Scroll hoy?
+
+Nuestra Scroll Sepolia testnet está funcionando. Aunque tenemos una [guía completa](/es/user-guide/), si estás familiarizado/a con el uso de Ethereum, puedes comenzar en minutos:
+
+- Visita nuestro [Bridge](https://scroll.io/bridge) y conecta tu wallet
+- Envía tokens de Ethereum Sepolia Testnet a la Scroll Sepolia Testnet
+  (o usa un [faucet](/es/user-guide/faucet))
+- Prueba una aplicación descentralizada (dapp) con nuestra [Uniswap Showcase](http://uniswap-showcase.sepolia.scroll.xyz/) -- ¡solo asegúrate de seleccionar la red Scroll Sepolia!
+
+<!-- TODO: Add Aave after Sepolia goes live -->
+
+## ¿Hacia dónde se dirige Scroll?
+
+Actualmente nos encontramos en nuestra red de pruebas final antes de lanzar nuestra mainnet en Ethereum. A continuación, descentralizaremos cada componente de la infraestructura. Echa un vistazo a [nuestro roadmap](https://scroll.io), síguenos en [nuestro Discord](https://discord.gg/scroll) o en [Twitter](https://twitter.com/scroll_zkp) para estar al tanto.
diff --git a/src/content/docs/es/glossary.md b/src/content/docs/es/glossary.md
new file mode 100644
index 000000000..1f0a3ac6c
--- /dev/null
+++ b/src/content/docs/es/glossary.md
@@ -0,0 +1,71 @@
+---
+section: developers
+date: Last Modified
+title: "English to Spanish Glosary"
+lang: "es"
+permalink: "glossary"
+excerpt: "Translation of English terms into Spanish"
+---
+
+| English                                         | Spanish                                      |
+| ----------------------------------------------- | -------------------------------------------- |
+| Assembly                                        | Ensamblador                                  |
+| Key-value pair                                  | Par llave-valor                              |
+| Tree                                            | Árbol                                        |
+| Leaf node                                       | Nodo hoja                                    |
+| Branch node                                     | Nodo rama                                    |
+| Root node                                       | Nodo raíz                                    |
+| Mapping                                         | Mapeo                                        |
+| Leaf node                                       | Nodo hoja                                    |
+| Bridge                                          | Bridge (masculino)                           |
+| Bridging                                        | Bridging, conexión                           |
+| Assets                                          | Activos                                      |
+| Fee                                             | Comisión                                     |
+| Gateway                                         | La Gateway (femenino)                        |
+| On-chain                                        | On-chain                                     |
+| Token                                           | Token                                        |
+| zero-knowledge Proof                            | Prueba Conocimiento Cero                     |
+| Rollup                                          | Rollup                                       |
+| Bytecode                                        | Bytecode                                     |
+| Testnet                                         | Red de Prueba                                |
+| Smart Contract                                  | Contrato Inteligente                         |
+| Merge                                           | Merge                                        |
+| Mainnet                                         | Red Principal                                |
+| Builders                                        | Constructores                                |
+| RPC                                             | RPC                                          |
+| Faucet                                          | Faucet                                       |
+| Setup                                           | Configuración                                |
+| Chain ID                                        | Identificador de Cadena                      |
+| Currency Symbol                                 | Símbolo de Moneda                            |
+| Block Explorer URL                              | URL de Explorador de Bloques                 |
+| HartHat                                         | HartHat                                      |
+| Foundry                                         | Foundry                                      |
+| IDE                                             | Entorno de Desarrollo Integrado              |
+| Deploy                                          | Desplegar, lanzar                            |
+| Run                                             | Ejecutar                                     |
+| Transactions                                    | Transacciones                                |
+| Environment                                     | Entorno                                      |
+| Injected Provider                               | Proveedor de Inyecciones                     |
+| Truffle                                         | Truffle                                      |
+| Brownie                                         | Brownie                                      |
+| Script                                          | Script                                       |
+| Wallet                                          | Billetera                                    |
+| Frontend                                        | Frontend                                     |
+| IU                                              | Interfaz de Usuario                          |
+| Plugins                                         | Complementos                                 |
+| API                                             | API                                          |
+| Gateway                                         | Gateway                                      |
+| Router                                          | Enrutador                                    |
+| Scroll                                          | Scroll                                       |
+| Ethereum                                        | Ethereum                                     |
+| Zero-knowledge                                  | Conocimiento cero                            |
+| Layer 2 rollup                                  | Rollup de capa 2                             |
+| Smart contracts                                 | Contratos inteligentes                       |
+| Mainnet                                         | Red principal                                |
+| Polynomial commitment scheme                    | Esquema de compromiso de polinomios          |
+| Commitment                                      | Compromiso, guardado                         |
+| Proof of validity                               | Prueba de validez                            |
+| Proof of fraud                                  | Prueba de fraude                             |
+| Optimistic rollup                               | Rollup optimista                             |
+| zkVM (Zero-Knowledge Virtual Machine)           | Máquina Virtual zk (Zero-Knowledge)          |
+| zkEVM (Zero-Knowledge Ethereum Virtual Machine) | Máquina Virtual Ethereum zk (Zero-Knowledge) |
diff --git a/src/content/docs/es/learn/index.mdx b/src/content/docs/es/learn/index.mdx
new file mode 100644
index 000000000..d68f94ac8
--- /dev/null
+++ b/src/content/docs/es/learn/index.mdx
@@ -0,0 +1,28 @@
+---
+section: learn
+title: "Aprende"
+lang: "es"
+permalink: "learn/"
+excerpt: "Learn more about Ethereum scalability and zero knowledge cryptography."
+---
+
+import NavCard from "../../../../components/NavCard.astro"
+
+Scroll reúne la investigación y la ingeniería de protocolos blockchain y criptografía zero knowledge. Si quieres profundizar más, sigue leyendo y consulta los recursos adicionales.
+
+¿Desea que se trate un tema específico? Crea [un issue](https://github.com/scroll-tech/scroll-documentation/issues/new?assignees=&labels=new+content%2Ctriage&projects=&template=new_content.yml&title=%5BNew+Content%5D%3A+%3Cyour-title-here%3E) en nuestro repositorio de Github.
+
+<div class="navs" class="flex flex-col flex-wrap items-center md:flex-row md:gap-8 md:items-start">
+  <NavCard
+    icon="/svgs/home-technology.svg"
+    name="Ethereum y Protocolos"
+    content="Comprende el ecosistema de Ethereum y cómo encaja Scroll en él."
+    link="/es/learn/the-scalability-problem"
+  />
+  <NavCard
+    icon="/svgs/home-learn.svg"
+    name="Zero Knowledge"
+    content="Conozca la criptografía zero knowledge y sus aplicaciones."
+    link="/es/learn/zero-knowledge/introduction-to-zero-knowledge"
+  />
+</div>
diff --git a/src/content/docs/es/learn/intro-to-rollups.md b/src/content/docs/es/learn/intro-to-rollups.md
new file mode 100644
index 000000000..6b8ac34bb
--- /dev/null
+++ b/src/content/docs/es/learn/intro-to-rollups.md
@@ -0,0 +1,51 @@
+---
+section: learn
+date: Last Modified
+title: "Intro a los Rollups"
+lang: "es"
+permalink: "learn/intro-to-rollups"
+excerpt: "Los rollups son la solución de escalado de capa 2 más predominante en el ecosistema Ethereum."
+whatsnext: { "Proceso del Rollup": "/es/technology/chain/rollup" }
+---
+
+## ¿Qué es un rollup?
+
+Los rollups son la solución de escalado de capa 2 más predominante en el ecosistema Ethereum, y se consideran una [parte central](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) de la hoja de ruta de Ethereum.
+
+Un rollup procesa lotes de transacciones fuera de la cadena (es decir, no en la capa 1), y luego publica los datos resultantes en la cadena (es decir, en la capa 1).
+
+La ejecución de cada transacción se realiza fuera de la cadena, y no es necesario que los nodos de la capa 1 vuelvan a ejecutarla. Esto permite un alto rendimiento de las transacciones, sin afectar a la descentralización de la capa 1.
+
+Para que un rollup sea seguro, debe demostrar que su cálculo fuera de la cadena (el procesamiento de las transacciones) se ha realizado correctamente. Existen principalmente dos mecanismos para demostrar la validez del cálculo fuera de la cadena: las pruebas de validez y las pruebas de fraude.
+
+## ¿Qué es un optimistic rollup?
+
+Un optimistic rollup es un rollup que utiliza pruebas de fraude para afirmar la validez de sus cálculos.
+
+Las pruebas de fraude son un mecanismo que permite a los usuarios cuestionar y demostrar la invalidez de cualquier cálculo realizado en el L2. Si una prueba de fraude se presenta con éxito, la L2 puede volver a un estado anterior y el cálculo no válido puede ser corregido. Las pruebas de fraude dependen de que al menos una parte honesta compruebe que las transacciones de la L2 se han ejecutado correctamente.
+
+## ¿Qué es un ZK rollup?
+
+Un ZK rollup es un rollup que utiliza pruebas de validez para afirmar la legitimidad de sus cálculos.
+
+Cuando un ZK rollup ejecuta un lote de transacciones y publica el estado resultante en L1, también publica una prueba de validez. Esta prueba matemática demuestra que el estado resultante es efectivamente el estado resultante de ejecutar correctamente el lote de transacciones.
+
+En la actualidad, existen múltiples tipos de ZK rollups, definidos en términos generales como zkVMs (zk Virtual Machines) o zkEVMs (zk Ethereum Virtual Machines).
+
+Los zkVMs están diseñados desde cero para trabajar bien con circuitos ZK y requieren diferentes flujos de trabajo de desarrollo en comparación con un zkEVM. Algunos ejemplos son Starkware y Aztec.
+
+Los zkEVMs están diseñados para emular la EVM. Existen dos tipos principales de zkEVMs: compatibles con bytecode y compatibles con lenguaje. Las zkEVM compatibles con bytecode emulan la EVM a un nivel muy bajo, permitiendo un desarrollo y una experiencia de usuario casi idénticos en comparación con Ethereum Layer 1. Los zkEVMs compatibles con lenguajes compilan Solidity y otros lenguajes de alto nivel en diferentes bytecodes, lo que puede resultar en cambios en el flujo de trabajo. zkSync es el zkEVM compatible con lenguajes más popular.
+
+Scroll es compatible con bytecode. Se eligió este enfoque porque aporta ciertas ventajas:
+
+- Solidity, Vyper y Huff funcionan desde el primer momento.
+- No es necesario volver a auditar
+- Se hereda la mayoría de las herramientas existentes
+- UX y DevX casi idénticos a los de Ethereum.
+
+Encontrará más información sobre el enfoque de Scroll en la sección Tecnología.
+
+## Lecturas adicionales
+
+- [An Incomplete Guide to Rollups](https://vitalik.ca/general/2021/01/05/rollup.html) - Vitalik Buterin
+- [Scaling](https://ethereum.org/en/developers/docs/scaling/) - Ethereum Docs
diff --git a/src/content/docs/es/learn/the-scalability-problem.md b/src/content/docs/es/learn/the-scalability-problem.md
new file mode 100644
index 000000000..d26781c5f
--- /dev/null
+++ b/src/content/docs/es/learn/the-scalability-problem.md
@@ -0,0 +1,27 @@
+---
+section: learn
+date: Last Modified
+title: "El Problema de la Escalabilidad"
+lang: "es"
+permalink: "learn/intro-to-rollups"
+excerpt: "La fuerte descentralización y seguridad de Ethereum se consigue a costa de sacrificar la escalabilidad: para garantizar que todos los nodos participantes puedan seguir el ritmo de la red, el rendimiento de ésta es limitado. Este límite se traduce en costos y latencias más elevados para los usuarios."
+whatsnext: { "Intro a los Rollups": "/es/learn/intro-to-rollups" }
+---
+
+## El problema de escalabilidad de Ethereum
+
+[Ethereum](https://ethereum.org/en/developers/docs/intro-to-ethereum/#what-is-ethereum) es una blockchain de propósito general que soporta el despliegue y ejecución de [smart contracts](https://ethereum.org/en/developers/docs/intro-to-ethereum/#what-are-smart-contracts).
+
+Una de las características que definen a Ethereum es su compromiso inquebrantable con la seguridad y la descentralización. Ethereum está diseñado para que ordenadores de todo el mundo (incluso los más baratos, como una [Raspberry Pi](https://ethereum-on-arm-documentation.readthedocs.io/)) puedan participar en la red, ejecutar copias locales de la blockchain y procesar nuevas transacciones.
+
+Sin embargo, la fuerte descentralización y seguridad de Ethereum se consigue a costa de sacrificar la escalabilidad: para garantizar que todos los nodos participantes puedan seguir el ritmo de la red, el rendimiento de ésta es limitado. En última instancia, este límite se traduce en mayores costos y latencias para los usuarios.
+
+## Soluciones de Escalabilidad
+
+Las soluciones de escalabilidad de Ethereum tienen como objetivo aumentar el rendimiento de la red sin sacrificar la descentralización o la seguridad.
+
+Existen principalmente dos tipos de soluciones de escalado: soluciones de escabilidad de capa 1 y soluciones de escabilidad de capa 2.
+
+**La Capa 1** (o **L1**) intenta escalar la red modificando directamente la blockchain de Ethereum. El término "capa 1" se refiere aquí a la cadena de bloques principal de Ethereum. En general, es muy difícil diseñar soluciones de escalado de capa 1 que aumenten el rendimiento y, al mismo tiempo, preserven altos niveles de seguridad y descentralización. Por ello, los recientes esfuerzos de escalado se han alejado de las soluciones de capa 1 y se han orientado hacia soluciones de capa 2.
+
+**La Capa 2** (o **L2**) de soluciones de escalado son redes que viven **en la parte superior** de la capa 1 de Ethereum - son esencialmente blockchains separadas que están "ancladas" a la blockchain subyacente de Ethereum de alguna manera. Estas redes de capa 2 generalmente pueden procesar transacciones a un ritmo mayor que la red de capa 1 subyacente, ya que no están sujetas a las mismas limitaciones. El mecanismo de "anclaje", cuyos detalles varían según la capa 2, permite a la red de capa 2 heredar las sólidas propiedades de seguridad y descentralización de la capa 1 de Ethereum.
diff --git a/src/content/docs/es/learn/zero-knowledge/additional-zk-learning-resources.md b/src/content/docs/es/learn/zero-knowledge/additional-zk-learning-resources.md
new file mode 100644
index 000000000..415705887
--- /dev/null
+++ b/src/content/docs/es/learn/zero-knowledge/additional-zk-learning-resources.md
@@ -0,0 +1,26 @@
+---
+section: learn
+date: Last Modified
+title: "Recursos de Aprendizaje ZK Adicionales"
+lang: "es"
+permalink: "learn/zero-knowledge/additional-zk-learning-resources"
+excerpt: "¿Quieres profundizar en ZK? Éstos son algunos de nuestros recursos favoritos."
+---
+
+¿Quieres profundizar en el ZK? Aquí tienes algunos de nuestros recursos favoritos.
+
+## Vídeo
+
+- [ZK Whiteboard Sessions](https://youtube.com/playlist?list=PLj80z0cJm8QErn3akRcqvxUsyXWC81OGq)
+  - Estas sesiones de whiteboard son una forma fantástica de aprender sobre ZK. Las tres primeras conferencias de Dan Boneh proporcionan una gran base sobre la que se construyen las siguientes, en las que se analizan los desarrollos más recientes.
+- [Zero Knowledge Proofs MOOC](https://youtube.com/playlist?list=PLS01nW3Rtgor_yJmQsGBZAg5XM4TSGpPs)
+  - Un MOOC que cubre las pruebas zero knowledge desde los primeros principios, hasta los temas modernos de la industria.
+- [The 9th BIU Winter School on Cryptography - Zero Knowledge](https://youtube.com/playlist?list=PL8Vt-7cSFnw29cLUVqAIuMlg1QJ-szV0K)
+  - Estas conferencias sientan las bases teóricas zero knowledge - están dirigidas a académicos y público con madurez matemática.
+- [ZK Symposium](https://www.youtube.com/playlist?list=PLrzRr7okCcmbAlgYpuFjzUJv8tAyowDQY)
+  - Una mezcla de presentaciones teóricas y aplicadas de algunos de los mejores investigadores y creadores de productos en el ámbito zero-knowledge.
+
+## Texto
+
+- [Proofs, Arguments, and Zero-Knowledge](https://people.cs.georgetown.edu/jthaler/ProofsArgsAndZK.html) - Justin Thaler
+  - Un libro de texto completo sobre la teoría zero-knowledge.
diff --git a/src/content/docs/es/learn/zero-knowledge/introduction-to-zero-knowledge.mdx b/src/content/docs/es/learn/zero-knowledge/introduction-to-zero-knowledge.mdx
new file mode 100644
index 000000000..66614320a
--- /dev/null
+++ b/src/content/docs/es/learn/zero-knowledge/introduction-to-zero-knowledge.mdx
@@ -0,0 +1,75 @@
+---
+section: learn
+date: Last Modified
+title: "Introducción a Zero Knowledge"
+lang: "es"
+permalink: "learn/zero-knowledge/introduction-to-zero-knowledge"
+whatsnext: { "Polynomial Commitment Schemes": "/es/learn/zero-knowledge/polynomial-commitment-schemes" }
+excerpt: 'En la última década, un campo de la criptografía llamado "zero-knowledge" ha avanzado rápidamente. Promete nuevas formas de crear aplicaciones y permite que los protocolos aumenten la eficacia, la seguridad y la privacidad.'
+---
+
+import Aside from "../../../../../components/Aside.astro"
+
+En la última década, un campo de la criptografía llamado "zero-knowledge" ha avanzado rápidamente. Promete nuevas formas de crear aplicaciones y permite que los protocolos aumenten la eficacia, la seguridad y la privacidad.
+
+Examinemos qué hace que el campo de las pruebas "zero-knowledge" sea tan interesantes y qué problemas ayuda a resolver a los ingenieros.
+
+## Blockchains Trustless y Verificabilidad
+
+Las blockchains suelen funcionar procesando transacciones enviadas por los usuarios. Estas transacciones suelen desencadenar algún tipo de cálculo que la blockchain debe realizar.
+
+Para que la blockchain sea "trustless" (es decir, no dependa de la confianza en una parte concreta), los participantes en la red deben verificar que las transacciones son válidas y que los cálculos resultantes se han realizado correctamente.
+
+Comprobar que la transacción es válida suele requerir la verificación de la firma digital, que comprueba que el remitente de la transacción es realmente el autor de la misma. La verificación de que el cálculo de una transacción se ha realizado correctamente suele requerir la reejecución local de la transacción.
+
+## Limitaciones de la Verificabilidad
+
+Esta metodología de verificación de cada transacción se rompe en situaciones en las que un participante no puede volver a ejecutar el cálculo. Un participante puede no ser capaz de volver a ejecutar el cálculo por un par de razones: (1) podría ser que ciertos datos no estén disponibles (por razones de privacidad), o (2) puede ser demasiado caro para un ordenador participante volver a ejecutar todas las transacciones - esta segunda razón es especialmente relevante cuando se consideran blockchains de alto rendimiento con un gran número de transacciones por segundo.
+
+## El Poder de las Zero-Knowledge Proofs
+
+Las Zero-knowledge proofs (ZKP) permiten superar estas limitaciones.
+
+Las ZKP permiten a los participantes verificar los resultados de un cálculo (1) preservando la privacidad de cualquier dato sensible utilizado en el cálculo, y (2) haciendo que la verificación sea significativamente más barata que volver a ejecutar el cálculo. Estas dos propiedades de las ZKP se denominan **zero-knowledge** y **succinctness**, respectivamente.
+
+Estas propiedades de las ZKP son extremadamente útiles en el contexto de la verificabilidad de las blockchains "trustless". Sin ZKP, los participantes tienen que volver a ejecutar el cálculo resultante de cada transacción. Esto requiere que todos los participantes vean todos los datos (potencialmente sensibles) utilizados en cada cálculo, y también limita el rendimiento de todo el sistema. Con las ZKP, una parte puede realizar el cálculo y, a continuación, generar una prueba de que el cálculo se ha realizado correctamente. Otros participantes pueden verificar que el cálculo se ha realizado correctamente _verificando que la prueba es válida_, en lugar de volver a ejecutar el cálculo ellos mismos. Verificar la prueba (1) no filtra información sobre datos sensibles utilizados en el cálculo original, y (2) es significativamente más barato computacionalmente que volver a ejecutar el cálculo original. Estas dos propiedades tienen el potencial de permitir la privacidad y la escalabilidad de las blockchains trustless.
+
+## Circuitos, Pruebas y Verificadores
+
+En la práctica, las ZKP pueden ser bastante complejas de implementar en un sistema, pero a un alto nivel, te gustaría entender que las pruebas de zero-knowledge tienen unos pocos componentes: un circuito, una prueba y un verificador.
+
+El circuito es un programa que recibe datos de entrada y afirma que los datos de entrada son válidos de acuerdo con algunas "restricciones" que los datos de entrada deben satisfacer. Los datos de entrada pueden ser públicos (conocidos por todos), privados (conocidos sólo por el verificador) o mixtos (algunos datos de entrada son públicos y otros privados).
+
+Se puede generar una prueba, afirmando que una entrada satisface el circuito. La prueba no revela información sobre las entradas privadas y es bastante pequeña.
+
+El verificador puede comprobar (1) que la prueba es válida, (2) que la prueba coincide con las restricciones establecidas por el circuito (y no es sólo una prueba falsa), y (3) que las entradas públicas utilizadas para generar la prueba coinciden con las utilizadas por el verificador. Ten en cuenta que esta comprobación realizada por el verificador suele ser un cómputo barato.
+
+<Aside type="tip" title="">
+  Puedes notar que el verificador no tiene una salida más allá de "prueba válida" o "prueba inválida". Recuerde, el
+  verificador sólo confirma otros cálculos - en la práctica, las "salidas" de una función en realidad podría terminar siendo
+  entradas adicionales a un circuito y verificador.
+</Aside>
+
+### Circuitos, Pruebas y Verificadores — un ejemplo
+
+Tomemos el Sudoku como ejemplo. Supongamos que hay un rompecabezas Sudoku, y Alice quiere demostrar a Bob que conoce una solución al rompecabezas, pero no quiere revelar cuál es la solución.
+
+En este caso, el rompecabezas en particular será una entrada pública (tanto Alice como Bob lo saben), y la solución es una entrada privada (Alice lo sabe, pero lo mantendrá en privado de Bob). El **circuito** tomaría ambas entradas y afirmaría que la solución es correcta comprobándola de la forma estándar, fila a fila, columna a columna, etc. De este modo, el circuito "restringe" que la solución de la entrada privada sea realmente una solución válida para el puzzle de la entrada pública, y sólo se "satisface" cuando se supera la comprobación de la solución.
+
+Entonces se puede generar una **prueba** que establezca que Alice conoce una entrada que satisface el circuito para el puzzle en particular (la entrada pública).
+
+La prueba, junto con el puzzle, podría pasarse a Bob, que podría utilizar un **verificador** correspondiente al circuito de comprobación del Sudoku para evaluar si la prueba es válida y, por tanto, si Alice conoce la solución del puzzle. Bob no obtiene ningún conocimiento de la solución de Alice, pero puede verificar que ella conoce una solución válida.
+
+## Zero-Knowledge Proofs y Blockchains
+
+Una de las principales motivaciones de los recientes avances en las ZKP es su aplicación a las cadenas de bloques. Dos de los principales retos a los que se enfrentan las blockchains descentralizadas son la privacidad y la escalabilidad: todos los datos son públicos y cada nodo de la red tiene que volver a ejecutar cada cálculo en la red. Las ZKP pueden ayudar a resolver ambos problemas.
+
+Aunque hay varios proyectos que utilizan la característica de zero-knowledge de las ZKP para crear aplicaciones que preserven la privacidad, en Scroll sólo utilizamos la característica de concisión de las ZKP para escalar Ethereum.
+
+## Scroll y Zero Knowledge Proofs
+
+La idea que impulsa Scroll es bastante simple. ¿Qué pasaría si pudiéramos utilizar un Smart Contract de Ethereum para verificar todos los cálculos de otra versión de Ethereum? Podríamos ejecutar otra red que proporcionara un acceso más rápido y barato a una máquina virtual de Ethereum ("EVM"), y Ethereum proporcionaría la seguridad necesaria para validar todos los cálculos y asegurarse de que esta otra red no infringe las reglas de la EVM.
+
+El resto de las secciones de Aprende y Tecnología explican cómo funciona esto con más detalle, pero a un nivel sencillo, recuerda que las zero-knowledge se basan en tener un circuito, una prueba y un verificador.
+
+En nuestra construcción, el circuito (en realidad un conjunto de circuitos) codifica las reglas de la EVM para "restringir" el comportamiento aceptable para procesar las transacciones de entrada relativas al estado de la cadena. Utilizando esta "zkEVM", una red de GPUs toma las transacciones de un conjunto de bloques y genera una prueba. Y de vuelta a Ethereum, un smart contract verifica que, para un conjunto de transacciones, esta prueba coincide con el circuito consagrado en el smart contract. Si es así, esas transacciones pueden considerarse "finalizadas", la red avanza y hemos creado un espacio de bloques rápido, seguro y asequible para el crecimiento de Ethereum.
diff --git a/src/content/docs/es/learn/zero-knowledge/kzg-commitment-scheme.md b/src/content/docs/es/learn/zero-knowledge/kzg-commitment-scheme.md
new file mode 100644
index 000000000..067992dd0
--- /dev/null
+++ b/src/content/docs/es/learn/zero-knowledge/kzg-commitment-scheme.md
@@ -0,0 +1,70 @@
+---
+section: learn
+date: Last Modified
+title: "Esquema de Compromiso KZG"
+lang: "es"
+permalink: "learn/zero-knowledge/kzg-commitment-scheme"
+excerpt: "KZG se utiliza Proto-Danksharding de Ethereum, y también se utiliza en el sistema de pruebas de Scroll. Este artículo dará una visión general del esquema de compromiso KZG."
+whatsnext: { "Recursos Adicionales": "/es/learn/zero-knowledge/additional-zk-learning-resources" }
+---
+
+Uno de los esquemas de compromiso polinómico más utilizados es el esquema de compromiso KZG. El esquema fue originalmente [publicado](https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf) en 2010 por Kate, Zaverucha y Goldberg.
+
+KZG se utiliza en [Proto-Danksharding](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) de Ethereum, y también se utiliza en el sistema de pruebas de Scroll.
+
+Este artículo dará una visión general del esquema de compromiso KZG.ç
+
+## Preliminares y notaciones
+
+Recordemos la premisa de los esquemas de compromiso polinómico. Tenemos algún polinomio $P(x)$ que nos gustaría comprometer. Asumiremos que el polinomio tiene un grado menor que $l$.
+
+KZG compromisos se basan en una [curva elíptica de pares](https://vitalik.ca/general/2017/01/14/exploring_ecp.html). Sean $\mathbb{G}_1$ y $\mathbb{G}_2$ dos grupos de curvas elípticas de orden $p$, con un no trivial [mapeo bilineal](https://en.wikipedia.org/wiki/Bilinear_map) $e: \mathbb{G}_1 \times \mathbb{G}_2 \rightarrow \mathbb{G}_T$. Sea $g$ un generador de $\mathbb{G}_1$, y $h$ un generador de $\mathbb{G}_2$. Utilizaremos la notación $[x]_1 := x \cdot g$ y $[x]_2 := x \cdot h$, donde $x \in \mathbb{F}_p$.
+
+## 1. Ceremonia o Trusted Setup
+
+Antes de calcular cualquier compromiso KZG, se debe realizar una única trusted setup. Una vez completada, puede reutilizarse para comprometer y revelar tantos polinomios diferentes como se desee. La trusted setup funciona de la siguiente manera:
+
+- Elija algún elemento de campo aleatorio $\tau \in \mathbb{F}_p$
+- Sea $l \in \mathbb{Z}$ el grado máximo de los polinomios que queremos comprometer a
+  - La trusted setup sólo permitirá compromisos con polinomios de grado $\leq l$
+- Se calcula $([\tau^0]_1,[\tau^1]_1,[\tau^{2}]_1\ldots,[\tau^{l}]_1)$ y $([\tau]_2)$, y se dan a conocer estos valores públicamente.
+
+Ten en cuenta que $\tau$ no debe ser revelado - es un parámetro secreto de la configuración, y debe ser desechado después de la ceremonia haya sido completada para que nadie pueda averiguar su valor.
+
+Existen métodos establecidos para llevar a cabo trusted setups con suposiciones de confianza débiles (suposición de confianza 1-de-N) utilizando [multi-party computation](https://en.wikipedia.org/wiki/Secure_multi-party_computation) (MPC). Para más información sobre cómo funcionan las trusted setups, véase este [post](https://vitalik.ca/general/2022/03/14/trustedsetup.html) de Vitalik.
+
+## 2. Compromiso con un polinomio
+
+- Dado un polinomio $P(x) = \sum_{i=0}^{l} p_i x^i$
+- Se computa y emite el compromiso $c = [P(\tau)]_1$.
+- Aunque el committer no puede computar $P(\tau)$ directamente (ya que no conoce $\tau$), puede computarlo utilizando la salida de la trusted setup:
+  - $[P(\tau)]_1 = [\sum_{i=0}^{l} p_i \tau^i]_1 = \sum_{i=0}^{l} p_i [\tau^i]_1$.
+
+## 3. Probar una evaluación
+
+- Dada una evaluación $P(a) = b$
+- Se computa y emite la prueba $\pi = [Q(\tau)]_1$
+  - Donde $Q(x) := \frac{P(x)-b}{x-a}$
+    - Obsérvese que tal $Q(x)$ existe si y sólo si $P(a) = b$. Por tanto, la existencia de este polinomio cociente sirve como prueba de la evaluación.
+
+## 4. Verificación de una prueba de evaluación
+
+- Dado un compromiso $c = [P(\tau)]_1$, una evaluación $P(a) = b$, y una prueba $\pi = [Q(\tau)]_1$
+- Se Verifica que $e(\pi, [\tau - a]_2) = e(c - [b]_1, h)$
+  - Algo de álgebra muestra que esto es equivalente a comprobar que el polinomio cociente está correctamente formado en $\tau$: $Q(\tau) = \frac{P(\tau) -b}{\tau-a}$
+    $$
+    \begin{align*}
+    & e(\pi, [\tau - a]_2) = e(c - [b]_1, h) \\ \iff
+    & e([Q(\tau)]_1, [\tau -a]_2) = e([P(\tau)]_1 - [b]_1, h) \\ \iff
+    &  Q(\tau) \cdot (\tau - a) \cdot e(g, h) = (P(\tau)-b) \cdot e(g,h) \\ \iff
+    & Q(\tau) \cdot (\tau -a) = P(\tau) - b
+    \end{align*}
+    $$
+  - El mapeo bilineal $e$ nos permite comprobar esta propiedad sin conocer el parámetro secreto de configuración $\tau$
+- Una vez realizada esta comprobación, podemos concluir que (con una probabilidad abrumadoramente alta) el polinomio cociente está correctamente formado, y por tanto que la evaluación es correcta.
+
+## Aprende Más
+
+- [https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html)
+- [https://alinush.github.io/2020/05/06/kzg-polynomial-commitments.html](https://alinush.github.io/2020/05/06/kzg-polynomial-commitments.html)
+- [https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf](https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf)
diff --git a/src/content/docs/es/learn/zero-knowledge/polynomial-commitment-schemes.md b/src/content/docs/es/learn/zero-knowledge/polynomial-commitment-schemes.md
new file mode 100644
index 000000000..74bc0ff9e
--- /dev/null
+++ b/src/content/docs/es/learn/zero-knowledge/polynomial-commitment-schemes.md
@@ -0,0 +1,35 @@
+---
+section: learn
+date: Last Modified
+title: "Esquemas de Compromiso Polinómicos"
+lang: "es"
+permalink: "learn/zero-knowledge/polynomial-commitment-schemes"
+excerpt: "Los Polynomial commitment schemea son un componente básico de los sistemas de pruebas de zero-knowledge."
+whatsnext: { "Esquema de Compromiso KZG": "/es/learn/zero-knowledge/kzg-commitment-scheme" }
+---
+
+Los Esquemas de Compromiso Polinómicos son un componente básico de los sistemas de pruebas de zero-knowledge (así como de otros protocolos criptográficos).
+
+Como su nombre indica, los esquemas de compromiso polinómicos son esquemas de compromiso en los que el objeto a comprometer es un polinomio. Estos esquemas también tienen una propiedad especial por la que una evaluación del polinomio puede verificarse con acceso únicamente al compromiso del polinomio.
+
+## Esquemas de Compromiso
+
+Un **[esquema de compromiso](https://en.wikipedia.org/wiki/Commitment_scheme)** es una primitiva criptográfica que implica a dos partes: un _committer_ y un _verifier_. El committer se compromete con un valor $v$ computando un compromiso $c$ y revelándolo al verifier. En un momento posterior, el committer puede revelar el valor original, y el verifier puede verificar que el compromiso corresponde a este valor revelado.
+
+Los esquemas de compromiso seguros tienen dos características:
+
+1. **Binding**: una vez publicado el compromiso $c$, el committer no debe ser capaz de encontrar algún otro valor $v'$ distinto de $v$ que también corresponda a $c$. Es decir, el compromiso $c$ vincula al committer a su valor original $v$.
+2. **Hiding**: el verifier no debe poder obtener ninguna información sobre el valor original $v$ a partir del compromiso $c$. Es decir, el compromiso $c$ oculta toda la información sobre el valor original $v$.
+
+## Esquemas de Compromiso Polinómicos
+
+Un **esquema de compromiso polinómicos** es un esquema de compromiso en el que el committer se compromete con un polinomio $P(x)$ calculando un compromiso $c$. Como en los esquemas de compromiso normales, el committer puede revelar más tarde el polinomio original, y el verifier puede comprobar que el compromiso corresponde al polinomio revelado. Sin embargo, los esquemas de compromiso polinómico tienen una propiedad adicional: el committer puede probar evaluaciones particulares del polinomio comprometido sin revelar el propio polinomio. Por ejemplo, el committer puede probar que $P(a) = b$, y el verifier puede verificar dicha prueba utilizando sólo el compromiso $c$.
+
+Los esquemas de compromiso polinómicos son extremadamente útiles para aplicaciones que usan zero-knowledge. Un prover puede utilizar un esquema de este tipo para demostrar que conoce un polinomio que satisface ciertas propiedades (por ejemplo, que pasa por un cierto punto $(a,b)$), sin revelar el polinomio subyacente.
+
+Otra razón por la que los esquemas polinómicos son útiles es que el compromiso $c$ es generalmente mucho más pequeño que el polinomio que representa, y por lo tanto se puede considerar como una **compresión** del polinomio $P(x)$. La magnitud de la compresión depende del esquema concreto. Por ejemplo, en el esquema de compromiso polinómico KZG, un polinomio de grado arbitrariamente grande puede comprimirse hasta un compromiso consistente en un único elemento de grupo.
+
+## Aprende Más
+
+- [https://en.wikipedia.org/wiki/Commitment_scheme](https://en.wikipedia.org/wiki/Commitment_scheme)
+- [https://learn.0xparc.org/materials/halo2/miscellaneous/polynomial-commitment](https://learn.0xparc.org/materials/halo2/miscellaneous/polynomial-commitment)
diff --git a/src/content/docs/es/technology/_images/L1-to-L2.png b/src/content/docs/es/technology/_images/L1-to-L2.png
new file mode 100644
index 000000000..89d140909
Binary files /dev/null and b/src/content/docs/es/technology/_images/L1-to-L2.png differ
diff --git a/src/content/docs/es/technology/_images/L2-to-L1.png b/src/content/docs/es/technology/_images/L2-to-L1.png
new file mode 100644
index 000000000..0e8cbbf87
Binary files /dev/null and b/src/content/docs/es/technology/_images/L2-to-L1.png differ
diff --git a/src/content/docs/es/technology/_images/arch.png b/src/content/docs/es/technology/_images/arch.png
new file mode 100644
index 000000000..7c0b2db02
Binary files /dev/null and b/src/content/docs/es/technology/_images/arch.png differ
diff --git a/src/content/docs/es/technology/_images/batching.png b/src/content/docs/es/technology/_images/batching.png
new file mode 100644
index 000000000..a101859bb
Binary files /dev/null and b/src/content/docs/es/technology/_images/batching.png differ
diff --git a/src/content/docs/es/technology/_images/deposit.png b/src/content/docs/es/technology/_images/deposit.png
new file mode 100644
index 000000000..1ba61ec9c
Binary files /dev/null and b/src/content/docs/es/technology/_images/deposit.png differ
diff --git a/src/content/docs/es/technology/_images/rollup.png b/src/content/docs/es/technology/_images/rollup.png
new file mode 100644
index 000000000..345826c28
Binary files /dev/null and b/src/content/docs/es/technology/_images/rollup.png differ
diff --git a/src/content/docs/es/technology/_images/withdraw-trie.png b/src/content/docs/es/technology/_images/withdraw-trie.png
new file mode 100644
index 000000000..fe602e973
Binary files /dev/null and b/src/content/docs/es/technology/_images/withdraw-trie.png differ
diff --git a/src/content/docs/es/technology/_images/withdraw.png b/src/content/docs/es/technology/_images/withdraw.png
new file mode 100644
index 000000000..faecae833
Binary files /dev/null and b/src/content/docs/es/technology/_images/withdraw.png differ
diff --git a/src/content/docs/es/technology/_images/zkevm1.png b/src/content/docs/es/technology/_images/zkevm1.png
new file mode 100644
index 000000000..39f45db33
Binary files /dev/null and b/src/content/docs/es/technology/_images/zkevm1.png differ
diff --git a/src/content/docs/es/technology/_images/zkevm2.png b/src/content/docs/es/technology/_images/zkevm2.png
new file mode 100644
index 000000000..4e5ff8a2a
Binary files /dev/null and b/src/content/docs/es/technology/_images/zkevm2.png differ
diff --git a/src/content/docs/es/technology/_images/zkevm3.png b/src/content/docs/es/technology/_images/zkevm3.png
new file mode 100644
index 000000000..31e268f23
Binary files /dev/null and b/src/content/docs/es/technology/_images/zkevm3.png differ
diff --git a/src/content/docs/es/technology/_images/zktrie-arch.png b/src/content/docs/es/technology/_images/zktrie-arch.png
new file mode 100644
index 000000000..38f74e6f8
Binary files /dev/null and b/src/content/docs/es/technology/_images/zktrie-arch.png differ
diff --git a/src/content/docs/es/technology/_images/zktrie-deletion.png b/src/content/docs/es/technology/_images/zktrie-deletion.png
new file mode 100644
index 000000000..c47fc7267
Binary files /dev/null and b/src/content/docs/es/technology/_images/zktrie-deletion.png differ
diff --git a/src/content/docs/es/technology/_images/zktrie-insertion.png b/src/content/docs/es/technology/_images/zktrie-insertion.png
new file mode 100644
index 000000000..da0ae521a
Binary files /dev/null and b/src/content/docs/es/technology/_images/zktrie-insertion.png differ
diff --git a/src/content/docs/es/technology/bridge/cross-domain-messaging.mdx b/src/content/docs/es/technology/bridge/cross-domain-messaging.mdx
new file mode 100644
index 000000000..b1a518ec6
--- /dev/null
+++ b/src/content/docs/es/technology/bridge/cross-domain-messaging.mdx
@@ -0,0 +1,232 @@
+---
+section: technology
+date: Last Modified
+title: "Cross-Domain Messaging"
+lang: "es"
+permalink: "technology/bridge/cross-domain-messaging"
+whatsnext: { "Gateways de Depósito": "/es/technology/bridge/deposit-gateways/" }
+---
+
+import ClickToZoom from "../../../../../components/ClickToZoom.astro"
+import ToggleElement from "../../../../../components/ToggleElement.astro"
+
+import L1ToL2 from "../_images/L1-to-L2.png"
+import L2ToL1 from "../_images/L2-to-L1.png"
+import WithdrawTrie from "../_images/withdraw-trie.png"
+
+Scroll tiene un bridge para el paso de mensajes arbitrarios que permite la transferencia de tokens y permite a las dapps comunicarse entre la capa 1 y la capa 2. Esto significa que las dapps de la capa 1 pueden activar funciones de contrato en la capa 2, y viceversa. A continuación, explicaremos cómo se transmiten los mensajes entre la capa 1 y la capa 2.
+
+## Envío de mensajes de L1 a L2
+
+<ClickToZoom src={L1ToL2} alt="L1 to L2 workflow" caption="Figure 1. L1 to L2 message relay workflow" />
+
+Existen dos enfoques principales para enviar un mensaje de L1 a L2: enviar mensajes arbitrarios a través de `L1ScrollMessenger` y enviar transacciones forzadas a través de `EnforcedTxGateway`. Ambos enfoques permiten a los usuarios iniciar una transacción L2 en L1 y llamar a contratos arbitrarios en L2. En el caso de los mensajes arbitrarios, el remitente de las transacciones L2 es la dirección alias "L1ScrollMessenger". Para las transacciones forzadas, el remitente de L2 es una cuenta de titularidad externa (EOA). Además, proporcionamos varias gateways de tokens estándares para facilitar a los usuarios el depósito de ETH y otros tokens estándares, incluidos ERC-20, ERC-677, ERC-721 y ERC-1155. En esencia, estas gateways codifican los depósitos de tokens en un mensaje y lo envían a sus homólogos en L2 a través del contrato `L1ScrollMessenger`. Puede encontrar más detalles sobre las gateways de tokens de L1 en [Gateways de Depósito](/es/technology/bridge/deposit-gateways).
+
+Como se muestra en la Figura 1, tanto los mensajes arbitrarios como las transacciones forzadas se añaden a la cola de mensajes almacenada en el contrato `L1MessageQueue`. El contrato `L1MessageQueue` proporciona dos funciones `appendCrossDomainMessage` y `appendEnforcedTransaction` para añadir mensajes arbitrarios y transacciones forzadas respectivamente.
+
+```solidity
+/// @notice Append an arbitrary L1-to-L2 message into this contract.
+/// @param target The target address on L2.
+/// @param gasLimit The maximum gas can be used for this transaction on L2.
+/// @param data The calldata of the L1-initiated transaction.
+function appendCrossDomainMessage(
+    address target,
+    uint256 gasLimit,
+    bytes calldata data
+) external;
+
+/// @notice Append an enforced transaction to this contract.
+/// @param sender The sender address of this transaction.
+/// @param target The target address of this transaction.
+/// @param value The value to be transferred on L2.
+/// @param gasLimit The maximum gas should be used for this transaction on L2.
+/// @param data The calldata of the L1-initiated transaction.
+function appendEnforcedTransaction(
+    address sender,
+    address target,
+    uint256 value,
+    uint256 gasLimit,
+    bytes calldata data
+) external;
+```
+
+Ambas funciones construyen una transacción iniciada por L1 con un nuevo tipo de transacción `L1MessageTx` introducido en la Scroll chain y calculan el hash de la transacción (ver más detalles en [Transacción de Mensajes en L1](/es/technology/chain/transactions#l1-message-transaction)). A continuación, `L1MessageQueue` añade el hash de la transacción a la cola de mensajes y emite el evento `QueueTransaction(sender, target, value, queueIndex, gasLimit, calldata)`. La diferencia entre `appendCrossDomainMessage` y `appendEnforcedTransaction` a la hora de construir transacciones de mensajes L1 es:
+
+- `appendCrossDomainMessage` sólo puede ser llamado por `L1ScrollMessenger` y utiliza la [Address Alias](#address-alias) de `msg.sender`, que será la dirección de `L1ScrollMessenger`, como remitente de la transacción.
+- La función `appendEnforcedTransaction` sólo puede ser llamada por `EnforcedTxGateway` y utiliza `sender` del parámetro de función como remitente de la transacción. Esto permite a los usuarios ejecutar una retirada o transferencia de ETH desde sus cuentas L2 directamente a través del bridge L1.
+
+Después de que la transacción se ejecuta con éxito en L1, el watcher en el secuenciador Scroll que monitoriza el contrato `L1MessageQueue` recoge los nuevos eventos `QueueTransaction` de los bloques en L1. El secuenciador construye entonces una nueva transacción `L1MessageTx` por evento y las añade a su cola local de transacciones en L1. Cuando construye un nuevo bloque en L2, el secuenciador incluye las transacciones tanto de su cola de transacciones en L1 como de su mempool en L2. Ten en cuenta que las transacciones de mensajes en L1 deben incluirse secuencialmente basándose en el orden de la cola de mensajes en L1 en el contrato `L1MessageQueue`. Las transacciones `L1MessageTx` siempre van primero en los bloques en L2 seguidas de las transacciones en L2. Actualmente, limitamos el número de transacciones `L1MessageTx` en un bloque en L2 a `NumL1MessagesPerBlock` (fijado actualmente en 10).
+
+A continuación, nos extenderemos más en el proceso específico de envío de mensajes arbitrarios a través de `L1ScrollMessenger` y el envío de transacciones forzadas a través de `EnforcedTxGateway`.
+
+### Envío de Mensajes Arbitrarios
+
+El contrato `L1ScrollMessenger` proporciona dos funciones `sendMessage` para enviar mensajes arbitrarios. La única diferencia es que la segunda permite a los usuarios especificar una dirección de reembolso distinta de la del remitente para recibir el reembolso de la comisión.
+
+<ToggleElement anchor="sendMessage signatura de funciones">
+<div slot="title"><code>sendMessage</code> signatura de funciones</div>
+```solidity
+/// @param target The target address on L2.
+/// @param value The value to deposit to L2 from `msg.value`.
+/// @param message The message passed to target contract.
+/// @param gasLimit The maximum gas can be used for this transaction on L2.
+function sendMessage(
+    address target,
+    uint256 value,
+    bytes memory message,
+    uint256 gasLimit
+) external payable;
+
+/// @param target The target address on L2.
+/// @param value The value to deposit to L2 from `msg.value`.
+/// @param message The message passed to target contract.
+/// @param gasLimit The maximum gas can be used for this transaction on L2.
+/// @param refundAddress The address to refund excessive fee on L1.
+function sendMessage(
+    address target,
+    uint256 value,
+    bytes calldata message,
+    uint256 gasLimit,
+    address refundAddress
+) external payable;
+````
+</ToggleElement>
+
+
+Ambas funciones requieren que los usuarios proporcionen un límite de gas para la transacción `L1MessageTx` correspondiente en L2 y paguen por adelantado el [Message Relay Fee](#message-relay-fee) en L1, que se calcula en función del importe del límite de gas. La comisión se recoge en un contrato `feeVault` en L1. En caso de que la transacción falle en L2 porque el usuario no ha establecido el límite de gas correcto para su mensaje en L1, el usuario puede repetir el mismo mensaje con un límite de gas más alto. Puedes encontrar más detalles en la sección [Reintento de Mensajes Fallidos](#reintentar-mensajes-fallidos).
+
+Las funciones `sendMessage` codifican los argumentos en un mensaje entre dominios (véase el fragmento de código siguiente), donde el nonce del mensaje es el siguiente índice de la cola de mensajes en L1. Los datos codificados se utilizan como calldata en la transacción `L1MessageTx` ejecutada en L2. Ten en cuenta que estos mensajes entre dominios siempre llaman a la función `relayMessage` del contrato `L2ScrollMessenger` en L2.
+
+```solidity
+abi.encodeWithSignature(
+    "relayMessage(address,address,uint256,uint256,bytes)",
+    _sender,
+    _target,
+    _value,
+    _messageNonce,
+    _message
+)
+````
+
+La cantidad de ETH depositada como `value` se bloquea en el contrato `L1ScrollMessenger`. Si la cantidad de ETH en el mensaje no puede cubrir la Message Relay Fee y la cantidad depositada, la transacción se revertirá. El contrato `L1ScrollMessenger` reembolsará la cantidad sobrante a la `refundAddress` designada o al remitente de la transacción en caso contrario. Por último, `L1ScrollMessenger` añade el mensaje entre dominios a `L1MessageQueue` mediante el método `appendCrossDomainMessage`.
+
+### Envío de Transacciones Forzadas
+
+El contrato `EnforcedTxGateway` proporciona dos funciones `sendTransaction` para enviar una transacción forzada. En la primera función, el remitente de la transacción generada `L1MessageTx` es el remitente de la transacción. Por otro lado, la segunda función utiliza la dirección del `sender` como remitente de la transacción `L1MessageTx`. Esto permite a un tercero enviar una transacción forzada en nombre del usuario y pagar la comisión de retransmisión. Ten en cuenta que la segunda función requiere proporcionar una firma válida de la transacción `L1MessageTx` generada que coincida con la dirección del `sender`. Ambas funciones `sendTransaction` exigen que el remitente sea una cuenta EOA.
+
+<ToggleElement anchor="sendTransaction signatura de funciones">
+<div slot="title"><code>sendTransaction</code> signatura de funciones</div>
+
+```solidity
+/// @param target The target address on L2.
+/// @param value The value to withdraw from the `tx.origin` address on L2.
+/// @param gasLimit The maximum gas can be used for this transaction on L2.
+/// @param data The calldata passed to target contract.
+function sendTransaction(
+    address target,
+    uint256 value,
+    uint256 gasLimit,
+    bytes calldata data
+) external payable;
+
+/// @param sender The sender address who will initiate this transaction on L2.
+/// @param target The target address on L2.
+/// @param value The value to withdraw from the `sender` address on L2.
+/// @param gasLimit The maximum gas can be used for this transaction on L2.
+/// @param data The calldata passed to target contract.
+/// @param signature The signature for the corresponding `L1MessageTx` transaction.
+/// @param refundAddress The address to refund excessive fee on L1.
+function sendTransaction(
+    address sender,
+    address target,
+    uint256 value,
+    uint256 gasLimit,
+    bytes calldata data,
+    bytes memory signature,
+    address refundAddress
+) external payable;
+```
+
+</ToggleElement>
+
+De forma similar a la retransmisión arbitraria de mensajes, `sendTransaction` deduce la comisión de retransmisión de mensajes y la transfiere a la cuenta `feeVault` de L1. Pero una diferencia clave es que el `value` que se pasa a la función indica la cantidad de ETH que debe transferirse desde la cuenta del remitente en L2, no en L1. Por lo tanto, el `msg.value` sólo necesita cubrir el [Message Relay Fee](#message-relay-fee). Si la cantidad de ETH en el mensaje no puede cubrir la comisión, la transacción fallará. Cualquier exceso de comisión se reembolsa al remitente de la transacción en la primera función y a la `refundAddress` en la segunda función. Por último, `EnforcedTxGateway` llama a `L1MessageQueue.appendEnforcedTransaction` para añadir la transacción a la cola de mensajes.
+
+### Reintento de Mensajes Fallidos
+
+Si una transacción de `L1MessageTx` falla en L2 debido a gas insuficiente, los usuarios pueden reproducir el mensaje con un límite de gas más alto. Para ello, `L1ScrollMessenger` proporciona el método `replayMessage`, que permite a los usuarios enviar la misma información que el mensaje anterior fallido con un límite de gas superior. Este mensaje se convertirá en una nueva transacción `L1MessageTx` en L2. Ten en cuenta que no se reembolsará la tarifa de gas de la transacción fallida anterior, ya que ésta ya se ha procesado en L2.
+
+<ToggleElement anchor="replayMessage signatura de función">
+<div slot="title"><code>replayMessage</code> signatura de función</div>
+
+```solidity
+/// @param from The address of the sender of the message.
+/// @param to The address of the recipient of the message.
+/// @param value The msg.value passed to the message call.
+/// @param queueIndex The queue index for the message to replay.
+/// @param message The content of the message.
+/// @param newGasLimit New gas limit to be used for this message.
+/// @param refundAddress The address of account who will receive the refunded fee.
+function replayMessage(
+    address from,
+    address to,
+    uint256 value,
+    uint256 queueIndex,
+    bytes memory message,
+    uint32 newGasLimit,
+    address refundAddress
+) external payable;
+```
+
+</ToggleElement>
+
+Dado que el contrato `L2ScrollMessenger` registra todos los mensajes de L1 que se retransmitieron con éxito a L2, la transacción del mensaje reproducido se revertirá en L2 si el mensaje original tiene éxito.
+
+### Message Relay Fee
+
+El contrato `L2GasPriceOracle` desplegado en L1 calcula la comisión de retransmisión de un mensaje dado su límite de gas. Este contrato almacena el valor `l2BaseFee` en su memoria, que se actualiza mediante un relayer dedicado ejecutado actualmente por Scroll. La comisión de retransmisión de los mensajes de L1 a L2 es `gasLimit * l2BaseFee`.
+
+### Address Alias
+
+Debido al comportamiento del opcode `CREATE`, es posible que alguien despliegue un contrato en la misma dirección en L1 y L2 pero con diferente bytecode. Para evitar que usuarios malintencionados se aprovechen de esto, el bridge aplica un Address Alias cuando el remitente del mensaje es un contrato en L1. La dirección del remitente alias de la transacción del mensaje L1 es `l1_dirección_del_contrato + offset` donde el `offset` es `0x11110000000000000000000000000000000000001111`.
+
+## Sending Messages from L2 to L1
+
+<ClickToZoom src={L2ToL1} alt="L2 to L1 workflow" caption="Figure 2. L2 to L1 message relay workflow" />
+
+En L2, los usuarios pueden enviar mensajes arbitrarios a través de `L2ScrollMessenger` para retirar tokens y llamar a contratos L1. Al igual que en L1, hemos creado varias gateways de tokens estándares para facilitar la inicialización de los retiros de tokens. Para más detalles sobre las gateways de tokens de L2, consulta [Gateways de Retiro](/es/technology/bridge/withdraw-gateways).
+
+El contrato `L2ScrollMessenger` también proporciona una función `sendMessage`. La diferencia con respecto a `L1ScrollMessenger.sendMessage` es que el parámetro `gasLimit` se ignora en la función porque la transacción de ejecución de retiro en L1 es enviada por los usuarios y la comisión de transacción se paga en L1 directamente. Así, la función `sendMessage` requiere que `msg.value` sea igual al parámetro `value`. La función codifica los argumentos en un mensaje entre dominios siguiendo el mismo esquema que en [`L1ScrollMessenger`](#sending-arbitrary-messages).
+
+<ToggleElement anchor="sendMessage signatura de función">
+<div slot="title"><code>sendMessage</code> signatura de función</div>
+
+```solidity
+/// @param target The target address on L1.
+/// @param value The value to withdraw to L1 from `msg.value`.
+/// @param message The message passed to target contract.
+/// @param _gasLimit Ignored in the L2ScrollMessenger because the withdrawal execution on L1 is done by the user.
+function sendMessage(
+    address target,
+    uint256 value,
+    bytes memory message,
+    uint256 _gasLimit
+) external payable;
+```
+
+</ToggleElement>
+
+A continuación, el hash de mensajes entre dominios se añade a `L2MessageQueue` llamando a su función `appendMessage`. El contrato `L2MessageQueue` mantiene el [Withdraw Trie](#withdraw-trie), un Merkle tree sólo para añadir mensajes. Cada vez que se añade un nuevo mensaje a la cola, el contrato lo inserta en el Withdraw Trie y actualiza el hash root del trie.
+
+Una vez finalizado el lote de transacciones que contiene los mensajes L2 a L1 de los usuarios en el contrato L1 rollup, los usuarios deben enviar las transacciones _Execute Withdrawal_ correspondientes para llamar al método `relayMessageWithProof` del contrato `L1ScrollMessenger` que ejecuta la retirada en L1. Gracias a las Merkle proofs, la finalización de las transacciones de retirada en L1 no genera confianza y puede ser enviada por el propio usuario o por un tercero en nombre de los usuarios.
+
+Para facilitar la construcción de un MIP de retiro, Scroll mantiene un servicio llamado Bridge History API. Bridge History API supervisa los eventos `SentMessage` emitidos por `L2ScrollMessenger` y mantiene internamente un Withdraw Trie. Genera continuamente Merkle proofs para cada mensaje de retirada. Los usuarios y los servicios de terceros pueden consultar las Merkle proofs desde la Bridge History API para incluirlas en las transacciones _Execute Withdrawal_.
+
+Ten en cuenta que las transacciones de ejecución de retirada pueden ser enviadas por los propios usuarios o por un servicio de terceros.
+
+### Withdraw Trie
+
+<ClickToZoom src={WithdrawTrie} alt="Withdraw Trie structure" caption="Figure 3. Withdraw Trie structure" />
+
+El Withdraw Trie es un "Merkle tree" binario denso. El hash de un nodo hoja se hereda del hash del mensaje, mientras que el hash de un nodo no-hoja es el Keccak hash digest de los hashes concatenados de sus dos descendientes. La profundidad del Withdraw Trie crece dinámicamente en función del número de mensajes añadidos al trie.
+
+La figura 3(a) muestra un ejemplo de un withdraw trie completo de 3 capas. Cuando el número de hojas no puede saturar un tree binario completo, rellenamos los nodos de las hojas con hash 0, como se muestra en las figuras 3(b) y 3(c). Cuando se añade un nuevo mensaje a un Withdraw Trie no completo, el nodo de relleno se sustituye por un nuevo nodo hoja con el hash del mensaje real.
diff --git a/src/content/docs/es/technology/bridge/deposit-gateways.mdx b/src/content/docs/es/technology/bridge/deposit-gateways.mdx
new file mode 100644
index 000000000..f59ac4066
--- /dev/null
+++ b/src/content/docs/es/technology/bridge/deposit-gateways.mdx
@@ -0,0 +1,183 @@
+---
+section: technology
+date: Last Modified
+title: "Gateways de Depósito"
+lang: "es"
+permalink: "technology/bridge/deposit-gateways"
+whatsnext: { "Gateways de Retiro": "/es/technology/bridge/withdraw-gateways/" }
+---
+
+import ClickToZoom from "../../../../../components/ClickToZoom.astro"
+import DepositWorkflow from "../_images/deposit.png"
+
+Este documento describe cómo los usuarios y desarrolladores pueden utilizar las gateways para depositar tokens de L1 a L2. Proporcionamos varias gateways para tokens estándares y un router gateway en L1, listados en la siguiente tabla.
+
+| Gateway Contract         | Descripción                                                      |
+| ------------------------ | ---------------------------------------------------------------- |
+| `L1GatewayRouter`        | La gateway router que admite el depósito de tokens ETH y ERC20. |
+| `L1ETHGateway`           | La gateway para depositar ETH.                                      |
+| `L1StandardERC20Gateway` | La gateway para depósitos de tokens ERC20 estándar.                   |
+| `L1CustomERC20Gateway`   | La gateway para depósitos de tokens ERC20 personalizados.                     |
+| `L1WETHGateway`          | La gateway para depósitos ETH envueltos.                            |
+| `L1ERC721Gateway`        | La gateway para depósitos de tokens ERC-721.                          |
+| `L1ERC1155Gateway`       | La gateway para depósitos de tokens ERC-1155.                         |
+
+## Vista Ampliada
+
+<ClickToZoom src={DepositWorkflow} alt="Deposit Workflow" />
+
+La figura muestra el flujo de trabajo de depósito de L1 a L2. Los usuarios llaman a las gateways para iniciar el depósito de tokens. A continuación, el depósito se codifica en un mensaje que se envía al contrato `L1ScrollMessenger` y se añade la correspondiente transacción iniciada en L1 a la `L1MessageQueue`. Para finalizar los depósitos en L2, el secuenciador de L2 recoge los nuevos eventos de transacción de L1 e incluye las transacciones correspondientes en los bloques de L2 que crea. Las secciones siguientes describen los detalles de cómo se depositan los distintos tokens. Puede encontrar más detalles sobre el flujo de trabajo de retransmisión de mensajes de L1 a L2 en [Cross-Domain Messaging](/es/technology/bridge/cross-domain-messaging#sending-messages-from-l1-to-l2).
+
+## Depósito de ETH
+
+Scroll utiliza ETH como su token nativo. Preasignamos una cantidad suficiente de ETH al contrato `L2ScrollMessenger` en el bloque génesis para que pueda transferir tokens ETH nativos a cuentas L2 sin necesidad de emitir. El depósito de ETH funciona de la siguiente manera.
+
+1. `L1GatewayRouter` ofrece tres funciones para depositar ETH de L1 a L2. La función `depositETHAndCall` puede transferir ETH y ejecutar una llamada de contrato al mismo tiempo.
+
+    ```solidity
+    function depositETH(uint256 _amount, uint256 _gasLimit) external payable;
+
+    function depositETH(address _to, uint256 _amount, uint256 _gasLimit) public payable;
+
+    function depositETHAndCall(
+        address _to,
+        uint256 _amount,
+        bytes calldata _data,
+        uint256 _gasLimit
+    ) external payable;
+    ```
+
+2. Las tres funciones `depositETH` llaman a `L1ETHGateway`. `L1ETHGateway` codifica el depósito en un mensaje que se envía al contrato `L1ScrollMessenger`.
+
+3. El ETH del importe del depósito se bloquea en el contrato `L1ScrollMessenger`. L1ScrollMessenger añade el mensaje a la cola de mensajes del contrato L1MessageQueue.
+
+4. Una vez finalizada la transacción de depósito en el L1, el secuenciador incluirá una transacción L2 correspondiente en el bloque L2 para finalizar el depósito y transferir ETH a la dirección del destinatario en el L2.
+
+5. La transacción L2 llama a la función `L2ScrollMessenger.relayMessage`, que ejecuta el mensaje retransmitido.
+   En el caso del depósito de ETH, la función `relayMessage` llama a `L2ETHGateway.finalizeDepositETH` para transferir ETH a la cuenta del destinatario en L2.
+
+6. Si el usuario llama a `depositETHAndCall` en L1, `finalizeDepositETH` en el contrato `L2ETHGateway` reenviará los datos adicionales al contrato L2 de destino.
+
+## Depósito de Tokens ERC20 
+
+Se proporcionan varios contratos de gateway ERC20 para conectar diferentes tipos de tokens ERC20, como tokens ERC20 estándar, tokens ERC20 personalizados y Wrapped ETH. El `L1GatewayRouter` registra la asignación canónica de tokens ERC20 a la correspondiente gateway ERC20 en la L1. El `L1GatewayRouter` utiliza `StandardERC20Gateway` como gateway ERC20 por defecto para los nuevos tokens ERC20 a menos que ya se haya configurado una gateway personalizada.
+
+El depósito de tokens ERC20 funciona de la siguiente manera.
+
+1. Para depositar tokens ERC20 de L1 a L2, los usuarios pueden utilizar `L1GatewayRouter.depositERC20` y `L1GatewayRouter.depositERC20AndCall` que se muestran a continuación.
+
+    ```solidity
+    function depositERC20(address _token, uint256 _amount, uint256 _gasLimit) external payable;
+
+    function depositERC20(address _token, address _to, uint256 _amount, uint256 _gasLimit) external payable;
+
+    function depositERC20AndCall(
+        address _token,
+        address _to,
+        uint256 _amount,
+        bytes memory _data,
+        uint256 _gasLimit
+    ) public payable;
+    ```
+
+2. En función del mapping entre los tokens ERC20 y la gateway, el `L1GatewayRouter` llama a la gateway correspondiente: `L1StandardERC20Gateway`, `L1CustomERC20Gateway`, o `L1WETHGateway`. El resto de pasos se describirán por separado.
+
+### ERC20 Tokens Estándares
+
+Los tokens ERC20 estándar son tokens que no requieren ninguna lógica personalizada. Para estos tokens, sus contratos de tokens L2 ERC20 se crean mediante `L2StandardERC20Gateway`. Los pasos restantes para el depósito de tokens ERC20 estándar son:
+
+3. El contrato `L1StandardERC20Gateway` bloquea los tokens ERC20 transfiriéndolos del emisor a sí mismo.
+4. Si este token ERC20 no se ha retirado antes a través de `L1StandardERC20Gateway`, `L1StandardERC20Gateway` calculará una dirección determinista de token ERC20 en L2 y añadirá los metadatos del token (símbolo, nombre y decimales) al mensaje para el posible despliegue del contrato en L2. Si la dirección del token en L2 ya está almacenada en el `tokenMapping`, `L1StandardERC20Gateway` cargará directamente la dirección del token en L2 desde el mapeo.
+5. `L1StandardERC20Gateway` codifica el mensaje de depósito de tokens y llama a `L1ScrollMessenger` para enviar el mensaje.
+6. La transacción en L2 correspondiente llama a la función `L2ScrollMessenger.relayMessage` para finalizar el depósito en L2. En el caso de depósitos de tokens ERC20 estándar, la transacción llama entonces a `L2StandardERC20Gateway.finalizeDepositERC20`.
+7. Si este contrato de token ERC20 no se ha desplegado en L2, `L2StandardERC20Gateway` extraerá los metadatos del token del mensaje y llama a `ScrollStandardERC20Factory` para desplegar el token ERC20 estándar en L2.
+8. `L2StandardERC20Gateway` llama a la función mint en el contrato de token ERC20 en L2 correspondiente.
+9. Si el usuario llama a `depositERC20AndCall` en L1, `L2StandardERC20Gateway` llamará al contrato en L2 de destino con datos adicionales.
+
+### ERC20 Tokens Personalizados
+
+En comparación con los tokens ERC20 estándares, el contrato L2 de los tokens ERC20 personalizados es desplegado por el propietario del token. Los pasos restantes para el depósito de tokens ERC20 personalizados son:
+
+3. El contrato `L1CustomERC20Gateway` bloquea los tokens ERC20 en L1 transfiriéndolos del emisor a sí mismo.
+4. El contrato `L1CustomERC20Gateway` requiere una dirección de token ERC20 en L2 presente en el `tokenMapping`. Recupera la dirección de token ERC20 correspondiente, codifica el mensaje de depósito de token y lo reenvía a `L1ScrollMessenger`.
+5. La transacción en L2 correspondiente llama a la función `L2ScrollMessenger.relayMessage` para finalizar el depósito en L2. En el caso de depósitos de tokens ERC20 personalizados, la transacción llama a `L2CustomERC20Gateway.finalizeDepositERC20`.
+6. `L2CustomERC20Gateway` llama a la función "mint" en el correspondiente contrato de tokens ERC20 de L2. Es necesario que el contrato de tokens ERC20 en L2 conceda permisos de emisión al contrato `L2CustomERC20Gateway`.
+7. Si el usuario llama a `depositERC20AndCall` en L1, la `L2CustomERC20Gateway` llamará al contrato en L2 de destino con datos adicionales.
+
+### WETH Token
+
+Proporcionamos una gateway personalizada `L1WETHGateway` para Wrapped ETH token en L1 y registramos la dirección de la gateway en el `L1GatewayRouter`. El depósito del token WETH funciona de la siguiente manera.
+
+3. `L1WETHGateway` bloquea los tokens WETH transfiriéndolos del remitente a sí mismo y desenvolviendo el token WETH a token ETH nativo. A continuación, el token ETH y `msg.value` (para pagar la comisión de retransmisión) se envían juntos al contrato `L1ScrollMessenger`.
+4. `L1WETHGateway` codifica el mensaje de depósito del token y lo reenvía a `L1ScrollMessenger`.
+5. La transacción en L2 correspondiente llama a la función `L2ScrollMessenger.relayMessage` para finalizar el depósito en L2. En el caso del depósito de tokens WETH, la transacción llama a `L2WETHGateway.finalizeDepositERC20`.
+6. `L2WETHGateway` envuelve de nuevo el token ETH depositado en L2 WETH y lo transfiere a la dirección del destinatario en L2.
+7. Si el usuario llama a `depositERC20AndCall` en L1, `L2WETHGateway` llamará al contrato de destino en L2 con datos adicionales.
+
+## Depósito de tokens ERC-721/ERC-1155
+
+El depósito de tokens ERC-721 o ERC-1155 funciona de forma muy similar a los tokens ERC20. Se pueden utilizar las gateways `L1ERC721Gateway` o `L1ERC1155Gateway` para depositar tokens ERC-721 /ERC-1155 desde L1.
+
+```solidity
+function depositERC721(
+    address _token,
+    uint256 _tokenId,
+    uint256 _gasLimit
+) external payable;
+
+function depositERC721(
+    address _token,
+    address _to,
+    uint256 _tokenId,
+    uint256 _gasLimit
+) external payable;
+
+function depositERC1155(
+    address _token,
+    uint256 _tokenId,
+    uint256 _amount,
+    uint256 _gasLimit
+) external payable;
+
+function depositERC1155(
+    address _token,
+    address _to,
+    uint256 _tokenId,
+    uint256 _amount,
+    uint256 _gasLimit
+) external payable;
+```
+
+Para facilitar una gran cantidad de depósitos de tokens ERC-721 o ERC-1155, también proporcionamos funciones de depósito por lotes en el contrato `L1ERC721Gateway` y `L1ERC1155Gateway` a través de las siguientes funciones:
+
+```solidity
+function batchDepositERC721(
+    address _token,
+    uint256[] calldata _tokenIds,
+    uint256 _gasLimit
+) external payable;
+
+function batchDepositERC721(
+    address _token,
+    address _to,
+    uint256[] calldata _tokenIds,
+    uint256 _gasLimit
+) external payable;
+
+function batchDepositERC1155(
+    address _token,
+    uint256[] calldata _tokenIds,
+    uint256[] calldata _amounts,
+    uint256 _gasLimit
+) external payable;
+
+function batchDepositERC1155(
+    address _token,
+    address _to,
+    uint256[] calldata _tokenIds,
+    uint256[] calldata _amounts,
+    uint256 _gasLimit
+) external payable;
+```
+
+Los contratos de contrapartida de L2 para los tokens ERC-721 o ERC-1155 son `L2ERC721Gateway` y `L2ERC1155Gateway`. Se utilizan para finalizar depósitos en L2.
diff --git a/src/content/docs/es/technology/bridge/withdraw-gateways.mdx b/src/content/docs/es/technology/bridge/withdraw-gateways.mdx
new file mode 100644
index 000000000..f1476640b
--- /dev/null
+++ b/src/content/docs/es/technology/bridge/withdraw-gateways.mdx
@@ -0,0 +1,165 @@
+---
+section: technology
+date: Last Modified
+title: "Gateways de Retiro"
+lang: "es"
+permalink: "technology/bridge/withdraw-gateways"
+whatsnext: { "Secuenciador": "/es/technology/sequencer/execution-node/" }
+---
+
+import ClickToZoom from "../../../../../components/ClickToZoom.astro"
+import WithdrawWorkflow from "../_images/withdraw.png"
+
+Este documento describe cómo los usuarios y desarrolladores pueden utilizar las gateways para retirar tokens de L2 a L1. Proporcionamos varias gateways para tokens estándares y un gateway router en L2, listados en la siguiente tabla.
+
+| Gateway Contract         | Descripción                                                         |
+| ------------------------ | ------------------------------------------------------------------- |
+| `L2GatewayRouter`        | La gateway router que admite el retiro de tokens ETH y ERC20. |
+| `L2ETHGateway`           | La gateway para los retiros de ETH.                                    |
+| `L2StandardERC20Gateway` | La gateway para los retiros de tokens ERC20 estándares.                   |
+| `L2CustomERC20Gateway`   | La gateway para los retiros de tokens ERC20 personalizados.                     |
+| `L2WETHGateway`          | La gateway para los retiros de Wrapped ETH.                            |
+| `L2ERC721Gateway`        | La gateway para los retiros de tokens ERC-721.                          |
+| `L2ERC1155Gateway`       | La gateway para los retiros de tokens ERC-1155.                         |
+
+## Vista General
+
+<ClickToZoom src={WithdrawWorkflow} alt="Withdraw Workflow" />
+
+La figura muestra el flujo de trabajo de retiro de L2 a L1. Los usuarios llaman a las gateways para iniciar el retiro de tokens. El retiro se codifica en un mensaje que se envía a `L2ScrollMessenger`, que luego se añade a `L2MessageQueue`. `L2MessageQueue` mantiene un Withdraw Trie y actualiza la "root" cada vez que se añade un nuevo mensaje. La root del Withdraw Trie se finaliza en el contrato de rollup L1 junto con la state root L2. Una vez finalizada la nueva root del Withdraw Trie en la L1, los usuarios o terceros pueden construir una Merkle Inclusion Proof válida para la root del Withdraw Trie y enviar una transacción _withdraw execution_ para finalizar el retiro en la L1. Encontrará más información sobre el flujo de trabajo de retransmisión de mensajes de L2 a L1 en [Cross-Domain Messaging](/es/technology/bridge/cross-domain-messaging#sending-messages-from-l2-to-l1).
+
+Las secciones siguientes describen los detalles de cómo se retiran las diferentes tokens.
+
+## Retiro de ETH
+
+El retiro del token ETH funciona de la siguiente manera.
+
+1. `L2GatewayRouter` ofrece tres funciones para retirar ETH de L2 a L1. La función `withdrawETHAndCall` puede retirar ETH y ejecutar una llamada de contrato al mismo tiempo.
+
+    ```solidity
+    function withdrawETH(uint256 _amount, uint256 _gasLimit) external payable;
+
+    function withdrawETH(address _to, uint256 _amount, uint256 _gasLimit) public payable;
+
+    function withdrawETHAndCall(
+        address _to,
+        uint256 _amount,
+        bytes calldata _data,
+        uint256 _gasLimit
+    ) external payable;
+    ```
+
+2. Las funciones `withdrawETHAndCall` llaman a `L2ETHGateway`. `L2ETHGateway` codifica el mensaje de retirada y lo envía al contrato `L2ScrollMessenger` junto con la ETH retirada.
+3. La ETH retirada se bloquea de nuevo en el contrato `L2ScrollMessenger`. L2ScrollMessenger añade el mensaje a la cola de mensajes del contrato L2MessageQueue.
+4. La transacción de ejecución de la retirada en L1 llama a la función `L1ScrollMessenger.relayMessageWithProof` para finalizar la retirada. En el caso de la retirada de ETH, la función `relayMessageWithProof` llama a `L1ETHGateway.finalizeWithdrawETH` para devolver ETH a la cuenta del destinatario en L1.
+5. Si el usuario llama a `withdrawETHAndCall` en L2, la función `finalizeWithdrawETH` del contrato `L1ETHGateway` reenviará los datos adicionales al contrato L1 de destino.
+
+## Retiro de tokens ERC20
+
+El retiro de tokens ERC20 funciona de la siguiente manera.
+
+1. Para retirar tokens ERC20 de L1 a L2, los usuarios pueden utilizar `L2GatewayRouter.withdrawERC20` y `L2GatewayRouter.withdrawERC20AndCall` como se muestra a continuación.
+
+    ```solidity
+    function withdrawERC20(address _token, uint256 _amount, uint256 _gasLimit) external payable;
+
+    function withdrawERC20(address _token, address _to, uint256 _amount, uint256 _gasLimit) external payable;
+
+    function withdrawERC20AndCall(
+        address _token,
+        address _to,
+        uint256 _amount,
+        bytes memory _data,
+        uint256 _gasLimit
+    ) public payable;
+    ```
+
+2. En función del mapping de los tokens ERC20 a la gateway, el `L2GatewayRouter` llama a la gateway correspondiente, `L2StandardERC20Gateway`, `L2CustomERC20Gateway`, o `L2WETHGateway`. El resto de pasos se describirán por separado.
+
+### Tokens ERC20 estándares y personalizados
+
+El retiro de tokens ERC20 estándar y personalizados funciona de la siguiente manera.
+
+3. El contrato `L2StandardERC20Gateway` o `L2CustomERC20Gateway` quema el token ERC20 retirado, codifica la retirada en un mensaje y lo envía a `L2ScrollMessenger`.
+4. La transacción de ejecución de retiro de L1 llama a la función `L1ScrollMessenger.relayMessageWithProof` para finalizar los retiros en L1. En caso de un retiro de tokens ERC20 estándar o personalizados, la transacción llama a la función `finalizeWithdrawERC20` en el contrato `L1StandardERC20Gateway` o `L1CustomERC20Gateway` respectivamente.
+   - En el contrato `L1StandardERC20Gateway`, si se trata de la primera transacción de retirada de un token ERC20, la función `finalizeWithdrawERC20` actualizará la asignación de la dirección del token L1 a su dirección del token L2 en el `tokenMapping`.
+5. La gateway de tokens ERC20 en L1 libera los tokens ERC20 bloqueados transfiriéndolos desde sí misma a la dirección del destinatario en L1.
+6. Si el usuario llama a `withdrawERC20AndCall` en L2, las gateways llamarán al contrato L1 de destino con datos adicionales.
+
+### WETH Token
+
+Proporcionamos una gateway personalizada `L2WETHGateway` para Wrapped ETH token en L2 y registramos la dirección de la gateway en el `L2GatewayRouter`. El retiro del token WETH funciona de la siguiente manera.
+
+1. `L2WETHGateway` transfiere el token WETH retirado a sí mismo y "desenvuelve" el token WETH a token ETH nativo. A continuación, el token ETH se devuelve al contrato `L2ScrollMessenger`.
+2. `L2WETHGateway` codifica el mensaje de retiro del token y lo reenvía a `L2ScrollMessenger`.
+3. La transacción de ejecución del retiro en L1 llama a la función `L1ScrollMessenger.relayMessageWithProof` para finalizarlo en L1. En el caso del retiro de tokens WETH, la transacción llama a `L1WETHGateway.finalizeWithdrawERC20` y envía el importe retirado en ETH a `L1WETHGateway`.
+4. `L1WETHGateway` vuelve a convertir el ETH retirado en un token WETH en L1 y lo transfiere a la dirección del destinatario en L1.
+5. Si el usuario llama a `withdrawERC20AndCall` en L2, `L1WETHGateway` llamará a la dirección en L1 de destino con datos adicionales.
+
+## Retiro de tokens ERC-721/ERC-1155
+
+El retiro de tokens ERC-721 o ERC-1155 funciona de forma muy similar a los tokens ERC20. Se puede utilizar la gateway `L2ERC721Gateway` o `L2ERC1155Gateway` para retirar tokens ERC-721 /ERC-1155 de L2.
+
+```solidity
+function withdrawERC721(
+    address _token,
+    uint256 _tokenId,
+    uint256 _gasLimit
+) external payable;
+
+function withdrawERC721(
+    address _token,
+    address _to,
+    uint256 _tokenId,
+    uint256 _gasLimit
+) external payable;
+
+function withdrawERC1155(
+    address _token,
+    uint256 _tokenId,
+    uint256 _amount,
+    uint256 _gasLimit
+) external payable;
+
+function withdrawERC1155(
+    address _token,
+    address _to,
+    uint256 _tokenId,
+    uint256 _amount,
+    uint256 _gasLimit
+) external payable;
+```
+
+Para facilitar el retiro de una gran cantidad de tokens ERC-721 o ERC-1155, también proporcionamos funciones de retiro por lotes en el contrato `L2ERC721Gateway` y `L2ERC1155Gateway` a través de las siguientes funciones:
+
+```solidity
+function batchWithdrawERC721(
+    address _token,
+    uint256[] calldata _tokenIds,
+    uint256 _gasLimit
+) external payable;
+
+function batchWithdrawERC721(
+    address _token,
+    address _to,
+    uint256[] calldata _tokenIds,
+    uint256 _gasLimit
+) external payable;
+
+function batchWithdrawERC1155(
+    address _token,
+    uint256[] calldata _tokenIds,
+    uint256[] calldata _amounts,
+    uint256 _gasLimit
+) external payable;
+
+function batchWithdrawERC1155(
+    address _token,
+    address _to,
+    uint256[] calldata _tokenIds,
+    uint256[] calldata _amounts,
+    uint256 _gasLimit
+) external payable;
+```
+
+Los contratos de contraparte en L1 para tokens ERC-721 o ERC-1155 son `L1ERC721Gateway` y `L1ERC1155Gateway` para finalizar los retiros en L1.
\ No newline at end of file
diff --git a/src/content/docs/es/technology/chain/accounts.mdx b/src/content/docs/es/technology/chain/accounts.mdx
new file mode 100644
index 000000000..def6b59b0
--- /dev/null
+++ b/src/content/docs/es/technology/chain/accounts.mdx
@@ -0,0 +1,29 @@
+---
+section: technology
+date: Last Modified
+title: "Cuentas y Estados"
+lang: "es"
+permalink: "technology/chain/accounts-and-state"
+whatsnext: { "Transacciones": "/es/technology/chain/transactions/" }
+---
+
+## Cuentas
+
+Al igual que Ethereum, Scroll tiene dos tipos de cuentas: Cuenta de propiedad externa (EOA) y cuenta de contrato que contiene el smart contract y almacenamientos adicionales.
+
+Scroll almacena información adicional en el bytecode del contrato en la cuenta para facilitar que el circuito zkEVM pruebe la transición de estado de forma más eficiente.
+
+La cuenta en Scroll contiene los siguientes campos:
+
+- `nonce`: Un contador que indica el número de transacciones enviadas por el emisor.
+- `balance`: El saldo del token `ETH` en el balance de la cuenta (unidad en wei).
+- `storageRoot`: El hash raíz del trie de almacenamiento. Dado que Scroll utiliza [zkTrie](/es/technology/sequencer/zktrie) para el trie de almacenamiento, `storageRoot` almacena el hash digest de Poseidon en un entero de 256 bits.
+- `codeHash`: El hash digest Keccak del bytecode del contrato.
+- `PoseidonCodeHash` (**nuevo campo**): El hash digest Poseidon del bytecode del contrato en un entero de 256 bits.
+- `CodeSize` (**nuevo campo**): El número de bytes en el bytecode del contrato.
+
+## Estado
+
+El estado de una blockchain es una colección de datos de cuentas. El _state trie_ codifica los datos de las cuentas y sus correspondientes direcciones en una estructura de datos [Merkle tree](https://en.wikipedia.org/wiki/Merkle_tree). La "root del tree", o el estado del blockchain, es un compendio criptográfico de todos los datos de cuentas contenidos en el árbol.
+
+Ethereum utiliza una estructura de datos llamada [Patricia Merkle Trie](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) tanto para el trie de estado como para el trie de almacenamiento que guarda las entradas llave-valor almacenadas en un smart contract. En Scroll, sustituimos Patricia Merkle Trie por una estructura de datos más compatible con zk, llamada zkTrie, tanto para la trie de estado como para la trie de almacenamiento. A alto nivel, la estructura de datos zkTrie es un Merkle tree binario disperso con [Poseidon hash](https://eprint.iacr.org/2019/458.pdf), una función hash compatible con zk. El documento [zkTrie](/es/technology/sequencer/zktrie) describe más detalles sobre esta estructura de datos.
diff --git a/src/content/docs/es/technology/chain/blocks.mdx b/src/content/docs/es/technology/chain/blocks.mdx
new file mode 100644
index 000000000..e7f099e35
--- /dev/null
+++ b/src/content/docs/es/technology/chain/blocks.mdx
@@ -0,0 +1,37 @@
+---
+section: technology
+date: Last Modified
+title: "Bloques"
+lang: "es"
+permalink: "technology/chain/blocks"
+whatsnext: { "Proceso del Rollup": "/es/technology/chain/rollup/" }
+---
+
+Un bloque es una recopilación de transacciones y enlaces con el bloque anterior al que amplía.
+
+## Block Header
+
+La block header en Scroll refleja la estructura de Ethereum. Sin embargo, algunos campos de la block header se han modificado para adaptarse al contexto de la capa 2, como se detalla en la siguiente tabla:
+
+| Campo               | Descripción                                                        |
+| ------------------- | ------------------------------------------------------------------ |
+| `parentHash`        | El hash del bloque padre.                                      |
+| `uncleHash`         | Siempre 0.                                                          |
+| `coinbase`          | Dirección del contrato de la vault de comisiones pre-desplegada `0x5300000000000000000000000000000000000005`.             |
+| `stateRoot`         | El hash root del state trie. Esto es Poseidon.                |
+| `transactionsRoot ` | El hash del trie de transacción.                                  |
+| `receiptsRoot `     | El hash del trie del comprobante de la transacción.                         |
+| `logsBloom`         | La estructura de datos que contiene los registros de eventos.                          |
+| `difficulty`        | Siempre 0.                                                          |
+| `number`            | El número del Bloque.                                                  |
+| `gasLimit`          | El gas máximo permitido en el bloque.                              |
+| `gasUsed`           | El gas utilizado en el bloque.                                         |
+| `timestamp`         | El tiempo del bloque.                                                    |
+| `extraData`         | Datos arbitrarios adicionales.                                         |
+| `mixHash`           | Siempre 0.                                                          |
+| `nonce`             | Siempre 0.                                                          |
+| `baseFee`           | Actualmente vacío en Scroll porque no hemos activado el EIP-1559. |
+
+## Tiempo de bloque
+
+El tiempo de bloque se refiere al intervalo entre dos bloques consecutivos. En Scroll, el tiempo de bloque está fijado en 3s. Un tiempo de bloque reducido mejora la experiencia del usuario y aumenta la escalabilidad de la cadena de Scroll.
diff --git a/src/content/docs/es/technology/chain/differences.mdx b/src/content/docs/es/technology/chain/differences.mdx
new file mode 100644
index 000000000..a5c69ad82
--- /dev/null
+++ b/src/content/docs/es/technology/chain/differences.mdx
@@ -0,0 +1,46 @@
+---
+section: technology
+date: Last Modified
+title: "Diferencias de EVM respecto a Ethereum"
+lang: "es"
+permalink: "technology/chain/differences"
+whatsnext: { "Bridge": "/es/technology/bridge/cross-domain-messaging/" }
+---
+
+## Opcodes
+
+| Opcode                      | Comportamiento de Scroll                                                                                                  |
+| --------------------------- | ---------------------------------------------------------------------------------------------------------------- |
+| `BLOCKHASH`                 | Devuelve `keccak(chain_id \|\| block_number)` para los últimos 256 bloques.                                            |
+| `COINBASE`                  | Devuelve la dirección de la vault de comisiones (contrato predesplegado `0x53000000000000000000000000000000000000000005`).               |
+| `DIFFICULTY` / `PREVRANDAO` | Devuelve siempre 0.                                                                                                 |
+| `BASEFEE`                   | Desactivado porque actualmente desactivamos el EIP-1559. Si el opcode es detectado, la transacción será revertida. |
+| `SELFDESTRUCT`              | Desactivado. Si el opcode es detectado, la transacción será revertida.                                        |
+
+## Contratos Precompilados
+
+| Dirección | Nombre         | Comportamiento de Scroll                                                                                 |
+| ------- | ------------ | ----------------------------------------------------------------------------------------------- |
+| `0x02`  | `SHA2-256`   | Actualmente no soportado.                                                                        |
+| `0x03`  | `RIPEMD-160` | Actualmente no soportado.                                                                        |
+| `0x05`  | `modexp`     | Restringe los valores de entrada `B, E, M` a enteros sin signo menores que $2^{256}$.                   |
+| `0x08`  | `ecPairing`  | Las entradas siguen siendo múltiplos de 6 valores de 32 bytes, pero limitan el número de tuplas a un máximo de 4. |
+| `0x09`  | `blake2f`    | Actualmente no soportado.                                                                        |
+
+El resto de contratos precompilados tienen el mismo comportamiento que Ethereum. Sin embargo, su uso máximo dentro de un bloque está restringido por un límite ligado a la capacidad del circuito zkEVM.
+
+## EIPs
+
+Nuestro secuenciador se desarrolló basándose inicialmente en la London fork. Deshabilitamos algunos EIPs en la London fork e introdujimos algunos EIPs de la Shanghai fork para mejorar la compatibilidad.
+
+EIPs deshabilitados hasta la London fork:
+
+- [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559): Cambio en el "market fee" y tipo de transacción EIP-1559
+- [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930): Listas de acceso opcionales
+- [EIP-3198](https://eips.ethereum.org/EIPS/eip-3198): opcode `BASEFEE` 
+
+EIP importados de la Shanghai fork:
+
+- [EIP-3651](https://eips.ethereum.org/EIPS/eip-3651): Warm `COINBASE`
+- [EIP-3855](https://eips.ethereum.org/EIPS/eip-3855): instrucción `PUSH0`
+- [EIP-3860](https://eips.ethereum.org/EIPS/eip-3860): Límite y medidor initcode
diff --git a/src/content/docs/es/technology/chain/rollup.mdx b/src/content/docs/es/technology/chain/rollup.mdx
new file mode 100644
index 000000000..d78647ce9
--- /dev/null
+++ b/src/content/docs/es/technology/chain/rollup.mdx
@@ -0,0 +1,155 @@
+---
+section: technology
+date: Last Modified
+title: "Proceso del Rollup"
+lang: "es"
+permalink: "technology/chain/rollup"
+whatsnext: { "Diferencias de EVM respecto a Ethereum": "/es/technology/chain/differences/" }
+---
+
+import ClickToZoom from "../../../../../components/ClickToZoom.astro"
+import RollupProcess from "../_images/rollup.png"
+
+Este documneto describe el proceso del Rollup en Scroll
+
+## Flujo de Trabajo
+
+<ClickToZoom src={RollupProcess} alt="Rollup Process" />
+
+La figura ilustra el flujo de trabajo del rollup. El secuenciador L2 contiene tres módulos:
+
+- **Sync Service** se suscribe al evento emitido desde el contrato bridge L1. Una vez que detecta cualquier mensaje recién añadido a la inbox de L1, el Sync Service generará una nueva transacción `L1MessageTx` en consecuencia y la añadirá a la cola local de transacciones L1.
+- **Mempool** recoge las transacciones que se envían directamente al secuenciador L2.
+- El **Executor** extrae las transacciones tanto de la cola de transacciones L1 como de la mempool L2 y las ejecuta para construir un nuevo bloque L2.
+
+El nodo rollup contiene tres módulos:
+
+- **Relayer** envía las transacciones de confirmación y las transacciones de finalización al contrato de rollup para la disponibilidad y la finalidad de los datos.
+- Los módulos **Chunk Proposer** y **Batch Proposer** proponen nuevos chunks y nuevos lotes siguiendo las restricciones descritas en [Lotes de Transacciones](/es/technology/chain/transactions#lotes-de-transacciones).
+
+El proceso de rollup puede dividirse en tres fases: ejecución de transacciones, procesamiento por lotes y compromiso de datos, y generación y finalización de pruebas.
+
+### Fase 1. Ejecución de Transacciones
+
+1. Los usuarios envían transacciones al contrato bridge en L1 o a los secuenciadores en L2.
+2. El Sync Service del secuenciador en L2 obtiene las últimas transacciones en L1 adjuntas del contrato bridge.
+3. El secuenciador en L2 procesa las transacciones tanto de la cola de mensajes en L1 como del mempool en L2 para construir bloques en L2.
+
+### Fase 2. Procesamiento por Lotes y Compromiso de Datos
+
+4. El nodo de rollup monitoriza los últimos bloques en L2 y obtiene los datos de la transacción.
+5. Si se cumplen los criterios (descritos en [Lotes de Transacciones](/es/technology/chain/transactions#transaction-batching)), el nodo rollup propone un nuevo chunk o lote y lo escribe en la base de datos. En caso contrario, el nodo rollup seguirá esperando más bloques o chunks.
+6. Una vez creado un nuevo lote, el rollup relayer recopila los datos de la transacción en este lote y envía una Commit Transaction al contrato rollup para la disponibilidad de los datos.
+
+### Fase 3. Generación y Finalización de Pruebas.
+
+7. Una vez que el coordinador sondea un nuevo chunk o lote de la base de datos:
+   - Ante un nuevo chunk, el coordinador consultará las trazas de ejecución de todos los bloques de este chunk al secuenciador L2 y enviará una proving task de chunk a un prover zkEVM seleccionado al azar.
+   - Ante un nuevo lote, el coordinador recopilará todas las pruebas de todos de los chunks de este lote y enviará una proving task de lote a un prover agregador seleccionado aleatoriamente.
+8. Cuando el coordinador reciba una prueba de chunk o lote de un prover, escribirá la prueba en la base de datos.
+9. Una vez que el rollup relayer obtenga una nueva prueba de lote de la base de datos, enviará una transacción de finalización al contrato de rollup para verificar la prueba.
+
+## Commit Transaction
+
+La Commit Transaction envía la información del bloque y los datos de la transacción a L1 para la disponibilidad de los datos. La transacción incluye el batch header padre, los datos del chunk y un mapa de bits del mensaje L1 omitido. El batch header padre designa el lote anterior al que se vincula este lote. El lote padre debe confirmarse antes; de lo contrario, la transacción se revertirá. Véase la firma de la función `commitBatch` más abajo.
+
+```solidity
+function commitBatch(
+    uint8 version,
+    bytes calldata parentBatchHeader,
+    bytes[] memory chunks,
+    bytes calldata skippedL1MessageBitmap
+) external override OnlySequencer
+```
+
+Después de que la función `commitBatch` verifique que el lote padre se ha consignado antes, construye el batch header y almacena el hash del mismo en el contrato `ScrollChain`.
+
+```solidity
+mapping(uint256 => bytes32) public committedBatches;
+```
+
+La codificación del batch header y de los datos de los chunks se describen en la sección [Codec](#codec). La mayoría de los campos de la batch header son fáciles de derivar de los datos de los chunks. Un campo importante a tener en cuenta es `dataHash` que formará parte de la entrada pública para verificar la prueba de validez. Suponiendo que un lote contiene `n` chunks, su `dataHash` se calcula de la siguiente manera
+
+```
+batch.dataHash := keccak(chunk[0].dataHash || ... || chunk[n-1].dataHash)
+```
+
+Suponiendo que un chunk contenga `k` bloques, su `dataHash` se calcula del siguiente modo
+
+```
+chunk.dataHash := keccak(blockContext[0] || ... || blockContext[k-1] ||
+                         block[0].l1TxHashes || block[0].l2TxHashes || ... ||
+                         block[k-1].l1TxHashes || block[k-1].l2TxHashes)
+```
+
+donde `block.l1TxHashes` son los hashes de transacción concatenados de las transacciones L1 en este bloque y `block.l2TxHashes` son los hashes de transacción concatenados de las transacciones L2 en este bloque. Nótese que los hashes de transacción de las transacciones L1 no son cargados por el nodo rollup, sino que se cargan directamente desde el contrato `L1MessageQueue` dado el rango de índices de los mensajes L1 incluidos en este bloque. Los hashes de transacciones L2 se calculan a partir de los bytes codificados en RLP en el campo `l2Transactions` del [`Chunk`](#Chunk-Codec).
+
+Además, la función `commitBatch` contiene un mapa de bits de los mensajes L1 omitidos. Lamentablemente, esto se debe al problema del sobreflujo de pruebas. Si la transacción en L1 correspondiente a un mensaje en L1 supera el límite de capacidad del circuito, no podremos generar una prueba válida para esta transacción y, por tanto, no podremos finalizarla en L1. Scroll está trabajando activamente para eliminar el problema del sobreflujo de pruebas mediante actualizaciones de nuestro sistema de pruebas.
+
+## Finalización de la Transacción
+
+La Transacción finaliza con el lote previamente comprometido y su prueba de validez. La transacción también presenta la "state root" y la "withdraw root" después del lote. Esta es la firma de la función `finalizeBatchWithProof`:
+
+```solidity
+function finalizeBatchWithProof(
+    bytes calldata batchHeader,
+    bytes32 prevStateRoot,
+    bytes32 postStateRoot,
+    bytes32 withdrawRoot,
+    bytes calldata aggrProof
+) external override OnlyProver
+```
+
+La función `finalizeBatchWithProof` primero verifica si el lote ha sido comprometido en el contrato. A continuación, calcula el hash de entrada público de la siguiente manera
+
+```
+publicInputHash := keccak(chainId || prevStateRoot || postStateRoot || withdrawRoot || batch.dataHash)
+```
+
+El hash de entrada público y la prueba de validez se envían al verificador de plonk en solidity. Una vez superada la verificación, la nueva "state root" y la "withdraw root" se almacenan en el contrato `ScrollChain`.
+
+```solidity
+mapping(uint256 => bytes32) public override finalizedStateRoots;
+mapping(uint256 => bytes32) public override withdrawRoots;
+```
+
+En esta fase, la "state root" del último lote finalizado puede utilizarse de forma trustless y las transacciones de retirada de ese lote pueden ejecutarse en L1 utilizando la prueba de Merkle para la "withdraw root".
+
+## Codec
+
+Esta sección describe el codec de tres estructuras de datos del contrato Rollup: `BatchHeader`, `Chunk` y `BlockContext`.
+
+### Codec `BatchHeader` 
+
+| Campo                    | Bytes   | Tipo        | Offset | Descripción                                                     |
+| ------------------------ | ------- | ----------- | ------ | --------------------------------------------------------------- |
+| `version`                | 1       | `uint8`     | 0      | La versión del batch header.                                        |
+| `batchIndex`             | 8       | `uint64`    | 1      | El index del lote.                                          |
+| `l1MessagePopped`        | 8       | `uint64`    | 9      | El número de mensajes L1 emitidos en el lote.                    |
+| `totalL1MessagePopped`   | 8       | `uint64`    | 17     | El número total de mensajes L1 emitidos tras el lote.          |
+| `dataHash`               | 32      | `bytes32`   | 25     | El hash de datos del lote.                                      |
+| `parentBatchHash`        | 32      | `bytes32`   | 57     | El hash del lote padre.                                           |
+| `skippedL1MessageBitmap` | dynamic | `uint256[]` | 89     | Un mapa de bits para indicar qué mensajes L1 se omiten en el lote. |
+
+### Codec `Chunk`
+
+| Campo            | Bytes   | Tipo           | Offset    | Descripción                                                                                                                                       |
+| ---------------- | ------- | -------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `numBlocks`      | 1       | `uint8`        | 0         | El número de bloques del chunk.                                                                                                                 |
+| `block[0]`       | 60      | `BlockContext` | 1         | La información del bloque 1.                                                                                                            |
+| ...              | ...     | ...            | ...       | ...                                                                                                                                               |
+| `block[i]`       | 60      | `BlockContext` | `60*i+1`  | La información del bloque `i+1`-ésimo.                                                                                                           |
+| ...              | ...     | ...            | ...       | ...                                                                                                                                               |
+| `block[n-1]`     | 60      | `BlockContext` | `60*n-59` | La información del último bloque.                                                                                                           |
+| `l2Transactions` | dynamic | `bytes`        | `60*n+1`  | La codificación RLP concatenada de transacciones L2 con firmas. La longitud en bytes (`uint32`) de la codificación RLP se inserta antes de cada transacción. |
+
+### Codec `BlockContext`
+
+| Campo             | Bytes | Tipo      | Offset | Descripción                                                                         |
+| ----------------- | ----- | --------- | ------ | ----------------------------------------------------------------------------------- |
+| `blockNumber`     | 8     | `uint64`  | 0      | El número del bloque.                                                                        |
+| `timestamp`       | 8     | `uint64`  | 8      | El tiempo del bloque.                                                                        |
+| `baseFee`         | 32    | `uint256` | 16     | La comisión base de este bloque. Actualmente, siempre es 0, porque desactivamos el EIP-1559. |
+| `gasLimit`        | 8     | `uint64`  | 48     | El límite de gas de este bloque.                                                             |
+| `numTransactions` | 2     | `uint16`  | 56     | El número de transacciones en este bloque, incluyendo las txns en L1 y L2                    |
+| `numL1Messages`   | 2     | `uint16`  | 58     | El número de mensajes L1 en este bloque                                                      |
diff --git a/src/content/docs/es/technology/chain/transactions.mdx b/src/content/docs/es/technology/chain/transactions.mdx
new file mode 100644
index 000000000..c7d94f80d
--- /dev/null
+++ b/src/content/docs/es/technology/chain/transactions.mdx
@@ -0,0 +1,91 @@
+---
+section: technology
+date: Last Modified
+title: "Transacciones"
+lang: "es"
+permalink: "technology/chain/transactions"
+whatsnext: { "Bloques": "/es/technology/chain/blocks/" }
+---
+
+import ClickToZoom from "../../../../../components/ClickToZoom.astro"
+import TransactionBatching from "../_images/batching.png"
+
+Una transacción es un mensaje firmado criptográficamente que inicia una transición de estado al estado de la cadena. Puede ser una simple transferencia de saldo o la llamada a un smart contract, que a su vez ejecuta un programa para alterar el estado.
+
+## Tipo de Transacción
+
+Actualmente, Scroll admite tres tipos de transacciones.
+
+- Transacción Pre-EIP-155: Soporta el contrato [Singleton Factory](https://eips.ethereum.org/EIPS/eip-2470).
+- Transacción Legacy (consulte [EIP-155](https://eips.ethereum.org/EIPS/eip-155))
+- Transacción tipo `L1MessageTx` (Tipo: `0x7E`): Se trata de una nueva transacción [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) introducida en Scroll como se describe a continuación. Este tipo de transacción es para transacciones iniciadas en L1.
+
+Ten en cuenta que los tipos de transacción [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) y [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) no están soportados actualmente en Scroll. Scroll incorporará estos dos tipos de transacción en el futuro.
+
+### Transacción de Mensajes en L1
+
+Introducimos un nuevo tipo de transacciones `L1MessageTx` para transacciones iniciadas por L1. Este tipo de transacción se inicia en el contrato bridge de L1. Cada vez que se añade un nuevo mensaje al contrato `L1MessageQueue` en L1, el secuenciador L2 creará una transacción `L1MessageTx` correspondiente que se incluirá en los bloques en L2. Dado que la firma ya se verificó implícitamente cuando los usuarios enviaron la transacción en L1, las transacciones `L1MessageTx` no tienen firma.
+
+El tipo de transacción `L1MessageTx` es `0x7E` y su payload se define como se muestra a continuación.
+
+```go
+type L1MessageTx struct {
+	QueueIndex uint64          // The queue index of the message queue in L1 contract
+	Gas        uint64          // Gas limit
+	To         *common.Address // Cannot be nil, we do not allow contract creation from L1
+	Value      *big.Int
+	Data       []byte
+	Sender     common.Address
+}
+```
+
+La codificación RLP de las transacciones `L1MessageTx` sigue la regla [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) `TransactionType || TransactionPayload`, donde `TransactionType` es `0x7E` y `TransactionPayload = RLP(L1MessageTx)`.
+
+Dos comportamientos notables de las transacciones `L1MessageTx`:
+
+- El `QueueIndex` de la transacción es el índice de la cola de mensajes en L1, distinto del `Nonce` de la cuenta `Sender`. Pero el `Nonce` del remitente seguirá aumentando en 1 después de la transacción.
+- Este tipo de transacciones no paga [Comisión en L2](/es/developers/transaction-fees-on-scroll#l2-fee) o [Comisión en L1](/es/developers/transaction-fees-on-scroll#l1-fee). La comisión L2 ya se paga cuando los usuarios envían transacciones en L1. La comisión L1 no se cobra porque los datos de las transacciones `L1MessageTx` ya están disponibles en el contrato bridge de L1.
+
+## Ciclo de Vida de las Transacciones
+
+El ciclo de vida de la transacción en Scroll contiene las tres fases:
+
+1. **Confirmed**: El usuario envía una transacción al contrato bridge en L1 o al secuenciador en L2. La transacción se convierte en `Confirmed` después de ser ejecutada e incluida en un bloque en L2.
+2. **Committed**: Las transacciones se incluyen en un lote y se envía a L1 una _commit transaction_ que contiene los datos de este lote. Después de que la commit transaction se finaliza en los bloques L1, las transacciones de este lote se convierten en `Committed`.
+3. **Finalized**: La prueba de validez de este lote se genera y verifica en el L1. Después de que la _finalize transaction_ se termina en el L1, el estado de la transacción es `Finalized` y se convierte en una parte canónica de la Scroll L2 chain.
+
+### Envío de transacciones
+
+Hay dos puntos de entrada en los que los usuarios pueden enviar transacciones a Scroll.
+
+En primer lugar, los usuarios pueden enviar transacciones directamente al secuenciador en L2. Para ello, los usuarios sólo tienen que configurar sus wallets y conectarse al endpoint RPC de Scroll. El secuenciador valida la transacción y la almacena en su fondo de transacciones local.
+
+En segundo lugar, las transacciones de depósito y ejecución originadas en L1. El contrato bridge de Scroll L1 proporciona tres puntos de entrada para que los usuarios y los smart contracts envíen transacciones desde el L1. Todos los mensajes enviados a través de estos tres puntos de entrada se añadirán al contrato `L1MessageQueue`.
+
+- El contrato `ScrollGatewayRouter` y varias gateways de tokens estándares permiten a los usuarios y contratos depositar tokens estándares en la L2. Ver más detalles en [Gateways de Depósito](/es/technology/bridge/deposit-gateways).
+- El contrato `L1ScrollMessenger` permite a los usuarios y contratos enviar mensajes arbitrarios a L2. Ver más detalles en [Envío de Mensajes Arbitrarios](/es/technology/bridge/cross-domain-messaging#envío-de-mensajes-arbitrarios).
+- El contrato `EnforcedTxGateway` permite a los EOA iniciar una transacción forzada desde la misma dirección para retirar tokens o llamar a otros contratos en L2. Ver más detalles en [Envío de Transacciones Forzadas](/es/technology/bridge/cross-domain-messaging#envío-de-transacciones-forzadas).
+
+El secuenciador de Scroll inicia periódicamente un nuevo trabajo de minería. Extrae los mensajes L1 del contrato `L1MessageQueue` y las transacciones en el mempool de L2 y sella un bloque. Una vez que una transacción se incluye en un bloque L2, su estado pasa a ser `Confirmed`.
+
+### Compilación de datos de transacciones
+
+El nodo de rollup recopila nuevos bloques en L2 y los empaqueta en trozos y lotes (ver más detalles en [Lotes de Transacciones](/es/technology/chain/transactions#lotes-de-transacciones)). Periódicamente envía una _Commit Transaction_ que publica los datos de un lote de transacciones en el contrato L1 `ScrollChain`. Una vez finalizada la commit transaction en un bloque L1, el estado de las transacciones de este lote pasa a ser `Committed`. En este momento, los usuarios pueden reconstruir por sí mismos el estado L2 completamente basándose en los datos consignados del contrato L1.
+
+### Finalizar transacciones
+
+Una vez generada la prueba de validez, el rollup node envía una _Finalize Transaction_ que incluye la prueba de validez y el nuevo state root después de este lote para su verificación onchain. Una vez que la transacción finalizada se confirma en un bloque de L1, el estado de las transacciones L2 de este lote pasa a ser `Finalized`. La nueva state root puede ser utilizada por terceros con total confianza.
+
+## Lotes de Transacciones
+
+<ClickToZoom src={TransactionBatching} alt="Transaction Batching" />
+
+En Scroll, las transacciones se agrupan en varios niveles.
+
+1. Un grupo de transacciones ordenadas se empaquetan en un bloque.
+2. Una serie de bloques contiguos se agrupan en un chunk. El chunk es la unidad base para la generación de pruebas del circuito zkEVM.
+3. Una serie de bloques contiguos se agrupan en un lote. El lote es la unidad base para el compromiso de datos y la verificación de pruebas en la L1. La prueba de un lote, o _batch proof_, es una prueba agregada de las pruebas de los chunks de este lote.
+
+El objetivo de este esquema de lotes multi-layer es reducir el costo de gas del compromiso de datos onchain y la verificación de pruebas. Este enfoque aumenta la granularidad de las unidades de rollup en L1 al tiempo que tiene en cuenta la capacidad del circuito fijo. Como resultado, la división en lotes reduce los datos que deben almacenarse en el contrato y amortiza el costo de verificación de la prueba a más transacciones L2.
+
+Una vez creado un chunk, se generará una tarea de comprobación de chunk correspondiente y se enviará a un prover de zkEVM. Tras la creación de un nuevo lote, se producen dos acciones posteriores: (a) el nodo de rollup consigna los datos de transacción y la información de bloque de este lote al contrato L1, y (b) se envía una proving task para agregar pruebas de los chunks a un prover agregador. Las normas para proponer un chunk y un batch se detallan en [Rollup Node](/es/technology/sequencer/rollup-node).
diff --git a/src/content/docs/es/technology/index.mdx b/src/content/docs/es/technology/index.mdx
new file mode 100644
index 000000000..3a5de3e5c
--- /dev/null
+++ b/src/content/docs/es/technology/index.mdx
@@ -0,0 +1,24 @@
+---
+section: technology
+date: Last Modified
+title: "Arquitectura de Scroll"
+lang: "es"
+permalink: "technology"
+whatsnext:
+  { "Scroll Chain": "/es/technology/chain/accounts", "Bridge": "/es/technology/bridge/cross-domain-messaging", "Secuenciador": "/es/technology/sequencer/execution-node", "zkEVM": "/es/technology/zkevm/zkevm-overview" }
+---
+
+import ClickToZoom from "../../../../components/ClickToZoom.astro"
+import Architecture from "./_images/arch.png"
+
+<ClickToZoom src={Architecture} alt="Architecture" />
+
+Como se ilustra en la figura anterior, la Scroll chain consta de tres capas:
+
+- **Settlement Layer**: proporciona disponibilidad de datos y ordenación para la Scroll chain canónica, verifica las pruebas de validez, y permite a los usuarios y dapps enviar mensajes y activos entre Ethereum y Scroll. Utilizamos Ethereum como Settlement Layer y desplegamos el bridge y el rollup contract en Ethereum.
+- **Sequencing Layer**: contiene un *Execution Node* que ejecuta las transacciones enviadas al secuenciador de Scroll y las transacciones enviadas al bridge contract en L1 y produce bloques en L2, y un *Rollup Node* que agrupa transacciones, publica datos de transacciones e información de bloques en Ethereum para la disponibilidad de datos, y envía pruebas de validez a Ethereum para la finalización.
+- **Proving Layer**: consiste en un grupo de probadores que son responsables de generar las pruebas de validez zkEVM que verifican la corrección de las transacciones L2, y un coordinador que envía las tareas de prueba a los probadores y retransmite las pruebas al Rollup Node para finalizarlas en Ethereum.
+
+Esta sección de la documentación proporciona información exhaustiva sobre la especificación del protocolo Scroll, el protocolo bridging, el secuenciador y el circuito zkEVM.
+
+*En el resto de esta sección, L1 se referirá a Ethereum, mientras que L2 se referirá a Scroll.*
diff --git a/src/content/docs/es/technology/prover/proof-generation.mdx b/src/content/docs/es/technology/prover/proof-generation.mdx
new file mode 100644
index 000000000..028be2e2a
--- /dev/null
+++ b/src/content/docs/es/technology/prover/proof-generation.mdx
@@ -0,0 +1,7 @@
+---
+section: technology
+date: Last Modified
+title: "Proof Generation"
+lang: "en"
+permalink: "technology/prover/proof-generation"
+---
diff --git a/src/content/docs/es/technology/sequencer/execution-node.mdx b/src/content/docs/es/technology/sequencer/execution-node.mdx
new file mode 100644
index 000000000..98c86676e
--- /dev/null
+++ b/src/content/docs/es/technology/sequencer/execution-node.mdx
@@ -0,0 +1,83 @@
+---
+section: technology
+date: Last Modified
+title: "Nodo de Ejecución"
+lang: "es"
+permalink: "technology/sequencer/execution-node"
+whatsnext: { "Nodo Rollup": "/es/technology/sequencer/rollup-node/" }
+---
+
+import Aside from "../../../../../components/Aside.astro"
+
+El nodo de ejecución es uno de los componentes centrales del protocolo Scroll: se encarga de mantener la blockchain L2. El nodo de ejecución también garantiza que la experiencia del usuario y del desarrollador en Scroll se parezca mucho a la de Ethereum. Para ello, mantiene el comportamiento EVM y RPC heredado directamente de Ethereum, con muy pocas modificaciones.
+
+Las funciones principales del nodo de ejecución de Scroll son:
+- Recoger transacciones de L2 y L1.
+- Validar transacciones y agruparlas en bloques en L2.
+- Ejecutar bloques y mantener el estado del blockchain L2.
+
+Cabe destacar que la transmisión de mensajes y tokens de L1 a L2 (depósitos) también es responsabilidad del nodo de ejecución. Los mensajes de L2 a L1 (retiros), por otro lado, pueden ser ejecutados por cualquier usuario en L1.
+
+Las funciones secundarias del nodo de ejecución de Scroll son:
+- Ofrecer APIs RPC estándar de Ethereum y algunas APIs de extensión de Scroll.
+- Permitir a los peers (nodos seguidores) sincronizar la blockchain utilizando el protocolo peer-to-peer de Ethereum.
+
+El nodo de ejecución, al ser un fork de [go-ethereum](https://github.com/ethereum/go-ethereum), hereda la mayor parte de su funcionalidad de Ethereum. Esto incluye estructuras de datos de transacciones y bloques, ejecución EVM, RPC y protocolos p2p. Como estos no fueron reimplementados sino que fueron heredados directamente de `go-ethereum`, podemos tener una certeza muy alta de la compatibilidad de Scroll con Ethereum.
+
+Las siguientes secciones presentarán los principales componentes del nodo de ejecución, las reglas de validación adicionales y un resumen de los detalles de la modificación.
+
+## Componentes de `l2geth`
+
+[`l2geth`](https://github.com/scroll-tech/go-ethereum) es un fork de Scroll de [go-ethereum](https://github.com/ethereum/go-ethereum). Es responsable de construir y ejecutar bloques y de mantener el estado de la cadena de bloques. `l2geth` hereda la mayor parte de su funcionalidad de Ethereum, con algunas diferencias notables que se enumeran a continuación. `l2geth` tiene los siguientes submódulos (lista no exhaustiva):
+- **Storage**: Ledger y almacenamiento de estado implementado usando LevelDB.
+- **EVM**: Las reglas de transición de estado de Ethereum.
+- **Worker:** Responsable de la creación de nuevos bloques en L2.
+- **L1 SyncService**: Sincroniza y almacena mensajes de L1 en la base de datos local `l2geth`.
+- **API Layer**: Interfaces estándar RPC y p2p de Ethereum.
+- **Transaction pool**: Mempool para transacciones en L2.
+- **Circuit capacity checker**: comprueba si una transacción o un bloque excede el límite de capacidad del circuito.
+
+### Comprobador de capacidad del circuito
+
+Con los circuitos zkEVM actuales de Scroll, es posible construir transacciones y bloques que no se pueden probar porque no caben en el circuito zkEVM. A esto lo llamamos *proof overflow*. Para evitarlo, implementamos un módulo *circuit capacity checker* como parte de l2geth. El comprobador de capacidad del circuito se utiliza tanto durante la creación como durante la validación de bloques.
+
+Durante la creación del bloque, si la siguiente transacción podría provocar una proof overflow, sellamos el bloque y dejamos la transacción para el siguiente bloque. Si una transacción conduce a una proof overflow, l2geth la descarta. A este mecanismo lo denominamos *skipping*.
+
+Omitir transacciones en L2 significa simplemente descartarlas. En este caso, el usuario debe enviar otra transacción con el mismo nonce que no provoque una proof overflow para poder continuar.
+
+Omitir mensajes en L1 es un proceso más explícito. Tanto el contrato `ScrollChain` en L1 como el zkEVM verifican que cada transacción en L1 en `L1MessageQueue` se incluyó y ejecutó, o se omitió. Aunque la codificación por lotes no contiene transacciones en L1, sí incluye un *skip bitmap* que indica a `ScrollChain` qué mensajes en L1 se han omitido. Si se omite un mensaje de depósito en L1, el usuario puede obtener la devolución de sus tokens en L1.
+
+<Aside type="note" title="Nota">
+  {" "}
+  Una Proof overflow y la omisión sugiere actividad maliciosa; para las transacciones de depósito normales, esto nunca ocurrirá.
+  {" "}
+</Aside>
+
+Como la unidad de prueba de zkEVM es el chunk, el proof overflow debe evitarse también para los chunks.
+Esto se consigue incorporando el verificador de la capacidad del circuito en el rollup-relayer para asegurarse de que nunca propone chunks no comprobables.
+
+## Reglas de Validación
+
+Scroll añade algunas reglas de validación además de las reglas de validación de bloques de Ethereum. Estas nuevas reglas restringen el comportamiento L2 de la inclusión de mensajes L1 y el límite de capacidad del circuito zkEVM.
+- El módulo [Comprobador de capacidad del circuito](/es/technology/sequencer/execution-node/#comprobador-de-capacidad-del-circuito) descrito anteriormente
+verifica que el bloque puede encajar en la capacidad del espacio del circuito zkEVM.
+- Reglas relacionadas con los mensajes en L1:
+    - Los mensajes en L1 de un bloque deben ser contiguos y estar al principio del bloque.
+    - Los mensajes en L1 de un bloque deben incluirse siguiendo su orden en `L1MessageQueue`, es decir, deben incluirse con `QueueIndex` creciente.
+    - Los mensajes en L1 de un bloque deben coincidir con los del contrato `L1MessageQueue`.
+- La mayoría de estas reglas se tienen en cuenta tanto durante la creación del bloque como durante su validación. Como resultado, si el nodo proponente del bloque viola alguna de estas reglas, los nodos seguidores rechazarán sus bloques.
+
+
+## Resumen de las Modificaciones
+
+El nodo de ejecución Scroll hereda la mayoría de los comportamientos de Ethereum. Sin embargo, hemos tenido que realizar algunos cambios incompatibles con Ethereum en `l2geth` para permitir una prueba más eficiente. Esta sección proporciona una lista no exhaustiva de las modificaciones, junto con su justificación.
+
+- **State and storage tree**: Ethereum utiliza el MPT (Merkle-Partricia Trie) como estructura de datos de almacenamiento de estados y contratos. La estructura de este trie y el hecho de que utilice hash Keccak lo harían prohibitivamente caro para los circuitos ZK. En su lugar, `l2geth` utiliza [zkTrie](/es/technology/sequencer/zktrie): un trie Merkle binario con Poseidon hash para su almacenamiento de estados y contratos.
+- **StateAccount**: La modificación de la cuenta de estado se describe en [Cuentas y Estado](/technology/chain/accounts).
+- **EVM**: Las modificaciones se describen en las [Diferencias de EVM respecto a Ethereum](/es/technology/chain/differences).
+- **Comisiones de transacción**
+    - Todas las comisiones recaudadas en L2 se envían a un contrato vault de comisiones en L2 mantenido por Scroll.
+    - Comisión L1: Además de la tasa de gas L2 que cubre el espacio de bloque L2 y los costos de ejecución, también cobramos una tasa L1 que cubre los costos de comprometer la transacción en L1. Esta tasa es proporcional al tamaño de la transacción codificada en RLP. El costo real depende de la configuración actual almacenada en el contrato `L1GasOracle` en L2. Esta tarifa se deduce directamente del saldo del remitente (y no de la asignación de gas).
+- **L1MessageTx**: Hemos introducido un nuevo tipo de transacción `L1MessageTx`. También hemos añadido interfaces de base de datos para almacenar dichas transacciones y los metadatos relacionados.
+- **SyncService**: supervisa los bloques finalizados en L1 y recoge los mensajes en L1 de los mismos.
+- **Nueva API**: El `l2geth` ofrece una API de rastreo `scroll_traceBlockByNumberOrHash` para que los provers puedan consultar la información de rastreo para generar pruebas.
diff --git a/src/content/docs/es/technology/sequencer/rollup-node.mdx b/src/content/docs/es/technology/sequencer/rollup-node.mdx
new file mode 100644
index 000000000..ac069e88c
--- /dev/null
+++ b/src/content/docs/es/technology/sequencer/rollup-node.mdx
@@ -0,0 +1,33 @@
+---
+section: technology
+date: Last Modified
+title: "Nodo Rollup"
+lang: "es"
+permalink: "technology/sequencer/rollup-node"
+whatsnext: { "zkTrie": "/es/technology/sequencer/zktrie/" }
+---
+
+El nodo de rollup es responsable de dividir el blockchain de Scroll en secciones que sean adecuadas para el proving y commitment en L1. Las dos unidades principales son los *chunks* y los *batches*.
+* Un chunk es simplemente una sección contigua del ledger L2, es una colección de bloques en L2, y los chunks son la unidad de prueba de zkEVM.
+* Por otro lado, un batch (o lote) es una colección de chunks que se envían a L1, junto con una prueba agregada.
+
+El nodo rollup tiene los siguientes submódulos:
+- Chunk Proposer: recopila bloques en L2 y propone chunks aplicando ciertos límites (véase más adelante).
+- Batch Proposer: recopila bloques y propone lotes aplicando ciertos límites (véase más adelante).
+- Relayer: envía datos de lotes y pruebas de lotes a L1.
+
+## Restricciones de chunks y batches
+
+Comparado con el nodo de ejecución, el nodo de rollup es un componente mucho más directo y sencillo.
+Recoge bloques en L2, crea chunks, batches y los envía a L1.
+En esta sección se describen los principales límites que debe cumplir el nodo de rollup durante la creación de "chunks" y "batches".
+
+Restricciones sobre los chunks:
+- **No proof overflow:** Utilizando el comprobador de capacidad de circuitos, nos aseguramos de incluir tantos bloques en un chunk como sea posible para que no se produzca un proof overflow.
+- **L1 payload:** Restricciones heredadas del batch proposer, el payload de la transacción no puede exceder los 128KB.
+
+Restricciones en los lotes:
+- **L1 payload:** Ethereum tiene un límite de 128 KB en el tamaño del payload de la transacción.
+- **L1 commit gas:** El costo de gas de confirmar un lote es proporcional al número de bloques y transacciones que contiene. Debemos asegurarnos de que este costo no excede el límite de gas de bloque L1.
+- **Número de chunks:** Un lote incluye un número de chunks que es óptimo para el prover de agregación.
+
diff --git a/src/content/docs/es/technology/sequencer/zktrie.mdx b/src/content/docs/es/technology/sequencer/zktrie.mdx
new file mode 100644
index 000000000..3c16acae9
--- /dev/null
+++ b/src/content/docs/es/technology/sequencer/zktrie.mdx
@@ -0,0 +1,204 @@
+---
+section: technology
+date: Last Modified
+title: "zkTrie"
+lang: "es"
+permalink: "technology/sequencer/zktrie"
+whatsnext: { "zkEVM": "/es/technology/zkevm/intro-to-zkevm/" }
+excerpt: "zkTrie es un Merkle Patricia Trie binario disperso construido usando Poseidon hash."
+---
+
+import Aside from "../../../../../components/Aside.astro"
+import ClickToZoom from "../../../../../components/ClickToZoom.astro"
+import zktrie1 from "../_images/zktrie-arch.png"
+import zktrie2 from "../_images/zktrie-insertion.png"
+import zktrie3 from "../_images/zktrie-deletion.png"
+
+Este documento describe zkTrie, un Merkle Patricia Trie binario disperso utilizado para almacenar pares llave-valor de forma eficiente. Se explica la estructura del árbol, la construcción, el hash de nodos y las operaciones del árbol, incluyendo la inserción y la eliminación.
+
+También puedes explorar nuestro [zktrie repo](https://github.com/scroll-tech/zktrie).
+
+## Estructura del Árbol
+
+zkTrie es un Merkle Patricia Trie binario disperso, representado en la figura anterior.
+Antes de sumergirnos en el Merkle Patricia Trie binario disperso, hablemos brevemente de los Merkle Trees y los Patricia Tries.
+* **Merkle Tree**: Un Merkle Tree es un árbol donde cada nodo hoja representa un hash de un bloque de datos, y cada nodo no-hoja representa el hash de sus nodos hijos.
+* **Patricia Trie**: Un Patricia Trie es un tipo de árbol radix o trie compreso utilizado para almacenar pares llave-valor de forma eficiente. Codifica los nodos con el mismo prefijo de la llave para compartir el camino común, donde el camino está determinado por el valor de la llave del nodo.
+
+Como se ilustra en la Figura 1, existen tres tipos de nodos en el zkTrie.
+- Nodo Rama: Dado que zkTrie es un sistema binario, un nodo rama dos hijos.
+- Nodo Hoja: Un nodo hoja contiene los datos de un par llave-valor.
+- Nodo Vacío: Un nodo vacío es un tipo especial de nodo, que indica que la sub-trie que comparte el mismo prefijo está vacía.
+
+En zkTrie, usamos Poseidon hash para calcular el hash de nodo porque es más amigable y eficiente probarlo en el circuito zk.
+
+<ClickToZoom src={zktrie1} alt="zkTrie Structure" caption="Figure 1. zkTrie Structure" />
+
+## Construcción del Árbol
+
+Dado un par llave-valor, primero calculamos una *llave segura* para el nodo hoja correspondiente haciendo un hash de la llave original (es decir, la dirección de la cuenta y la llave de almacenamiento) usando la función hash Poseidon. Esto puede hacer que la llave se distribuya uniformemente sobre el espacio de la llave. El método hash de la llave del nodo se describe en la sección [Node Hashing](#node-hashing) más abajo.
+
+Codificamos la ruta de un nuevo nodo hoja recorriendo la llave segura desde el Bit Menos Significativo (Least Significant Bit o LSB) hasta el Bit Más Significativo (Most Significant Bit o MSB). En cada paso, si el bit es 0, pasaremos al hijo izquierdo; en caso contrario, pasaremos al hijo derecho.
+
+Limitamos la profundidad máxima de zkTrie a 248, lo que significa que el árbol sólo recorrerá los 248 bits inferiores de la llave. Debido a que el espacio de llave segura es un campo finito utilizado por Poseidon hash que no ocupa todo el rango de $2^{256}$. la representación de bits de la llave puede ser ambigua en el campo finito y por lo tanto resulta en un problema de solidez en el circuito zk. Después de truncar la llave a 248 bits inferiores, el espacio de la llave puede ocupar completamente el rango de $2^{248}$ y no tendrá la ambigüedad en la representación de bits.
+
+Aplicamos una optimización para reducir la profundidad del árbol contrayendo un subárbol que sólo tiene un nodo hoja para un nodo hoja único. Por ejemplo, en la Figura 1, el árbol tiene tres nodos en total, con las claves `0100`, `0010` y `1010`. Como sólo hay un nodo que tenga la llave con sufijo `00`, el nodo hoja de la llave `0100` sólo atraviesa el sufijo `00` y no expande completamente su llave, lo que hubiera resultado en una profundidad de 4.
+
+## Operaciones del Árbol
+
+### Inserción
+
+<ClickToZoom src={zktrie2} alt="zkTrie Structure" caption="Figure 2. Insert a new leaf node to zkTrie" />
+
+Cuando insertamos un nuevo nodo hoja en una zkTrie, se dan dos casos ilustrados en la Figura 2.
+
+1. Al recorrer la ruta del nodo llave, se llega a un nodo vacío (Figura 2a). En este caso, sólo tenemos que sustituir este nodo vacío por este nodo hoja y retroceder en el camino para actualizar el merkle hash de los nodos rama hasta la raíz.
+2. Cuando se recorre el camino del nodo llave, se llega a otro nodo hoja `b` (Figura 2b). En este caso, tenemos que empujar hacia abajo el nodo hoja existente `b` hasta que el siguiente bit en las llaves de los nodos de dos nodo hoja difiera. En cada paso de empuje hacia abajo, tenemos que insertar un nodo vacío hermano en el nodo rama. Cuando llegamos al nivel en el que los bits difieren, colocamos dos nodo hoja `b` y `d` como hijo izquierdo e hijo derecho en función de sus bits. Por último, volvemos a trazar el camino y actualizamos el hash Merkle de todos los nodos rama.
+
+### Eliminación
+
+<ClickToZoom src={zktrie3} alt="zkTrie Structure" caption="Figure 3. Delete a leaf node from the zkTrie" />
+
+La eliminación de un nodo hoja es similar a la inserción. En la Figura 3 se ilustran dos casos.
+
+1. El nodo hermano del nodo hoja que se va a eliminar es un nodo rama (Figura 3a).
+En este caso, podemos simplemente reemplazar el nodo `a` por un nodo vacío y actualizar el hash de sus ancestros hasta el nodo raíz.
+2. El nodo hoja a eliminar es un nodo hoja (Figura 3b). De forma similar al caso 1, primero sustituimos el nodo hoja por un nodo vacío y empezamos a contraer su nodo hermano hacia arriba hasta que su nodo hermano no sea un nodo vacío. Por ejemplo, en la figura 3b, sustituimos el nodo hoja `b` por un nodo vacío. Como el hermano del nodo `c` se convierte ahora en un nodo vacío, tenemos que mover el nodo `c` un nivel hacia arriba y reemplazar a su padre. El nuevo hermano del nodo `c`, el nodo `e`, sigue siendo un nodo vacío. Así que de nuevo movemos el nodo `c` hacia arriba. Ahora que el hermano del nodo `c` es el nodo `a`, un nodo hoja, el proceso de borrado ha terminado.
+
+Ten en cuenta que el hermano de un nodo hoja en una zkTrie válida no puede ser un nodo vacío. De lo contrario, siempre debemos purgar el subárbol y mover el nodo hoja hacia arriba.
+
+## Hash de Nodos
+
+En esta sección, describiremos cómo se calculan la llave segura de hoja y el hash Merkle de nodo. Usamos Poseidon hash con arity 2 para ambos cálculos hash. En Scroll, la función hash Poseidon está configurada para tomar dos entradas de elementos de campo cada vez y un `domain_value` como contexto inicial para la separación de dominios, denotado como sigue.
+```
+h{domain_value}(input1, input2)
+```
+
+### Nodo Vacío
+
+El hash de un nodo vacío es 0.
+
+### Nodo Rama
+
+El hash del nodo de la rama se calcula del siguiente modo
+
+```go
+branchNodeHash = h{BranchNodeType}(leftChildHash, rightChildHash)
+```
+
+### Nodo Hoja
+
+El hash de un nodo hoja se calcula de la siguiente manera.
+
+```go
+leafNodeHash = h{LeafNodeType}(nodeKey, valueHash)
+```
+
+El cálculo implica dos campos `nodeKey` y `valueHash`.
+- El `nodeKey` es un hash de la llave original. El valor del dominio usado en el hash de Poseidon es 256.
+- El `valueHash` se calcula a partir del hash del valor del nodo hoja. El valor de dominio usado en el hash de Poseidon es `256 * n`, donde `n` es el número de elementos en el valor del nodo hoja.
+
+Hay dos tipos de nodo hoja: Cuentas Ethereum y pares llave-valor de almacenamiento. A continuación, vamos a describir el método de cálculo del nodo llave y el valor hash para cada tipo de nodo hoja, respectivamente.
+
+#### Cuenta Ethereum Nodo Hoja
+Para una Cuenta Ethereum Nodo Hoja, consiste en una dirección de Ethereum y una estructura de datos de cuenta de estado. La llave segura se deriva de la dirección de Ethereum.
+```go
+var address byte[20] // 20 bytes in big-endian
+valHi := address[0:16]
+valLo := address[16:20] * 2^96 // padding 12 bytes of 0 at the end
+nodeKey := h{256}(valHi, valLo)
+```
+
+Una estructura de cuenta de estado en el Scroll consta de los siguientes campos (`Fr` indica el campo finito y es un valor de 254 bits)
+
+- `Nonce`: u64
+- `Balance`: u256, pero tratada como Fr
+- `StorageRoot`: Fr
+- `KeccakCodeHash`: u256
+- `PoseidonCodeHash`: Fr
+- `CodeSize`: u64
+
+Antes de calcular el value hash, la cuenta de estado se transforma en una lista de valores `u256`. El esquema es el siguiente
+
+```text
+(The following scheme assumes the big-endian encoding)
+[0:32]
+	[0:16] Reserved with all 0
+	[16:24] CodeSize, uint64 in big-endian
+	[24:32] Nonce, uint64 in big-endian
+[32:64] Balance
+[64:96] StorageRoot
+[96:128] KeccakCodeHash
+[128:160] PoseidonCodehash
+(total 160 bytes)
+```
+
+La función marshal también devuelve un valor `flag` junto con un vector de valores `u256`. El `flag` es un mapa de bits que indica si un valor `u256` no puede ser tratado como un elemento de campo (Fr). El valor `flag` para la cuenta de estado es 8, como se muestra a continuación.
+
+```
+         +--------------------+---------+------+----------+----------+
+ index   |          0         |    1    |   2  |     3    |     4    |
+         +--------------------+---------+------+----------+----------+
+  u256   | nonce||codesize||0 | balance | root |  keccak  | poseidon |
+         +--------------------+---------+------+----------+----------+
+flag bit |          0         |    0    |   0  |     1    |     0    |
+         +--------------------+---------+------+----------+----------+
+         (LSB)                                                   (MSB)
+```
+
+El value hash se calcula en dos pasos:
+1. Convertir el valor que no puede ser representado como un elemento de campo del Poseidon hash al elemento de campo.
+2. Combinar elementos de campo en una estructura de árbol binario hasta que la raíz del árbol sea tratada como el value hash.
+
+En el primer paso, cuando el bit en el `flag` es 1 indicando el valor `u256` que no puede ser tratado como un elemento de campo, dividimos el valor en un valor alto-128bit y un valor bajo-128bit, y luego los pasamos a un Poseidon hash para derivar un valor de elemento de campo, `h(valueHi, valueLo)`.
+
+```go
+// convert Keccak codehash to a field element
+compressedKeccakCodeHash := h{512}(keccakCodeHash[0:16], keccakCodeHash[16:32])
+```
+
+En segundo lugar, el value hash se calcula del siguiente modo.
+
+```go
+domain := 256 * 5  // 5 elements to compute the valueHash
+valueHash :=
+    h{domain}(
+        h{domain}(
+            h{domain}(nonce||codesize||0, balance),
+            h{domain}(
+                storageRoot,
+                compressedKeccakCodeHash,
+            ),
+        ),
+        poseidonCodeHash,
+    )
+```
+
+#### Almacenamiento de Nodo Hoja
+
+Un nodo hoja de almacenamiento codifica un par llave-valor, en el que tanto la llave como el value son valores `u256`. La llave segura de este nodo hoja se deriva de la llave de almacenamiento.
+
+```go
+var storageKey byte[32]  // 32 bytes in big-endian
+valHi := storageKey[0:16]
+valLo := storageKey[16:32]
+nodeKey := h{256}(valHi, valLo)
+```
+
+El value de almacenamiento es un valor `u256`. El `flag` para el value or de almacenamiento es 1, como se muestra a continuación.
+
+```
+         +--------------+
+  index  |      0       |
+         +--------------+
+  u256   | storageValue |
+         +--------------+
+flag bit |      1       |
+         +--------------+
+```
+
+El value hash se calcula del siguiente modo
+
+```go
+valueHash = h{512}(storageValue[0:16], storageValue[16:32])
+```
diff --git a/src/content/docs/es/technology/zkevm/intro-to-zkevm.md b/src/content/docs/es/technology/zkevm/intro-to-zkevm.md
new file mode 100644
index 000000000..f7edb95a5
--- /dev/null
+++ b/src/content/docs/es/technology/zkevm/intro-to-zkevm.md
@@ -0,0 +1,30 @@
+---
+section: technology
+date: Last Modified
+title: "Introducción a la zkEVM"
+lang: "es"
+permalink: "technology/intro-to-zkevm"
+excerpt: "ZK rollups are widely recognized as the ideal scaling solution for Ethereum."
+whatsnext: { "Vista General de la zkEVM ": "/es/technology/zkevm/zkevm-overview" }
+---
+
+## Introducción y Motivación
+
+Los rollups ZK son ampliamente reconocidos como la solución de escalado ideal para Ethereum. Heredan la fuerte seguridad de la capa 1 de Ethereum y ofrecen la finalidad de transacción más rápida en comparación con otras soluciones de capa 2.
+
+La idea básica de un ZK rollup es ejecutar transacciones fuera de la cadena y generar pruebas de validez sucintas de ejecución. Estas pruebas sucintas pueden publicarse y verificarse en la capa 1 de Ethereum. Los ZK rollups mejoran la escalabilidad, ya que verifican la prueba de un lote de transacciones es mucho más barato que volver a ejecutar el lote de transacciones.
+
+Los rollups ZK pueden clasificarse en rollups de aplicación específica y rollups de uso general, en función de los tipos de transacciones que admiten. Los rollups ZK para aplicaciones específicas están diseñados para conjuntos de transacciones particulares, como pagos y swaps, o por ejemplo, el conjunto de acciones de un jugador para un juego online. En estos casos, los rollups sólo necesitan generar pruebas que demuestren la veracidad de las primitivas soportadas, como las transiciones de estado válidas para los jugadores de un juego.
+
+Por otro lado, los ZK rollups de propósito general admiten una gama más amplia de transacciones y cálculos. Estos rollups utilizan una máquina virtual (VM) para ejecutar código ensamblador y, a continuación, generan una prueba para demostrar que la ejecución se ha realizado correctamente de acuerdo con las especificaciones de la VM. La máquina virtual concreta que utiliza un ZK rollup para sus cálculos varía en función de los proyectos de ZK rollup que existen. Algunos proyectos optan por construir su propia máquina virtual, optimizada para la generación rápida de pruebas. Otros proyectos optan por utilizar la EVM, para una compatibilidad óptima con el ecosistema Ethereum.
+
+Scroll es un ZK rollup de propósito general que utiliza la EVM para cálculos fuera de la cadena. La capa de ejecución de Scroll funciona de forma similar a la de Ethereum: las transacciones se agrupan en bloques y, a continuación, los bloques se ejecutan de acuerdo con las especificaciones [EVM](https://ethereum.org/en/developers/docs/evm/) (en realidad utilizamos una versión ligeramente [modificada](https://github.com/scroll-tech/go-ethereum) de [Geth](https://geth.ethereum.org/)). Esto significa que los usuarios pueden interactuar con Scroll del mismo modo que lo harían con Ethereum. También significa que los desarrolladores pueden trabajar con Scroll del mismo modo que lo harían con Ethereum.
+
+Sin embargo, lograr la compatibilidad de Ethereum con un ZK rollup plantea un gran reto: el rollup debe ser capaz de generar una prueba que demuestre que un cálculo EVM fuera de la cadena se ha ejecutado correctamente. Esto es esencialmente lo que es un "zkEVM": **una zkEVM es un sistema que comprueba la correcta ejecución de la EVM**.
+
+La EVM se diseñó originalmente sin tener en cuenta los ZK rollups, y resulta que es todo un reto construir una zkEVM. Sin embargo, en Scroll no nos dejamos intimidar por el reto y hemos estado trabajando duro en colaboración con el equipo [Ethereum Privacy and Scaling Explorations](https://appliedzkp.org/) para hacer realidad la zkEVM.
+
+## Aprende Más
+
+- [Blog post](https://scroll.io/blog/zkEVM) de la presentación de la zkEVM
+- [Visión general de la zkEVM](https://youtu.be/NHwd-gJ8xg4) - Haichen Shen
diff --git a/src/content/docs/es/technology/zkevm/zkevm-overview.mdx b/src/content/docs/es/technology/zkevm/zkevm-overview.mdx
new file mode 100644
index 000000000..30eaeff77
--- /dev/null
+++ b/src/content/docs/es/technology/zkevm/zkevm-overview.mdx
@@ -0,0 +1,56 @@
+---
+section: technology
+date: Last Modified
+title: "Vista General de la zkEVM"
+lang: "es"
+permalink: "technology/zkevm-overview"
+excerpt: "Para entender cómo se construye una zkEVM, que prueba la ejecución del EVM, primero tenemos que ver la propia EVM."
+---
+
+import ClickToZoom from "../../../../../components/ClickToZoom.astro"
+import zkevm1 from "../_images/zkevm1.png"
+import zkevm2 from "../_images/zkevm2.png"
+import zkevm3 from "../_images/zkevm3.png"
+
+## La EVM
+
+Para entender cómo construir una zkEVM, que demuestre la ejecución del EVM, primero tenemos que ver la propia EVM.
+
+La EVM puede modelarse como una función de transición de estados. Esta especifica una función de transición `f` que, dado un estado inicial del sistema `S` y una transacción `T`, produce un nuevo estado del sistema `S'`: `f(S,T) = S'`.
+
+El "estado del sistema" se modela como un [Merkle-Patricia Trie modificado](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) (MPT). Este trie contiene todos los datos permanentes de la red. Esto incluye la información de todas las cuentas de propiedad externa (EOAs) y las cuentas de los smart contracts. Las cuentas de smart contracts tienen sub-tries que contienen el bytecode del smart contract y el almacenamiento permanente.
+
+La EVM procesa una nueva transacción ejecutando los cálculos resultantes y realizando los cambios correspondientes en el estado del sistema. Los cálculos de la EVM funcionan sobre almacenes de datos transitorios (pila y memoria), así como sobre almacenes de datos persistentes (bytecode y almacenamiento del contrato).
+
+<ClickToZoom src={zkevm1} />
+
+El cálculo activado por una transacción individual se descompone en pequeñas instrucciones de máquina denominadas "opcodes", que la EVM puede comprender y ejecutar directamente. El comportamiento de cada opcode se especifica en el [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf). Por lo tanto, la ejecución de una transacción puede resumirse en una "traza de ejecución", que no es más que una lista ordenada de ejecuciones de opcodes. Los clientes de ejecución de Ethereum, como [Geth](https://geth.ethereum.org/), pueden mostrar explícitamente una traza de ejecución paso a paso del cálculo que han realizado.
+
+<ClickToZoom src={zkevm2} />
+
+A medida que se ejecutan los opcodes, se altera el trie de estado. El resultado es un nuevo trie de estado, con una nueva raíz de estado.
+
+## Prueba de la ejecución de una EVM
+
+El objetivo de una zkEVM es generar una prueba que certifique la validez de la ejecución de una transacción. En otras palabras, dado un estado inicial del sistema `S`, una transacción `T`, y un estado resultante del sistema `S'`, la zkEVM debe generar una prueba de que `f(S,T) = S'`, donde `f` es la función de transición de estado especificada en el Ethereum Yellow Paper.
+
+Para demostrar la validez de la ejecución de la función de transición, descomponemos la ejecución en su traza de ejecución paso a paso. La ejecución de `f(S,T)` se expande en una lista de sus ejecuciones secuenciales de opcodes. La traza de ejecución sirve como "testigo (o "witness")" de la corrección de la transición de estado `f(S,T) = S'` - la traza es en cierto sentido una explicación paso a paso de cómo el estado pasa de `S` a `S'`.
+
+El problema se reduce entonces a demostrar lo siguiente:
+
+- La traza de ejecución es _correcta_.
+  - Cada opcode individual se ejecuta correctamente según la especificación del Ethereum Yellow Paper.
+- Por ejemplo, el opcode `ADD` debe resultar en sacar dos valores de la pila, y colocar su suma en la pila.
+- Una prueba debe mostrar que cada opcode fue ejecutado con el comportamiento adecuado, incluyendo cualquier alteración a los almacenes de datos transitorios (pila y memoria) o almacenes de datos permanentes (bytecode del contrato y almacenamiento).
+  - La lista ordenada de opcodes que se ejecutan es de hecho la lista correcta de opcodes activados por la transacción.
+    - Esto incluye cargar correctamente el calldata inicial de la transacción, y el bytecode de cualquier contrato invocado.
+- La traza de ejecución comienza con el estado inicial `S` y termina en el estado `S'`.
+
+<ClickToZoom src={zkevm3} />
+
+En secciones posteriores, nos adentraremos en los detalles de cómo puede demostrarse la corrección de las trazas de ejecución de la EVM.
+
+## Aprende Más
+
+- "Cypherpunks" [capítulo de GitBook](https://cypherpunks-core.github.io/ethereumbook/13evm.html) sobre la EVM
+- [Visión general de zkEVM](https://youtu.be/NHwd-gJ8xg4) - Haichen Shen
diff --git a/src/content/docs/es/user-guide/_images/bridge1.png b/src/content/docs/es/user-guide/_images/bridge1.png
new file mode 100644
index 000000000..dd552310e
Binary files /dev/null and b/src/content/docs/es/user-guide/_images/bridge1.png differ
diff --git a/src/content/docs/es/user-guide/_images/bridge2.png b/src/content/docs/es/user-guide/_images/bridge2.png
new file mode 100644
index 000000000..e3fe4701f
Binary files /dev/null and b/src/content/docs/es/user-guide/_images/bridge2.png differ
diff --git a/src/content/docs/es/user-guide/_images/bridge3.png b/src/content/docs/es/user-guide/_images/bridge3.png
new file mode 100644
index 000000000..03772fee9
Binary files /dev/null and b/src/content/docs/es/user-guide/_images/bridge3.png differ
diff --git a/src/content/docs/es/user-guide/_images/bridge4.png b/src/content/docs/es/user-guide/_images/bridge4.png
new file mode 100644
index 000000000..a060b2ce3
Binary files /dev/null and b/src/content/docs/es/user-guide/_images/bridge4.png differ
diff --git a/src/content/docs/es/user-guide/_images/bridge5.png b/src/content/docs/es/user-guide/_images/bridge5.png
new file mode 100644
index 000000000..7e75aeb4d
Binary files /dev/null and b/src/content/docs/es/user-guide/_images/bridge5.png differ
diff --git a/src/content/docs/es/user-guide/_images/bridge6.png b/src/content/docs/es/user-guide/_images/bridge6.png
new file mode 100644
index 000000000..80066a330
Binary files /dev/null and b/src/content/docs/es/user-guide/_images/bridge6.png differ
diff --git a/src/content/docs/es/user-guide/_images/bridge7.png b/src/content/docs/es/user-guide/_images/bridge7.png
new file mode 100644
index 000000000..66ee3ff94
Binary files /dev/null and b/src/content/docs/es/user-guide/_images/bridge7.png differ
diff --git a/src/content/docs/es/user-guide/_images/bridge8.png b/src/content/docs/es/user-guide/_images/bridge8.png
new file mode 100644
index 000000000..4b78a8b9e
Binary files /dev/null and b/src/content/docs/es/user-guide/_images/bridge8.png differ
diff --git a/src/content/docs/es/user-guide/bridge.mdx b/src/content/docs/es/user-guide/bridge.mdx
new file mode 100644
index 000000000..9aa0b7f42
--- /dev/null
+++ b/src/content/docs/es/user-guide/bridge.mdx
@@ -0,0 +1,126 @@
+---
+section: gettingStarted
+date: Last Modified
+title: "Bridge"
+lang: "es"
+permalink: "user-guide/bridge/"
+excerpt: "Para empezar a transferir activos desde Sepolia, navegue hasta el portal del bridge."
+---
+
+{/* // import ClickToZoom from "../../../../components/ClickToZoom.astro" */}
+{/* // import bridge1 from "./\_images/bridge1.png" */}
+{/* // import bridge2 from "./\_images/bridge2.png" */}
+{/* // import bridge3 from "./\_images/bridge3.png" */}
+{/* // import bridge4 from "./\_images/bridge4.png" */}
+{/* // import bridge5 from "./\_images/bridge5.png" */}
+{/* // import bridge6 from "./\_images/bridge6.png" */}
+{/* // import bridge7 from "./\_images/bridge7.png" */}
+{/* // import bridge8 from "./\_images/bridge8.png" */}
+
+{/* TODO: Update all instructions after being able to walk through the whole flow. */}
+
+Visita nuestro [Bridge](https://scroll.io/bridge) para empezar. [^thanks-hop] El Bridge admite operaciones de **depósito** y **retirada**, lo que permite a los usuarios mover activos de Sepolia Testnet a Scroll Sepolia Testnet con total confianza.
+[^thanks-hop]: Un fork de la IU de [Hop Exchange]('https://hop.exchange/') 🙌.
+
+Los depósitos pueden tardar hasta 15 minutos en estar disponibles en Scroll.
+
+Los retiros, que requieren una segunda interacción en Sepolia una vez finalizada la retirada, pueden tardar mucho más.
+
+:::caution[¿Esperando mucho tiempo para una transacción del bridge?]
+Las estimaciones de tiempo anteriores son típicas para el comportamiento normal de la red y los niveles de actividad. Dado que sólo procesamos un número determinado de transacciones de L1 en cola por bloque L2, los mensajes en el bridge pueden tardar más en incluirse en Scroll en momentos de uso excesivo de la red.
+:::
+
+## Depósito de Sepolia a Scroll Sepolia
+
+### Instrucciones
+
+1. En primer lugar, navegue hasta el [Scroll Bridge](https://scroll.io/bridge) y pulse el botón "Connect Wallet".
+1. En la app, asegúrate de que **Ethereum Sepolia** está arriba y **Scroll Sepolia** abajo. Puedes pulsar el botón "**↓**" para cambiar sus posiciones.
+1. Selecciona el token que quieres transferir de Sepolia a Scroll Sepolia. Si es la primera vez que usas el bridge, prueba con "ETH".
+1. Si es la primera vez que transfieres un token ERC20 específico, debes **Aprobar** el contrato Sepolia Bridge para acceder a tu token ERC20.
+1. A continuación, haz clic en el botón **Enviar a Scroll Sepolia** para realizar el ingreso. Tu billetera te pedirá que confirmes la transacción de transferencia.
+1. Una vez enviada y confirmada la operación de transferencia, el token se deducirá de tu billetera de Sepolia.
+1. Siempre puedes comprobar el estado de una transacción pulsando el icono "Historial" situado junto a la dirección de tu billetera en la esquina superior derecha.
+
+### ¿Cuándo llegarán los tokens a tu billetera de Scroll Sepolia?
+
+Puede tardar entre **8 y 14 minutos** (esperando a que el bloque se vuelva [_Seguro_](https://www.alchemy.com/overviews/ethereum-commitment-levels#what-are-ethereum-commitment-levels) en Sepolia) antes de que el token aparezca en tu billetera de Scroll Sepolia.
+
+{/* You can check the progress of deposit transactions as follows: */}
+
+{/* ##### 1. Click the "History" icon next to your billetera address in the top-right corner. */}
+
+{/* <ClickToZoom src={bridge1} /> */}
+
+{/* The pop-up panel lists the most recent transactions made in the Bridge app. There are two statuses: Sepolia status and Scroll Sepolia status. For deposit transactions (L1 -> L2), once your transaction becomes _Safe_ on Sepolia (**8 to 14 minutes**), you will see the **`success`** status shown. Your funds will be relayed to Scoll Sepolia after this. */}
+
+{/* The Recent Bridge Transactions window should give you an estimate of the time expected before your transaction is _Safe_ on Sepolia. */}
+
+{/* ##### 2. Click on the most recent transaction’s Sepolia transaction hash. */}
+
+{/* <ClickToZoom src={bridge2} /> */}
+
+{/* It will open the Transaction Details page in a new tab. You can see this transaction is confirmed on Sepolia. To check the Block's confirmation status, click the Block number and read the "Status" field. */}
+
+{/* <ClickToZoom src={bridge3} /> */}
+
+{/* ##### 3. Return to the Bridge app and wait! */}
+
+{/* Once your transaction status shows **`success`** on Scroll Sepolia, you should see the funds in your Scroll L2 wallet and a transaction hash: */}
+
+{/* <ClickToZoom src={bridge4} /> */}
+
+## Retiro de Scroll Sepolia a Sepolia
+
+### Instrucciones
+
+#### Envío de la primera transacción de retiro de fondos
+
+1. Primero, cambia a la red **Scroll Sepolia** en tu billetera.
+1. En la app, asegúrate de que **Scroll Sepolia** está arriba y **Ethereum Sepolia** abajo. Puedes pulsar el botón "**↓**" para cambiar las posiciones.
+1. Selecciona el token que quieres transferir de **Scroll Sepolia** a **Sepolia**. Si es la primera vez que usas el bridge, prueba con "ETH".
+1. Si es la primera vez que transfieres un token ERC20 específico, debes **Aprobar** el contrato Scroll Sepolia Bridge para acceder a tus tokens ERC20.
+1. A continuación, haz clic en el botón **Enviar a Ethereum Sepolia** para realizar la retirada. Tu billetera te pedirá que confirmes la transacción de transferencia.
+1. Una vez enviada y confirmada la operación de transferencia, el token se deducirá de tu billetera de Scroll Sepolia.
+
+#### Envío de una transacción de retiro de fondos
+
+{/* TODO: finish the additional instructions, better estimate "wait time" */}
+
+_Los pasos restantes tienen lugar en Scroll Sepolia, pero primero debes esperar a que tu transacción esté completamente probada ("finalizada") en Ethereum Sepolia. Este proceso puede durar hasta cuatro horas._
+
+1. Cuando tu transacción de retirada haya finalizado en Ethereum Sepolia, verá que el botón "Claim" en el área de Transacciones Recientes se vuelve sólido.
+1. Haz clic en el botón "Claim" para enviar la ejecución de la transacción de retiro de fondos.
+1. Una vez enviado, los fondos retirados deberían aparecer inmediatamente en tu billetera de Sepolia.
+
+### ¿Cuándo llegará el token a tu billetera Sepolia?
+
+El token transferido llegará a tu billetera de Sepolia inmediatamente después de que el bloque que contiene la ejecución de la transacción de retirada se confirme en Sepolia.
+
+{/* TODO: check architecture link is live */}
+
+:::tip[Estatus del Rollup]
+El estado de rollup `Finalizado` indica que se ha comprobado la correcta ejecución de las transacciones de este bloque mediante la verificación de una prueba de validez on-chain en Sepolia. Para más información sobre el estado de rollup, véase [Visión general de la arquitectura de Scroll](/es/technology).
+:::
+
+{/* You can check the progress of withdrawal transactions as follows: */}
+
+{/* 1. Click your wallet address at the top-right corner of the Bridge web app. */}
+
+{/* <ClickToZoom src={bridge5} /> */}
+
+{/* The pop-up panel lists the most recent transactions you made in the Bridge app (see the image below). There are two statuses: L1 status and L2 status. In this case, because we are bridging from L2 -> L1, we will quickly get a **`success`** status after submitting the transaction to the L2 Bridge. L1, on the other hand, takes **10 minutes to a few hours** to reach **`success`**. */}
+
+{/* 1. Click on the most recent transaction’s L2 transaction hash: */}
+
+{/* <ClickToZoom src={bridge6} /> */}
+
+{/* It will open the _Transaction Details_ page in a new tab. You can see this transaction is confirmed on L2. */}
+
+{/* <ClickToZoom src={bridge7} /> */}
+
+{/* The transaction is confirmed on L2, but still needs to be finalized on Goerli. */}
+
+{/* 1. Go back to the [Bridge](https://scroll.io/bridge) app. It takes about 10 minutes before the token shows up in your Goerli wallet. Once your transaction status shows success on L2, you should see the funds in your Goerli wallet and a transaction hash: */}
+
+{/* <ClickToZoom src={bridge8} /> */}
diff --git a/src/content/docs/es/user-guide/common-errors.mdx b/src/content/docs/es/user-guide/common-errors.mdx
new file mode 100644
index 000000000..d27a04ca1
--- /dev/null
+++ b/src/content/docs/es/user-guide/common-errors.mdx
@@ -0,0 +1,41 @@
+---
+section: gettingStarted
+date: Last Modified
+title: "Errores Comunes"
+lang: "es"
+permalink: "user-guide/common-errors/"
+excerpt: "¿Ve un error cuando intenta interactuar con Scroll Sepolia Testnet? Aquí hay algunos errores comunes de configuración y cómo solucionarlos rápidamente."
+---
+
+## Error de nonce incorrecto al enviar una transacción en MetaMask
+
+Encontrarás este error cuando el nonce local almacenado en tu wallet MetaMask sea diferente del nonce en el nodo Scroll testnet. Podría deberse a que hay una transacción pendiente reciente.
+
+Para solucionar este problema, es necesario restablecer su cuenta en MetaMask para el Scroll Sepolia Testnet. Los pasos para restablecer la cuenta son:
+
+1. Abre la extensión **MetaMask** en el navegador
+2. Selecciona **Scroll Sepolia Testnet** en el área superior
+3. Haz clic en el **icono de la cuenta** redondo en la esquina superior derecha
+4. Selecciona **Configuración**
+5. Vé a **Avanzado**.
+6. Haz clic en **Borrar datos de la pestaña de actividad**.
+
+No perderás ningún activo durante el reinicio de la cuenta MetaMask.
+
+:::caution[Precaución]
+Eliminar y volver a añadir una red NO es suficiente para solucionarlo, debes restablecer tu cuenta.
+:::
+
+## No ocurre nada al confirmar una transacción bridging/swapping
+
+Si no aparece ningún error o registro de consola, es probable que se deba a un problema de nonce, por favor, reinicie su cuenta MetaMask como se indica más [arriba](/es/user-guide/common-errors#error-de-nonce-incorrecto-al-enviar-una-transacción-en-metamask).
+
+## Block Explorer muestra "Internal server error".
+
+Utiliza una ventana de incógnito o abre la "Developer Console" de tu navegador y elimina la cookie `_explorer_key` (o todas las cookies). [Consulta esta guía para saber cómo eliminar las cookies](https://www.contentstack.com/docs/developers/how-to-guides/clear-caches-and-cookies-in-different-browsers/).
+
+## Al enviar la cantidad máxima de ETH en MetaMask se produce un error "Failed".
+
+Cuando envías ETH usando MetaMask, si intentas enviar la cantidad "Max", y resulta en un error "Failed". Esto se debe a que MetaMask no tiene en cuenta la "Comisión L1" adicional que tienen los rollups además de la comisión normal por el gas, por ello, se queda corto en una pequeña cantidad necesaria para pagar el gas de la transacción.
+
+Para solucionar esto, baje manualmente la cantidad de ETH para que sea un poco menor que la sugerida y la transacción se realizará.
diff --git a/src/content/docs/es/user-guide/faucet.mdx b/src/content/docs/es/user-guide/faucet.mdx
new file mode 100644
index 000000000..b69159d13
--- /dev/null
+++ b/src/content/docs/es/user-guide/faucet.mdx
@@ -0,0 +1,37 @@
+---
+section: gettingStarted
+date: Last Modified
+title: "Faucet"
+lang: "es"
+permalink: "user-guide/faucet/"
+whatsnext: { "Pasa tu ETH a Scroll Sepolia": "/es/user-guide/bridge" }
+excerpt: "Para interactuar con nuestra testnet, primero necesitas adquirir Sepolia ETH. Hay algunas aplicaciones de faucets de Sepolia para empezar."
+---
+
+Para interactuar con nuestra testnet, primero necesitas recibir ETH de la _Sepolia Testnet_. Luego puedes usar un bridge de _Sepolia Testnet_ a _Scroll Sepolia Testnet_.
+
+## Faucets de Sepolia
+
+Cada faucet tiene sus propias reglas y requisitos, por lo que es posible que tengas que probar unos cuantos antes de encontrar uno que funcione para ti.
+
+Aquí tienes algunos faucets de Sepolia:
+
+- [https://sepoliafaucet.com](https://sepoliafaucet.com//)
+- [https://sepolia-faucet.pk910.de](https://sepolia-faucet.pk910.de/)
+- [https://faucet.quicknode.com/drip](https://faucet.quicknode.com/drip)
+- [https://faucet.chainstack.com](https://faucet.chainstack.com)
+
+Una vez que recibas ETH en Sepolia, deberías verlos en tu wallet en la _Red Sepolia_. Pueden tardar unos segundos en aparecer, pero puedes comprobar el estado buscando una transacción a tu dirección en un [Explorador de bloques de Sepolia](https://sepolia.etherscan.io/).
+
+:::note[¡No te apresures!]
+La mayoría de los faucets sólo permiten solicitar tokens de prueba una vez cada 24 horas.
+:::
+
+## Faucets de Scroll Sepolia
+
+Si no quieres interactuar con el bridge, algunos faucets distribuyen ETH directamente a Scroll Sepolia . -->
+
+- [https://scroll.l2scan.co/faucet](https://scroll.l2scan.co/faucet)
+- [https://www.covalenthq.com/faucet/](https://www.covalenthq.com/faucet/)
+- [https://faucet.quicknode.com/scroll/sepolia](https://faucet.quicknode.com/scroll/sepolia)
+  {/* - [https://bwarelabs.com/faucets/scroll-testnet](https://bwarelabs.com/faucets/scroll-testnet) */}
diff --git a/src/content/docs/es/user-guide/index.md b/src/content/docs/es/user-guide/index.md
new file mode 100644
index 000000000..f11ff9c63
--- /dev/null
+++ b/src/content/docs/es/user-guide/index.md
@@ -0,0 +1,36 @@
+---
+section: gettingStarted
+date: Last Modified
+title: "Guía de Usuario de Scroll Sepolia"
+lang: "es"
+permalink: "user-guide/"
+excerpt: "Gracias por probar nuestra Scroll Sepolia Testnet. La Sepolia Testnet está formada por la Sepolia Testnet de Ethereum y la red de pruebas Scroll Sepolia."
+whatsnext: { "Configuración de Wallet": "/es/user-guide/setup" }
+---
+
+Gracias por probar la Scroll Sepolia Testnet. Si tienes preguntas o quieres darnos tu opinión, ¡únete a nuestro [Discord](https://discord.gg/scroll)!
+
+Sepolia Testnet está formada por _Ethereum's Sepolia Testnet_ y la red de pruebas _Scroll Sepolia_. Sepolia es una red de pruebas de Ethereum, mientras que Scroll Sepolia es una zero-knowledge rollup testnet desplegada sobre la primera. Existen algunas aplicaciones demo predesplegadas: un [bridge](https://scroll.io/bridge) entre _Sepolia_ y _Scroll Sepolia_,[^1] un [block explorer](https://sepolia-blockscout.scroll.io/) para _Scroll Sepolia_,[^2] y un [rollup explorer](https://scroll.io/rollupscan).
+
+Para ver las transacciones en L1, echa un vistazo al [Sepolia explorer](https://sepolia.etherscan.io/) de Etherscan.
+Para ver las transacciones en L2, puedes usar el explorador de bloques de Scroll, pero también puedes probar la funcionalidad adicional proporcionada por [Dora](https://www.ondora.xyz/network/scroll-sepolia/interactions) o [L2Scan](https://scroll.l2scan.co/).
+
+Este es el flujo de trabajo sugerido para explorar la Testnet:
+
+1. Añade las configuraciones de [Sepolia Testnet](https://scroll.io/portal) a tu wallet.
+2. Solicita tokens de prueba en la red _Sepolia_ desde cualquier aplicación de Ethereum Faucet. (véase el artículo [Faucet](/es/user-guide/faucet)).
+3. Transfiere tokens de prueba de _Sepolia_ a _Scroll Sepolia_ a través del [Bridge](https://scroll.io/bridge).
+4. Transfiere tokens a otras wallets en _Scroll Sepolia_ utilizando tu wallet.
+5. Explora nuestro ecosistema, interactuando con contratos como [Uniswap](http://uniswap-showcase.sepolia.scroll.xyz/).
+6. Retira tokens de _Scroll Sepolia_ a _Sepolia_ a través del [Bridge](https://scroll.io/bridge).
+
+Encontrarás las instrucciones de cada aplicación en el resto de esta guía del usuario.
+
+<!-- TODO: Add Aave back in item number 5 once live. -->
+
+## Preguntas y Feedback
+
+Si tienes algún problema, únete a nuestro [Discord](https://discord.gg/scroll) y habla con nosotros en el canal `#general-support`. También nos encantaría conocer tus opiniones o comentarios sobre cómo podemos mejorar tu experiencia.
+
+[^1]: Un fork de la IU de [Hop Exchange](https://hop.exchange/) 🐇🙌.
+[^2]: Usando el gran explorador de bloques de código abierto de [Blockscout](https://blockscout.com/)
diff --git a/src/content/docs/es/user-guide/setup.mdx b/src/content/docs/es/user-guide/setup.mdx
new file mode 100644
index 000000000..69e4e9639
--- /dev/null
+++ b/src/content/docs/es/user-guide/setup.mdx
@@ -0,0 +1,41 @@
+---
+section: gettingStarted
+date: Last Modified
+title: "Configuración"
+lang: "es"
+permalink: "user-guide/setup/"
+whatsnext: { "Obten ETH de Sepolia ETH desde un Faucet": "/es/user-guide/faucet" }
+excerpt: "Necesitas tener un wallet para interactuar con la Scroll Testnet. Puedes encontrar algunas wallets de ejemplo y consejos de configuración aquí."
+---
+
+import Aside from "../../../../components/Aside.astro"
+
+## Wallet
+
+Necesitas tener una wallet para interactuar con las dApps en la Scroll Sepolia testnet. Puedes encontrar algunos ejemplos de wallets y consejos de configuración más abajo. Nuestra aplicación Bridge es compatible con MetaMask, Coinbase Wallet o cualquier otra wallet compatible con WalletConnect.
+
+### MetaMask
+
+Puedes instalar MetaMask desde su [sitio web oficial](https://metamask.io/download/).
+
+Puedes importar las configuraciones de la Scroll Sepolia testnet a tu wallet de MetaMask. Para ello, visita el [portal de Scroll Sepolia](https://scroll.io/portal), luego haz clic en el botón "Connect Wallet" y selecciona MetaMask. A continuación, haz clic en los botones "Add to MetaMask" para Sepolia Testnet y Scroll Sepolia Testnet. Esto importará el identificador de cadena y las URL RPC para el Scroll Sepolia Testnet. La Sepolia Testnet también está configurada por defecto en MetaMask. Para mostrarla, haz clic en "Mostrar/ocultar redes de prueba" en el menú desplegable de selección de redes de MetaMask.
+
+### Configuración manual de la red (para otras wallets)
+
+Los links **Add to wallet** pueden no ser compatibles con todos las wallets. Si tiene problemas para utilizarlos, puede que necesite añadir manualmente la red _Sepolia Testnet_ y _Scroll Sepolia_ introduciendo los detalles de configuración de la tabla siguiente:
+
+| Nombre de la Red       | Scroll Sepolia Testnet                                                        | Sepolia Testnet                                                              |
+| ------------------ | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
+| RPC URL            | [https://sepolia-rpc.scroll.io/](https://sepolia-rpc.scroll.io/)              | [https://eth-sepolia-public.unifra.io](https://eth-sepolia-public.unifra.io) |
+| Chain ID           | 534351                                                                        | 11155111                                                                     |
+| Currency Symbol    | ETH                                                                           | ETH                                                                          |
+| Block Explorer URL | [https://sepolia-blockscout.scroll.io](https://sepolia-blockscout.scroll.io/) | [https://sepolia.etherscan.io](https://sepolia.etherscan.io)                 |
+
+<Aside type="tip" title="Exploradores de bloques adicionales">
+  Para ver la actividad en la Capa 1, utiliza [Sepolia Testnet Explorer](https://sepolia.etherscan.io) de Etherscan.
+
+Para una experiencia de exploración de bloques alternativa, Unifra ha construido [L2Scan](https://scroll.l2scan.co/), que permite a los usuarios
+explorar otros aspectos del Scroll Sepolia Testnet.
+[Dora](https://www.ondora.xyz/network/scroll-sepolia/interactions) también es compatible con Scroll Sepolia y ofrece una visión multi-chain de la actividad de la blockchain.
+
+</Aside>
diff --git a/src/content/docs/es/user-guide/transfer-tokens.md b/src/content/docs/es/user-guide/transfer-tokens.md
new file mode 100644
index 000000000..0b1c76361
--- /dev/null
+++ b/src/content/docs/es/user-guide/transfer-tokens.md
@@ -0,0 +1,18 @@
+---
+section: gettingStarted
+date: Last Modified
+title: "Transferencia de Tokens"
+lang: "es"
+permalink: "user-guide/transfer-tokens/"
+excerpt: "Puede utilizar su wallet como de costumbre para transferir tokens dentro de la Scroll Sepolia Testnet."
+---
+
+Puedes utilizar la funcionalidad normal de tu wallet para transferir tokens dentro de la Testnet de Scroll Sepolia -- no es necesaria ninguna configuración adicional.
+
+## Envío de un token en MetaMask
+
+1. Abre tu wallet y cambia a **Scroll Sepolia Testnet**.
+2. Haz clic en el botón **Enviar** del centro y escribe la dirección a la que deseas transferir en el cuadro de texto.
+3. Selecciona el token en la casilla **Activo** y escribe la cantidad de tokens que quieres transferir.
+4. Pulsa el botón **Siguiente** y después pulsa el botón **Confirmar** para enviar la transacción.
+5. Después del envío, puedes encontrar la transacción en la pestaña **Actividad** de tu wallet.