diff --git a/i18n/fr/code.json b/i18n/fr/code.json
new file mode 100644
index 000000000..6f8e0f86c
--- /dev/null
+++ b/i18n/fr/code.json
@@ -0,0 +1,404 @@
+{
+ "theme.ErrorPageContent.title": {
+ "message": "Cette page a planté.",
+ "description": "The title of the fallback page when the page crashed"
+ },
+ "theme.NotFound.title": {
+ "message": "Page introuvable",
+ "description": "The title of the 404 page"
+ },
+ "theme.NotFound.p1": {
+ "message": "Nous n'avons pas trouvé ce que vous recherchez.",
+ "description": "The first paragraph of the 404 page"
+ },
+ "theme.NotFound.p2": {
+ "message": "Veuillez contacter le propriétaire du site qui vous a lié à l'URL d'origine et leur faire savoir que leur lien est cassé.",
+ "description": "The 2nd paragraph of the 404 page"
+ },
+ "theme.admonition.note": {
+ "message": "remarque",
+ "description": "The default label used for the Note admonition (:::note)"
+ },
+ "theme.admonition.tip": {
+ "message": "astuce",
+ "description": "The default label used for the Tip admonition (:::tip)"
+ },
+ "theme.admonition.danger": {
+ "message": "danger",
+ "description": "The default label used for the Danger admonition (:::danger)"
+ },
+ "theme.admonition.info": {
+ "message": "info",
+ "description": "The default label used for the Info admonition (:::info)"
+ },
+ "theme.admonition.caution": {
+ "message": "attention",
+ "description": "The default label used for the Caution admonition (:::caution)"
+ },
+ "theme.BackToTopButton.buttonAriaLabel": {
+ "message": "Retour au début de la page",
+ "description": "The ARIA label for the back to top button"
+ },
+ "theme.blog.archive.title": {
+ "message": "Archive",
+ "description": "The page & hero title of the blog archive page"
+ },
+ "theme.blog.archive.description": {
+ "message": "Archive",
+ "description": "The page & hero description of the blog archive page"
+ },
+ "theme.blog.paginator.navAriaLabel": {
+ "message": "Pagination de la liste des articles du blog",
+ "description": "The ARIA label for the blog pagination"
+ },
+ "theme.blog.paginator.newerEntries": {
+ "message": "Nouvelles entrées",
+ "description": "The label used to navigate to the newer blog posts page (previous page)"
+ },
+ "theme.blog.paginator.olderEntries": {
+ "message": "Anciennes entrées",
+ "description": "The label used to navigate to the older blog posts page (next page)"
+ },
+ "theme.blog.post.paginator.navAriaLabel": {
+ "message": "Pagination des articles du blog",
+ "description": "The ARIA label for the blog posts pagination"
+ },
+ "theme.blog.post.paginator.newerPost": {
+ "message": "Article plus récent",
+ "description": "The blog post button label to navigate to the newer/previous post"
+ },
+ "theme.blog.post.paginator.olderPost": {
+ "message": "Article plus ancien",
+ "description": "The blog post button label to navigate to the older/next post"
+ },
+ "theme.blog.post.plurals": {
+ "message": "Un article|{count} articles",
+ "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
+ },
+ "theme.blog.tagTitle": {
+ "message": "{nPosts} tagués avec « {tagName} »",
+ "description": "The title of the page for a blog tag"
+ },
+ "theme.tags.tagsPageLink": {
+ "message": "Voir tous les tags",
+ "description": "The label of the link targeting the tag list page"
+ },
+ "theme.colorToggle.ariaLabel": {
+ "message": "Basculer entre le mode sombre et clair (actuellement {mode})",
+ "description": "The ARIA label for the navbar color mode toggle"
+ },
+ "theme.colorToggle.ariaLabel.mode.dark": {
+ "message": "mode sombre",
+ "description": "The name for the dark color mode"
+ },
+ "theme.colorToggle.ariaLabel.mode.light": {
+ "message": "mode clair",
+ "description": "The name for the light color mode"
+ },
+ "theme.docs.breadcrumbs.navAriaLabel": {
+ "message": "Fil d'Ariane",
+ "description": "The ARIA label for the breadcrumbs"
+ },
+ "theme.docs.DocCard.categoryDescription": {
+ "message": "{count} éléments",
+ "description": "The default description for a category card in the generated index about how many items this category includes"
+ },
+ "theme.docs.paginator.navAriaLabel": {
+ "message": "Pagination des documents",
+ "description": "The ARIA label for the docs pagination"
+ },
+ "theme.docs.paginator.previous": {
+ "message": "Précédent",
+ "description": "The label used to navigate to the previous doc"
+ },
+ "theme.docs.paginator.next": {
+ "message": "Suivant",
+ "description": "The label used to navigate to the next doc"
+ },
+ "theme.docs.tagDocListPageTitle.nDocsTagged": {
+ "message": "Un document tagué|{count} documents tagués",
+ "description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
+ },
+ "theme.docs.tagDocListPageTitle": {
+ "message": "{nDocsTagged} avec \"{tagName}\"",
+ "description": "The title of the page for a docs tag"
+ },
+ "theme.docs.versionBadge.label": {
+ "message": "Version: {versionLabel}"
+ },
+ "theme.docs.versions.unreleasedVersionLabel": {
+ "message": "Ceci est la documentation de la prochaine version {versionLabel} de {siteTitle}.",
+ "description": "The label used to tell the user that he's browsing an unreleased doc version"
+ },
+ "theme.docs.versions.unmaintainedVersionLabel": {
+ "message": "Ceci est la documentation de {siteTitle} {versionLabel}, qui n'est plus activement maintenue.",
+ "description": "The label used to tell the user that he's browsing an unmaintained doc version"
+ },
+ "theme.docs.versions.latestVersionSuggestionLabel": {
+ "message": "Pour une documentation à jour, consultez la {latestVersionLink} ({versionLabel}).",
+ "description": "The label used to tell the user to check the latest version"
+ },
+ "theme.docs.versions.latestVersionLinkLabel": {
+ "message": "dernière version",
+ "description": "The label used for the latest version suggestion link label"
+ },
+ "theme.common.editThisPage": {
+ "message": "Éditer cette page",
+ "description": "The link label to edit the current page"
+ },
+ "theme.common.headingLinkTitle": {
+ "message": "Lien direct vers {heading}",
+ "description": "Title for link to heading"
+ },
+ "theme.lastUpdated.atDate": {
+ "message": " le {date}",
+ "description": "The words used to describe on which date a page has been last updated"
+ },
+ "theme.lastUpdated.byUser": {
+ "message": " par {user}",
+ "description": "The words used to describe by who the page has been last updated"
+ },
+ "theme.lastUpdated.lastUpdatedAtBy": {
+ "message": "Dernière mise à jour{atDate}{byUser}",
+ "description": "The sentence used to display when a page has been last updated, and by who"
+ },
+ "theme.navbar.mobileVersionsDropdown.label": {
+ "message": "Versions",
+ "description": "The label for the navbar versions dropdown on mobile view"
+ },
+ "theme.tags.tagsListLabel": {
+ "message": "Tags :",
+ "description": "The label alongside a tag list"
+ },
+ "theme.AnnouncementBar.closeButtonAriaLabel": {
+ "message": "Fermer",
+ "description": "The ARIA label for close button of announcement bar"
+ },
+ "theme.blog.sidebar.navAriaLabel": {
+ "message": "Navigation article de blog récent",
+ "description": "The ARIA label for recent posts in the blog sidebar"
+ },
+ "theme.CodeBlock.copied": {
+ "message": "Copié",
+ "description": "The copied button label on code blocks"
+ },
+ "theme.CodeBlock.copyButtonAriaLabel": {
+ "message": "Copier le code",
+ "description": "The ARIA label for copy code blocks button"
+ },
+ "theme.CodeBlock.copy": {
+ "message": "Copier",
+ "description": "The copy button label on code blocks"
+ },
+ "theme.CodeBlock.wordWrapToggle": {
+ "message": "Activer/désactiver le retour à la ligne",
+ "description": "The title attribute for toggle word wrapping button of code block lines"
+ },
+ "theme.DocSidebarItem.toggleCollapsedCategoryAriaLabel": {
+ "message": "Plier/Déplier la catégorie '{label}' de la barre latérale",
+ "description": "The ARIA label to toggle the collapsible sidebar category"
+ },
+ "theme.NavBar.navAriaLabel": {
+ "message": "Main",
+ "description": "The ARIA label for the main navigation"
+ },
+ "theme.navbar.mobileLanguageDropdown.label": {
+ "message": "Langues",
+ "description": "The label for the mobile language switcher dropdown"
+ },
+ "theme.TOCCollapsible.toggleButtonLabel": {
+ "message": "Sur cette page",
+ "description": "The label used by the button on the collapsible TOC component"
+ },
+ "theme.blog.post.readMore": {
+ "message": "Lire plus",
+ "description": "The label used in blog post item excerpts to link to full blog posts"
+ },
+ "theme.blog.post.readMoreLabel": {
+ "message": "En savoir plus sur {title}",
+ "description": "The ARIA label for the link to full blog posts from excerpts"
+ },
+ "theme.blog.post.readingTime.plurals": {
+ "message": "Une minute de lecture|{readingTime} minutes de lecture",
+ "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
+ },
+ "theme.docs.breadcrumbs.home": {
+ "message": "Page d'accueil",
+ "description": "The ARIA label for the home page in the breadcrumbs"
+ },
+ "theme.docs.sidebar.collapseButtonTitle": {
+ "message": "Réduire le menu latéral",
+ "description": "The title attribute for collapse button of doc sidebar"
+ },
+ "theme.docs.sidebar.collapseButtonAriaLabel": {
+ "message": "Réduire le menu latéral",
+ "description": "The title attribute for collapse button of doc sidebar"
+ },
+ "theme.docs.sidebar.navAriaLabel": {
+ "message": "Docs sidebar",
+ "description": "The ARIA label for the sidebar navigation"
+ },
+ "theme.docs.sidebar.closeSidebarButtonAriaLabel": {
+ "message": "Fermer la barre de navigation",
+ "description": "The ARIA label for close button of mobile sidebar"
+ },
+ "theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": {
+ "message": "← Retour au menu principal",
+ "description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)"
+ },
+ "theme.docs.sidebar.toggleSidebarButtonAriaLabel": {
+ "message": "Ouvrir/fermer la barre de navigation",
+ "description": "The ARIA label for hamburger menu button of mobile navigation"
+ },
+ "theme.docs.sidebar.expandButtonTitle": {
+ "message": "Déplier le menu latéral",
+ "description": "The ARIA label and title attribute for expand button of doc sidebar"
+ },
+ "theme.docs.sidebar.expandButtonAriaLabel": {
+ "message": "Déplier le menu latéral",
+ "description": "The ARIA label and title attribute for expand button of doc sidebar"
+ },
+ "theme.SearchBar.seeAll": {
+ "message": "Voir les {count} résultats"
+ },
+ "theme.SearchPage.documentsFound.plurals": {
+ "message": "Un document trouvé|{count} documents trouvés",
+ "description": "Pluralized label for \"{count} documents found\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
+ },
+ "theme.SearchPage.existingResultsTitle": {
+ "message": "Résultats de recherche pour « {query} »",
+ "description": "The search page title for non-empty query"
+ },
+ "theme.SearchPage.emptyResultsTitle": {
+ "message": "Rechercher dans la documentation",
+ "description": "The search page title for empty query"
+ },
+ "theme.SearchPage.inputPlaceholder": {
+ "message": "Tapez votre recherche ici",
+ "description": "The placeholder for search page input"
+ },
+ "theme.SearchPage.inputLabel": {
+ "message": "Chercher",
+ "description": "The ARIA label for search page input"
+ },
+ "theme.SearchPage.algoliaLabel": {
+ "message": "Recherche par Algolia",
+ "description": "The ARIA label for Algolia mention"
+ },
+ "theme.SearchPage.noResultsText": {
+ "message": "Aucun résultat trouvé",
+ "description": "The paragraph for empty search result"
+ },
+ "theme.SearchPage.fetchingNewResults": {
+ "message": "Chargement de nouveaux résultats...",
+ "description": "The paragraph for fetching new search results"
+ },
+ "theme.SearchBar.label": {
+ "message": "Chercher",
+ "description": "The ARIA label and placeholder for search button"
+ },
+ "theme.SearchModal.searchBox.resetButtonTitle": {
+ "message": "Effacer la requête",
+ "description": "The label and ARIA label for search box reset button"
+ },
+ "theme.SearchModal.searchBox.cancelButtonText": {
+ "message": "Annuler",
+ "description": "The label and ARIA label for search box cancel button"
+ },
+ "theme.SearchModal.startScreen.recentSearchesTitle": {
+ "message": "Récemment",
+ "description": "The title for recent searches"
+ },
+ "theme.SearchModal.startScreen.noRecentSearchesText": {
+ "message": "Aucune recherche récente",
+ "description": "The text when no recent searches"
+ },
+ "theme.SearchModal.startScreen.saveRecentSearchButtonTitle": {
+ "message": "Sauvegarder cette recherche",
+ "description": "The label for save recent search button"
+ },
+ "theme.SearchModal.startScreen.removeRecentSearchButtonTitle": {
+ "message": "Supprimer cette recherche de l'historique",
+ "description": "The label for remove recent search button"
+ },
+ "theme.SearchModal.startScreen.favoriteSearchesTitle": {
+ "message": "Favoris",
+ "description": "The title for favorite searches"
+ },
+ "theme.SearchModal.startScreen.removeFavoriteSearchButtonTitle": {
+ "message": "Supprimer cette recherche des favoris",
+ "description": "The label for remove favorite search button"
+ },
+ "theme.SearchModal.errorScreen.titleText": {
+ "message": "Impossible de récupérer les résultats",
+ "description": "The title for error screen of search modal"
+ },
+ "theme.SearchModal.errorScreen.helpText": {
+ "message": "Vous pouvez vérifier votre connexion réseau.",
+ "description": "The help text for error screen of search modal"
+ },
+ "theme.SearchModal.footer.selectText": {
+ "message": "sélectionner",
+ "description": "The explanatory text of the action for the enter key"
+ },
+ "theme.SearchModal.footer.selectKeyAriaLabel": {
+ "message": "Touche Entrée",
+ "description": "The ARIA label for the Enter key button that makes the selection"
+ },
+ "theme.SearchModal.footer.navigateText": {
+ "message": "naviguer",
+ "description": "The explanatory text of the action for the Arrow up and Arrow down key"
+ },
+ "theme.SearchModal.footer.navigateUpKeyAriaLabel": {
+ "message": "Flèche vers le haut",
+ "description": "The ARIA label for the Arrow up key button that makes the navigation"
+ },
+ "theme.SearchModal.footer.navigateDownKeyAriaLabel": {
+ "message": "Flèche vers le bas",
+ "description": "The ARIA label for the Arrow down key button that makes the navigation"
+ },
+ "theme.SearchModal.footer.closeText": {
+ "message": "fermer",
+ "description": "The explanatory text of the action for Escape key"
+ },
+ "theme.SearchModal.footer.closeKeyAriaLabel": {
+ "message": "Touche Echap",
+ "description": "The ARIA label for the Escape key button that close the modal"
+ },
+ "theme.SearchModal.footer.searchByText": {
+ "message": "Recherche via",
+ "description": "The text explain that the search is making by Algolia"
+ },
+ "theme.SearchModal.noResultsScreen.noResultsText": {
+ "message": "Aucun résultat pour",
+ "description": "The text explains that there are no results for the following search"
+ },
+ "theme.SearchModal.noResultsScreen.suggestedQueryText": {
+ "message": "Essayez de chercher",
+ "description": "The text for the suggested query when no results are found for the following search"
+ },
+ "theme.SearchModal.noResultsScreen.reportMissingResultsText": {
+ "message": "Vous pensez que cette requête doit donner des résultats ?",
+ "description": "The text for the question where the user thinks there are missing results"
+ },
+ "theme.SearchModal.noResultsScreen.reportMissingResultsLinkText": {
+ "message": "Faites-le nous savoir.",
+ "description": "The text for the link to report missing results"
+ },
+ "theme.SearchModal.placeholder": {
+ "message": "Rechercher des docs",
+ "description": "The placeholder of the input of the DocSearch pop-up modal"
+ },
+ "theme.ErrorPageContent.tryAgain": {
+ "message": "Réessayer",
+ "description": "The label of the button to try again rendering when the React error boundary captures an error"
+ },
+ "theme.common.skipToMainContent": {
+ "message": "Aller au contenu principal",
+ "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation"
+ },
+ "theme.tags.tagsPageTitle": {
+ "message": "Tags",
+ "description": "The title of the tag list page"
+ }
+}
diff --git a/i18n/fr/docusaurus-plugin-content-blog/2019-05-28-first-blog-post.md b/i18n/fr/docusaurus-plugin-content-blog/2019-05-28-first-blog-post.md
new file mode 100644
index 000000000..02f3f81bd
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-blog/2019-05-28-first-blog-post.md
@@ -0,0 +1,12 @@
+---
+slug: first-blog-post
+title: First Blog Post
+authors:
+ name: Gao Wei
+ title: Docusaurus Core Team
+ url: https://github.com/wgao19
+ image_url: https://github.com/wgao19.png
+tags: [hola, docusaurus]
+---
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
diff --git a/i18n/fr/docusaurus-plugin-content-blog/2019-05-29-long-blog-post.md b/i18n/fr/docusaurus-plugin-content-blog/2019-05-29-long-blog-post.md
new file mode 100644
index 000000000..26ffb1b1f
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-blog/2019-05-29-long-blog-post.md
@@ -0,0 +1,44 @@
+---
+slug: long-blog-post
+title: Long Blog Post
+authors: endi
+tags: [hello, docusaurus]
+---
+
+This is the summary of a very long blog post,
+
+Use a `` comment to limit blog post size in the list view.
+
+
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
diff --git a/i18n/fr/docusaurus-plugin-content-blog/2021-08-01-mdx-blog-post.mdx b/i18n/fr/docusaurus-plugin-content-blog/2021-08-01-mdx-blog-post.mdx
new file mode 100644
index 000000000..c04ebe323
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-blog/2021-08-01-mdx-blog-post.mdx
@@ -0,0 +1,20 @@
+---
+slug: mdx-blog-post
+title: MDX Blog Post
+authors: [slorber]
+tags: [docusaurus]
+---
+
+Blog posts support [Docusaurus Markdown features](https://docusaurus.io/docs/markdown-features), such as [MDX](https://mdxjs.com/).
+
+:::tip
+
+Use the power of React to create interactive blog posts.
+
+```js
+
+```
+
+
+
+:::
diff --git a/i18n/fr/docusaurus-plugin-content-blog/2021-08-26-welcome/docusaurus-plushie-banner.jpeg b/i18n/fr/docusaurus-plugin-content-blog/2021-08-26-welcome/docusaurus-plushie-banner.jpeg
new file mode 100644
index 000000000..11bda0928
Binary files /dev/null and b/i18n/fr/docusaurus-plugin-content-blog/2021-08-26-welcome/docusaurus-plushie-banner.jpeg differ
diff --git a/i18n/fr/docusaurus-plugin-content-blog/2021-08-26-welcome/index.md b/i18n/fr/docusaurus-plugin-content-blog/2021-08-26-welcome/index.md
new file mode 100644
index 000000000..9455168f1
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-blog/2021-08-26-welcome/index.md
@@ -0,0 +1,25 @@
+---
+slug: welcome
+title: Welcome
+authors: [slorber, yangshun]
+tags: [facebook, hello, docusaurus]
+---
+
+[Docusaurus blogging features](https://docusaurus.io/docs/blog) are powered by the [blog plugin](https://docusaurus.io/docs/api/plugins/@docusaurus/plugin-content-blog).
+
+Simply add Markdown files (or folders) to the `blog` directory.
+
+Regular blog authors can be added to `authors.yml`.
+
+The blog post date can be extracted from filenames, such as:
+
+- `2019-05-30-welcome.md`
+- `2019-05-30-welcome/index.md`
+
+A blog post folder can be convenient to co-locate blog post images:
+
+
+
+The blog supports tags as well!
+
+**And if you don't want a blog**: just delete this directory, and use `blog: false` in your Docusaurus config.
diff --git a/i18n/fr/docusaurus-plugin-content-blog/authors.yml b/i18n/fr/docusaurus-plugin-content-blog/authors.yml
new file mode 100644
index 000000000..bcb299156
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-blog/authors.yml
@@ -0,0 +1,17 @@
+endi:
+ name: Endilie Yacop Sucipto
+ title: Maintainer of Docusaurus
+ url: https://github.com/endiliey
+ image_url: https://github.com/endiliey.png
+
+yangshun:
+ name: Yangshun Tay
+ title: Front End Engineer @ Facebook
+ url: https://github.com/yangshun
+ image_url: https://github.com/yangshun.png
+
+slorber:
+ name: Sébastien Lorber
+ title: Docusaurus maintainer
+ url: https://sebastienlorber.com
+ image_url: https://github.com/slorber.png
diff --git a/i18n/fr/docusaurus-plugin-content-blog/options.json b/i18n/fr/docusaurus-plugin-content-blog/options.json
new file mode 100644
index 000000000..9239ff706
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-blog/options.json
@@ -0,0 +1,14 @@
+{
+ "title": {
+ "message": "Blog",
+ "description": "The title for the blog used in SEO"
+ },
+ "description": {
+ "message": "Blog",
+ "description": "The description for the blog used in SEO"
+ },
+ "sidebar.title": {
+ "message": "Recent posts",
+ "description": "The label for the left sidebar"
+ }
+}
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current.json b/i18n/fr/docusaurus-plugin-content-docs/current.json
new file mode 100644
index 000000000..a0609b282
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current.json
@@ -0,0 +1,94 @@
+{
+ "version.label": {
+ "message": "Next",
+ "description": "The label for version current"
+ },
+ "sidebar.massaStationSidebar.category.Setup": {
+ "message": "Setup",
+ "description": "The label for category Setup in sidebar massaStationSidebar"
+ },
+ "sidebar.massaStationSidebar.category.Massa Wallet": {
+ "message": "Massa Wallet",
+ "description": "The label for category Massa Wallet in sidebar massaStationSidebar"
+ },
+ "sidebar.learnSidebar.category.Node Architecture": {
+ "message": "Node Architecture",
+ "description": "The label for category Node Architecture in sidebar learnSidebar"
+ },
+ "sidebar.buildSidebar.category.Smart Contract": {
+ "message": "Smart Contract",
+ "description": "The label for category Smart Contract in sidebar buildSidebar"
+ },
+ "sidebar.buildSidebar.category.Develop": {
+ "message": "Develop",
+ "description": "The label for category Develop in sidebar buildSidebar"
+ },
+ "sidebar.buildSidebar.category.Wallets": {
+ "message": "Wallets",
+ "description": "The label for category Wallets in sidebar buildSidebar"
+ },
+ "sidebar.buildSidebar.category.Massa-Web3": {
+ "message": "Massa-Web3",
+ "description": "The label for category Massa-Web3 in sidebar buildSidebar"
+ },
+ "sidebar.buildSidebar.category.Networks & Faucets": {
+ "message": "Networks & Faucets",
+ "description": "The label for category Networks & Faucets in sidebar buildSidebar"
+ },
+ "sidebar.buildSidebar.category.API": {
+ "message": "API",
+ "description": "The label for category API in sidebar buildSidebar"
+ },
+ "sidebar.buildSidebar.doc.Introduction": {
+ "message": "Introduction",
+ "description": "The label for the doc item Introduction in sidebar buildSidebar, linking to the doc build/smart-contract/intro"
+ },
+ "sidebar.buildSidebar.doc.WebAssembly Module": {
+ "message": "WebAssembly Module",
+ "description": "The label for the doc item WebAssembly Module in sidebar buildSidebar, linking to the doc build/smart-contract/sdk"
+ },
+ "sidebar.nodeSidebar.doc.Home": {
+ "message": "Home",
+ "description": "The label for the doc item Home in sidebar nodeSidebar, linking to the doc node/home"
+ },
+ "sidebar.nodeSidebar.doc.Installing a node": {
+ "message": "Installing a node",
+ "description": "The label for the doc item Installing a node in sidebar nodeSidebar, linking to the doc node/install"
+ },
+ "sidebar.nodeSidebar.doc.Routability": {
+ "message": "Routability",
+ "description": "The label for the doc item Routability in sidebar nodeSidebar, linking to the doc node/routability"
+ },
+ "sidebar.nodeSidebar.doc.Running a node": {
+ "message": "Running a node",
+ "description": "The label for the doc item Running a node in sidebar nodeSidebar, linking to the doc node/run"
+ },
+ "sidebar.nodeSidebar.doc.Creating a wallet": {
+ "message": "Creating a wallet",
+ "description": "The label for the doc item Creating a wallet in sidebar nodeSidebar, linking to the doc node/wallet"
+ },
+ "sidebar.nodeSidebar.doc.Staking": {
+ "message": "Staking",
+ "description": "The label for the doc item Staking in sidebar nodeSidebar, linking to the doc node/stake"
+ },
+ "sidebar.nodeSidebar.doc.Checking the node's status": {
+ "message": "Checking the node's status",
+ "description": "The label for the doc item Checking the node's status in sidebar nodeSidebar, linking to the doc node/check_status"
+ },
+ "sidebar.nodeSidebar.doc.Node and client configuration": {
+ "message": "Node and client configuration",
+ "description": "The label for the doc item Node and client configuration in sidebar nodeSidebar, linking to the doc node/all-configs"
+ },
+ "sidebar.nodeSidebar.doc.Initial node runners": {
+ "message": "Initial node runners",
+ "description": "The label for the doc item Initial node runners in sidebar nodeSidebar, linking to the doc node/initial"
+ },
+ "sidebar.nodeSidebar.doc.Frequently Asked Questions": {
+ "message": "Frequently Asked Questions",
+ "description": "The label for the doc item Frequently Asked Questions in sidebar nodeSidebar, linking to the doc node/faq"
+ },
+ "sidebar.nodeSidebar.doc.Tutorials and community resources": {
+ "message": "Tutorials and community resources",
+ "description": "The label for the doc item Tutorials and community resources in sidebar nodeSidebar, linking to the doc node/community-resources"
+ }
+}
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/api/grpc.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/build/api/grpc.mdx
new file mode 100644
index 000000000..76ba3a1f7
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/api/grpc.mdx
@@ -0,0 +1,105 @@
+---
+id: grpc
+sidebar_label: gRPC
+---
+
+# Massa gRPC API
+
+The [gRPC](https://grpc.io/) API allows you to communicate with the Massa blockchain.
+
+The Massa gRPC API is splitted in two parts:
+
+- **Public API**: used for blockchain interactions. Default port:
+ 33037 e.g.
+- **Private API**: used for node management. Default port: 33038 e.g.
+
+
+:::info
+To enable events (blocks, endorsements, operations...) brodcast via gRPC streams in your Massa node, add or edit the file
+`massa-node/config/config.toml` with the following content:
+
+```toml
+[api]
+ # whether to broadcast for blocks, endorsement and operations
+ enable_broadcast = true
+```
+:::
+
+## Documentation
+
+- gRPC **API** [documentation](https://htmlpreview.github.io/?https://github.com/massalabs/massa-proto/blob/main/doc/api.html).
+- gRPC **Commons** [documentation](https://htmlpreview.github.io/?https://github.com/massalabs/massa-proto/blob/main/doc/commons.html).
+- gRPC **API** [specification](https://github.com/massalabs/massa-proto/tree/main/proto/apis/massa/api/v1).
+
+## Integrations
+
+- **Postman**: You can find our Massa Postman collections on our official
+[workspace](https://www.postman.com/massalabs).
+- **Massa proto rs**: is a Rust library which contains generated code from Massa protobuf files. See
+[massa-proto-rs](https://github.com/massalabs/massa-proto-rs).
+
+## Code generation
+
+**Step 1: Clone `massa-proto` repository**
+
+```shell
+git clone -b MASSA_PROTO_TAG https://github.com/massalabs/massa-proto.git --depth 1
+```
+
+:::note
+If you are using an older version of the Massa node, please use the tag version or commit hash corresponding to your node version.
+Find all `massa-proto` tags [here](https://github.com/massalabs/massa-proto/tags).
+:::
+
+**Step 2: Install Buf CLI**
+
+1. Download the latest version of Buf CLI from the [official website](https://docs.buf.build/installation).
+2. Extract the downloaded file to a folder on your computer.
+3. Add the buf binary to your system PATH environment variable.
+
+**Step 3: Set up Buf**
+
+1. Add the following content to `buf.work.yml`:
+
+```yaml
+version: v1
+directories:
+ - proto/apis
+ - proto/commons
+ - proto/third_party
+```
+
+By specifying the directories in the configuration file, Buf knows which
+[.proto]{.title-ref} files to include in the build process.
+
+1. Create a file called `buf.gen.yml` and add the following content:
+
+```yaml
+version: v1
+managed:
+ enabled: true
+plugins:
+ - remote: buf.build/community/timostamm-protobuf-ts:v2.9.0
+ out: gen/ts
+```
+
+The configuration uses the official [timostamm-protobuf-ts](https://buf.build/community/timostamm-protobuf-ts)
+plugin to generate gRPC client and classes in TypeScript.
+
+:::info
+For other languages check the complete list of [official Buf plugins](https://buf.build/plugins).
+:::
+
+**Step 4: Generate gRPC client/classes in TypeScript**
+
+1. Launch the code generation:
+
+```yaml
+buf generate
+```
+
+2. Install the required dependencies for the generated code to your project:
+
+```shell
+npm install @protobuf-ts/runtime@^2.9.0 @protobuf-ts/runtime-rpc@^2.9.0
+```
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/api/jsonrpc.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/build/api/jsonrpc.mdx
new file mode 100644
index 000000000..9d17de54e
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/api/jsonrpc.mdx
@@ -0,0 +1,949 @@
+---
+id: jsonrpc
+sidebar_label: JsonRPC
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Massa JSON-RPC API
+
+The JsonRPC API allows you to communicate with the Massa blockchain.
+
+The Massa JSON-RPC API is splitted in two parts:
+
+- **Private API**: used for node management. Default port: 33034 e.g.
+
+- **Public API**: used for blockchain interactions. Default port:
+ 33035 e.g.
+
+The complete Massa [OpenRPC](https://spec.open-rpc.org/) specification is available
+[here](https://raw.githubusercontent.com/massalabs/massa/main/massa-node/base_config/openrpc.json).
+
+The [Interactive API Specification](https://playground.open-rpc.org/?schemaUrl=https://test.massa.net/api/v2&uiSchema\[appBar\]\[ui:input\]=false&uiSchema\[appBar\]\[ui:inputPlaceholder\]=Enter+Massa+JSON-RPC+server+URL&uiSchema\[appBar\]\[ui:logoUrl\]=https://massa.net/favicons/favicon.ico&uiSchema\[appBar\]\[ui:splitView\]=false&uiSchema\[appBar\]\[ui:darkMode\]=false&uiSchema\[appBar\]\[ui:title\]=Massa&uiSchema\[appBar\]\[ui:examplesDropdown\]=false&uiSchema\[methods\]\[ui:defaultExpanded\]=false&uiSchema\[methods\]\[ui:methodPlugins\]=true&uiSchema\[params\]\[ui:defaultExpanded\]=false)
+documents every available method and allows you to play with the API.
+
+:::info
+Massa has a new experimental API with both Http and WebSocket support:
+Default port: 33036
+
+- **Http**: used for node management and blockchain interactions. e.g.
+
+- **WebSocket**: used for streaming blockchain events. e.g.
+
+:::
+
+## Integrations
+
+- **JavaScript**: The [massa-web3](https://github.com/massalabs/massa-web3) TypeScript library
+can be used to call the JSON-RPC API... and much more.
+- **Postman**: You can find our Massa Postman collections on our official [workspace](https://www.postman.com/massalabs).
+
+## Explore the Blockchain
+
+In this section we'll learn how to interact with Massa blockchain using the public API via
+cURL commands which will create JSON-RPC request calls.
+
+### get_status
+
+Summary of the current state: time, last final blocks (hash, thread,
+slot, timestamp), clique count, connected nodes count.
+
+
+
+
+```shell
+curl --location --request POST 'https://mainnet.massa.net/api/v2' \
+--header 'Content-Type: application/json' \
+--data-raw '{
+ "jsonrpc": "2.0",
+ "id": 1,
+ "method": "get_status",
+ "params": []
+}'
+```
+
+
+
+
+
+```shell
+curl --location --request POST 'https://buildnet.massa.net/api/v2' \
+--header 'Content-Type: application/json' \
+--data-raw '{
+ "jsonrpc": "2.0",
+ "id": 1,
+ "method": "get_status",
+ "params": []
+}'
+```
+
+
+
+
+
+Example response:
+
+
+
+## WebSockets support
+
+In this section we'll learn how to enable and subscribe to WebSockets
+via Postman client.
+
+:::caution
+Experimental support for WebSocket is a feature that is subject to
+change in a future releases.
+:::
+
+Available subscriptions:
+
+- `subscribe_new_blocks/unsubscribe_new_blocks`:
+ subscribe/unsubscribe to/from new produced blocks.
+- `subscribe_new_blocks_headers/unsubscribe_new_blocks_headers`:
+ subscribe/unsubscribe to/from new produced blocks headers.
+- `subscribe_new_filled_blocks/unsubscribe_new_filled_blocks`:
+ subscribe/unsubscribe to/from new produced filled blocks with
+ operations content.
+- `subscribe_new_operations/unsubscribe_new_operations`:
+ subscribe/unsubscribe to/from new produced operations.
+
+To enable WebSocket support in Massa node, edit file
+`massa-node/config/config.toml` (create it if absent) with the following
+contents:
+
+```toml
+[api]
+ # whether to broadcast for blocks, endorsement and operations
+ enable_broadcast = true
+ # whether to enable WS.
+ enable_ws = true
+```
+
+Postman brings support for WebSocket APIs, more information about it
+[here](https://blog.postman.com/postman-supports-websocket-apis/).
+
+
+
+- run the massa node
+- connect to `ws://localhost:33036`
+- send the request message:
+
+```json
+{
+ "jsonrpc": "2.0",
+ "id": 1,
+ "method": "subscribe_new_filled_blocks",
+ "params": []
+}
+```
+
+- If the request succeed, the response will contains a subscription id:
+
+```json
+{
+ "jsonrpc": "2.0",
+ "result": 3508678639232691,
+ "id": 1
+}
+```
+
+- Result:
+
+```json
+{
+ "jsonrpc": "2.0",
+ "method": "new_filled_blocks",
+ "params": {
+ "subscription": 3508678639232691,
+ "result": "FILLED_BLOCK_CONTENT_0"
+ }
+}
+```
+
+- A message is received everytime a filled block is produced:
+
+```json
+{
+ "jsonrpc": "2.0",
+ "method": "new_filled_blocks",
+ "params": {
+ "subscription": 3508678639232691,
+ "result": "FILLED_BLOCK_CONTENT_N"
+ }
+}
+```
+
+- unsubscribe and stop receiving new filled blocks:
+
+```json
+{
+ "jsonrpc": "2.0",
+ "id": 1,
+ "method": "unsubscribe_new_filled_blocks",
+ "params": [
+ 3508678639232691
+ ]
+}
+```
+
+- Result:
+
+```json
+{
+ "jsonrpc": "2.0",
+ "result": true,
+ "id": 1
+}
+```
+
+:::note
+Multiple subscriptions are supported
+:::
+
+## Error codes
+
+When a call to Massa API fails, it **MUST** return a valid JSON-RPC
+[error object](https://www.jsonrpc.org/specification#error_object).
+
+| **Code** | **Message** | **Meaning** |
+|----------|----------------------|--------------------------------------------|
+| -32600 | Invalid request | The JSON sent is not a valid Request object |
+| -32601 | Method not found | The method does not exist / is not available |
+| -32602 | Invalid params | Invalid method parameter(s) |
+| -32603 | Internal error | Internal JSON-RPC error |
+| -32700 | Parse error | Invalid JSON, parsing issue |
+| -32000 | Bad request | Indicates that the server cannot or will not process the request due to something that is perceived to be a client error |
+| -32001 | Internal server error| The server encountered an unexpected issue |
+| -32003 | Service Unavailable | Indicates that the server is not ready to handle the request |
+| -32004 | Not found | Indicates that the server cannot find the requested resource |
+| -32005 | Method not allowed | Indicates that the server knows the request method, but the target resource doesn't support this method |
+| -32006 | Send channel error | Send channel error |
+| -32007 | Receive channel error| Receive channel error |
+| -32008 | Massa hash error | `massa_hash` error |
+| -32009 | Consensus error | Error from Consensus module |
+| -32010 | Execution error | Error from Execution module |
+| -32012 | Protocol error | Error from Protocol module |
+| -32013 | Models error | Error in Models |
+| -32014 | Time error | Error from Time module |
+| -32015 | Wallet error | Error from Wallet module |
+| -32016 | Inconsistency error | Inconsistency in the result of request |
+| -32017 | Missing command sender| Missing command sender |
+| -32018 | Missing config | Missing configuration |
+| -32019 | Wrong API | The wrong API (either Public or Private) was called |
+
+
+
+Example error:
+
+
+```json
+{
+"jsonrpc": "2.0",
+"error": {
+ "code": -32400,
+ "message": "Bad request: too many arguments, maximum authorized 2 but found 3"
+},
+"id": 1
+}
+```
+
+
+
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/api/postman_websocket.png b/i18n/fr/docusaurus-plugin-content-docs/current/build/api/postman_websocket.png
new file mode 100644
index 000000000..3f2f59eec
Binary files /dev/null and b/i18n/fr/docusaurus-plugin-content-docs/current/build/api/postman_websocket.png differ
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/api/providers.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/build/api/providers.mdx
new file mode 100644
index 000000000..6f58acee3
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/api/providers.mdx
@@ -0,0 +1,63 @@
+---
+id: providers
+sidebar_label: Providers
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# RPC Providers
+
+To interact with the different networks of the Massa blockchain, you can select from any of the listed providers.
+Be aware that the latency you encounter may vary depending on the provider's geographical location.
+To enhance redundancy and facilitate load balancing, consider using multiple providers.
+
+
+
+
+
+
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/hello-world-dapp.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/build/hello-world-dapp.mdx
new file mode 100644
index 000000000..fa867f8e4
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/hello-world-dapp.mdx
@@ -0,0 +1,419 @@
+---
+id: hello-world-dapp
+sidebar_label: '"Hello, World!" dApp'
+---
+
+# Build a "Hello, World!" dApp
+
+Welcome, Developer! You're about to embark on an exciting journey where you'll build your very first decentralized application (dApp) using the Massa blockchain. If you're thrilled about the world of blockchain, smart contracts, and dApps, you've come to the right place!
+
+This guide will help you build a simple "Hello, World!" dApp. We'll use a smart contract written in AssemblyScript and a user-friendly frontend designed in React.
+
+## What are we going to do ?
+
+Here's the scoop: The application we're about to develop is simple. It will allow the user to retrieve a "Hello, World!" message that was set during the dApp deployment. This message will be stored on the Massa blockchain and will be permanently visible to all users of our dApp trough a front end.
+
+Here's a quick overview of the component that will make up our dApp:
+
+- **The Smart Contract (SC)**
+ The smart contract, written in AssemblyScript, is the backbone of our dApp. If you are familiar with web development, you can think of the smart contract as the back end of the application. It will be deployed on the Massa blockchain and will be responsible for storing and retrieving the "Hello, World!" greeting message.
+
+- **The Frontend**
+ A basic web interface built in React will allow users to read the greeting message. This interface will interact with the Massa blockchain by fetching the "Hello, World!" message from our smart contract.
+
+And that's it! Let's get started.
+
+## The Smart Contract
+
+In this section, we are going to create a smart contract that will be deployed on the Massa blockchain. As explained earlier, this smart contract will be responsible for storing and retrieving the "Hello, World!" message.
+Smart contract in Massa are written in AssemblyScript, a language that is very similar to TypeScript. If you are not familiar with AssemblyScript, don't worry! We will guide you through the process of writing your first smart contract.
+
+### Prerequisites
+
+Before we start, here's what you'll need:
+
+- **Node.js and npm installed**
+ We recommend using Node.js version 18 or later, and the compatible npm version. You can download and install Node.js and npm from the official website: https://nodejs.org/.
+
+- **Massa Wallet and your secret key**
+ You'll need a funded Massa wallet and your secret key before you deploy your smart contract to the Massa blockchain.
+
+:::info
+Not sure how to create and fund a Massa wallet? Check our guide [here](/docs/build/wallet/intro).
+:::
+
+### Setting up Your Project
+
+Here are the steps to set up your smart contract project:
+
+#### Step 1: Initialize Your Smart Contract Project
+
+First, open a terminal, and navigate to your preferred directory. Now, let's create your project with the following command:
+
+```bash
+npx @massalabs/sc-project-initializer@buildnet init massa-hello-world
+```
+
+With this command, you have created a new folder named `massa-hello-world` with all the necessary files for developing a Massa smart contract. Navigate to this folder.
+
+Once you have navigated to the project directory, you should see the following files and directories:
+
+- **`assembly`**: This is the directory where your smart contract code resides. Within this, you'll find your contract files in the `contracts` subdirectory and your test files in the `tests` subdirectory.
+
+- **`.env.example`**: This file serves as a template for the `.env` file you'll need to create. It outlines the necessary environment variables required to deploy your smart contract.
+
+- **`package.json`**: This file contains the npm commands crucial for various operations such as checking, testing, building, and deploying your smart contract.
+:::
+
+#### Step 2: Setting up the Environment variables
+In order to communicate with the blockchain and deploy our smart contract we are going to need two things: a wallet and a node. The node will allow us to communicate with the blockchain while the wallet will allow us to sign and pay for the deployment of our smart contract. The wallet will come under the form of a secret key, while the node will be the JSON-RPC URL of a public node.
+
+Copy the content of the `.env.example` to a newly created `.env` file at the root of your project directory.
+Once created, edit the `.env` file by inserting your wallet's secret key.
+```bash
+WALLET_SECRET_KEY="Your_private_key_here"
+JSON_RPC_URL_PUBLIC=https://buildnet.massa.net/api/v2:33035
+```
+
+:::info
+- WALLET_SECRET_KEY: This is your wallet's secret key. It will be used to sign the contract deployment transaction. Make sure your wallet is funded.
+- JSON_RPC_URL_PUBLIC: This is the URL of the JSON-RPC interface of a public or a private Massa node.
+:::
+
+### Writing and Deploying the Smart Contract
+
+Now that you have set up your project, let's write our smart contract. Our smart contract will let users set and get a greeting message. The message will be stored in the contract storage and will be permanently visible to all users of our dApp. The greeting message will be set during the deployment of the smart contract.
+
+#### Step 1: Writing the smart contract
+
+Navigate to the `assembly/contracts` directory and open the `main.ts` file. This is where we will write our smart contract code.
+Replace the content of the `main.ts` file in assembly/contracts with the following code:
+
+```tsx
+import { generateEvent, Storage, Context } from "@massalabs/massa-as-sdk";
+
+/**
+ * This function is meant to be called only one time: when the contract is deployed.
+ *
+ * @param _ - not used
+ */
+export function constructor(_: StaticArray): void {
+ // This line is important. It ensures that this function can't be called in the future.
+ // If you remove this check, someone could call your constructor function and reset your smart contract.
+ if (!Context.isDeployingContract()) {
+ return;
+ }
+
+ // Set the greeting message in the contract storage
+ Storage.set("greeting", "Hello, World!");
+
+ // Emit an event to notify that the greeting message has been set
+ generateEvent(`Greeting has been set`);
+
+ return;
+}
+```
+At first glance, it may seems like a lot of code for a simple "Hello, World!". But the code above is actually quite simple. Let's break it down:
+
+- **Importing the necessary packages from Massa AssemblyScript SDK**
+```tsx
+import { generateEvent, Storage, Context } from "@massalabs/massa-as-sdk";
+```
+
+Here we are importing the necessary functions from the Massa AssemblyScript SDK. The Massa AssemblyScript software development kit (SDK) is a collection of functions and objects that wrap the ABIs exposed by the node.
+
+:::info
+If you are familiar with Solidity smart contracts, you will soon notice that some object provided by Massa AssemblyScript SDK are very similar to the ones provided by the Solidity SDK. For example, the `Context` object is very similar to the `msg` object in Solidity. It exposes methods such as `Context.transferredCoins()` which would translate to `msg.value` in Solidity. `Context.caller()` would return the address of the function caller like `msg.sender` in solidity. Similarly, the `generateEvent` function is very similar to the `emit` function in Solidity, etc.
+You can learn more about the Massa AssemblyScript SDK [here](docs/build/smart-contract/as-sdk.md).
+:::
+
+- **The constructor function**
+
+```tsx
+export function constructor(_: StaticArray): void {
+ if (!Context.isDeployingContract()) {
+ return;
+ }
+```
+
+This is the constructor function. It is called only once when the contract is being deployed. The constructor function takes a parameter of type `StaticArray`. This parameter is not used in this example, so we are ignoring it by using the `_` symbol. The `Context.isDeployingContract()` function is used to check if the contract is being deployed. If it is not, the function returns and the rest of the code is not executed. It ensures that the constructor function can't be called in the future. If you remove this check, someone could call your constructor function and reset your smart contract.
+
+- **Setting the greeting message in the contract storage**
+```tsx
+Storage.set("greeting", "Hello, World!");
+```
+
+This line sets the greeting message in the contract storage. The `Storage.set()` function takes two parameters: the key and the value. The key is a string that will be used to retrieve the value from the storage. The value can be of any type. In this example, we are using a string.
+
+:::info
+In Massa, if you want some data to be persistent on the blockchain, you need to store it in the contract storage. If you are familiar with web development, you can think of the storage as the database of your application. The contract storage is a key-value store that can be used to store simple objects such as our "Hello, World!" string, or more complex objects such as serializable object arrays. Then the data can be retrieved from the storage using methods such has `Storage.get()` or `Storage.has()` provided by the SDK. You can learn more about how to handle the storage with Massa AS-SDK [here](docs/build/smart-contract/as-sdk.md#storage).
+:::
+
+:::info
+In Massa, when writing to the persistent storage a.k.a the ledger, you need to pay for the storage space you will be using. The more data you store, the more you will have to pay. Similarly when you free-up some space from the ledger, you recover the amount of coins you paid to allocate the space. The price of storage is a fixed amount of Massa coins for each byte of data (0.001 MAS per byte). You can learn more about storage cost in Massa smart contracts [here](docs/learn/storage-costs.mdx).
+:::
+
+- **Emitting an event**
+
+```tsx
+generateEvent(`Greeting has been set`);
+```
+Here, we are emitting an event to notify that the greeting message has been set. Events are a great way to notify the front ends of a dApp that something has happened. They are similar to events in Solidity. You can learn more about events [here](docs/build/smart-contract/as-sdk.md#utilities).
+
+Now that we have written our smart contract, let's deploy it to the blockchain.
+
+#### Step 2: Compile Your Smart Contract
+
+In your project directory, run the following command to compile your smart contract into a WebAssembly (Wasm) file:
+
+```bash
+npm run build
+```
+
+:::info
+This command compiles your `main.ts` contract into a `main.wasm` file generated in the `build` directory. This main.wasm file is the compiled version of your smart contract that will be deployed to the blockchain.
+:::
+
+#### Step 3: Deploy the Smart Contract
+
+Now that your smart contract is compiled and ready, let's deploy it to the Massa blockchain.
+You first need some funds in your wallet that you can request from the [faucet](/docs/build/networks-faucets/public-networks).
+You can then run the following command in your project directory:
+
+```bash
+npm run deploy
+```
+
+Upon successful execution, the console should display the operation id that you can use to track the deployment of your smart contract.
+
+:::info
+After deployment, an event will be displayed in the console. This event contains the address of your deployed smart contract and the event message set in the constructor function.
+
+```bash
+Event Data Received: [
+ {
+ context: {...},
+ data: 'Greeting has been set'
+ },
+ {
+ context: {...},
+ data: 'Contract deployed at address: AS12UJM8JYR6cRzXgkUGTjRDu9hicJUPkDvy7zGhGZq3WgZ511dwR'
+ }
+]
+```
+
+Keep the address of your deployed smart contract handy. You'll need it later.
+:::
+
+## The Frontend
+
+Now that our smart contract is deployed, let's move on to the front end of your dApp. We'll use React with TypeScript to build a user interface that will interact with our deployed smart contract on the Massa blockchain. It will fetch the greeting message from the contract storage and display it to the user.
+
+Sounds fun, doesn't it? Let's get started!
+
+### Setting Up Your Project
+
+To set up your frontend project, follow these steps:
+
+- **Step 1: Initialize Your React Application**
+
+First, open your terminal, navigate to your desired directory, and execute the following command to create a new React project:
+
+```bash
+npx create-react-app my-app --template typescript
+```
+
+:::info
+The --template typescript flag sets up a TypeScript template for our React application.
+:::
+
+After the installation is complete, navigate to your project folder.
+
+- **Step 2: Installing Massa Web3**
+
+Next up, we are going to install the [Massa Web3 package](https://github.com/massalabs/massa-web3). This package enables our front end to interact with the Massa blockchain. If you are familiar with the EVM ecosystem, `massa-web3` would be the equivalent of `web3` or `ethers` librairies, but for the Massa blockchain. Here's how to install it:
+
+```bash
+npm install @massalabs/massa-web3@buildnet
+```
+
+- **Step 3: Building the Frontend**
+
+Now that we have our dependencies installed, let's begin building the front end of our dApp.
+
+Before writing our component, navigate to the src folder and locate the `App.tsx` file.
+
+This `App.tsx` file serves as the main entry point for your application. Replace the content of this file with the following code:
+
+```tsx
+import {
+ Client,
+ ClientFactory,
+ strToBytes,
+ bytesToStr,
+ WalletClient,
+ DefaultProviderUrls,
+} from "@massalabs/massa-web3";
+
+import { useEffect, useState } from "react";
+
+const sc_addr = "SC_ADDRESS"; // TODO Update the constant value!
+
+/**
+ * Content component that handles interactions with a Massa smart contract
+ * @returns The rendered component
+ */
+function Content() {
+ /**
+ * State variables to manage the web3 client and greetings
+ */
+ const [web3client, setWeb3client] = useState(null);
+ const [greeting, setGreeting] = useState(null);
+
+ /**
+ * Initialize the web3 client using the custom provider defined above
+ */
+ useEffect(() => {
+ const initClient = async () => {
+ const client = await ClientFactory.createDefaultClient(
+ DefaultProviderUrls.BUILDNET,
+ false
+ );
+ setWeb3client(client);
+ };
+ initClient().catch(console.error);
+ }, []);
+
+ /**
+ * Fetch the greeting when the web3 client is initialized
+ */
+ useEffect(() => {
+ if (web3client) {
+ funcGetGreeting();
+ }
+ }, [web3client]);
+
+ /**
+ * Function to get the current greeting from the smart contract
+ */
+ async function funcGetGreeting() {
+ if (web3client) {
+ let res = await web3client
+ .publicApi()
+ .getDatastoreEntries([
+ { address: sc_addr, key: strToBytes("greeting") },
+ ]);
+ if (res[0].candidate_value) {
+ let greetingDecoded = bytesToStr(res[0].candidate_value);
+ setGreeting(greetingDecoded);
+ }
+ }
+ }
+
+ return (
+
+
Greeting: {greeting}
+
+ );
+}
+
+export default Content;
+```
+
+:::info
+Make sure to replace `SC_ADDRESS` with your own smart contract address.
+:::
+
+### Understanding the Code
+
+Our code might seem like a mouthful at first, but let's break it down into smaller, digestible parts:
+
+- **Setting Up Providers and Initializing a Custom Client**
+```tsx
+const initClient = async () => {
+ const client = await ClientFactory.createDefaultClient(
+ DefaultProviderUrls.BUILDNET,
+ false
+ );
+ setWeb3client(client);
+};
+```
+In order to interact with the blockchain, our front end application is going to need a client. A client is a piece of software that can be used to interact with a service; in our case the service is the Massa blockchain and we will use the client's methods to interact with our smart contract.
+
+In the code above, we are using the `createDefaultClient` method to initialize our client object. This method takes two parameters: a provider URL and a boolean. The provider URL is the URL of the node we want to use to interact with the blockchain.
+
+:::info
+If you remember correctly, [before deploying our smart contract](#step-2-setting-up-the-environment-variables)
+, we created a `.env` file and added a `JSON_RPC_URL` variable to it. This variable was the URL of a node used to deploy our smart contract to the Massa blockchain. Here we are doing something similar but instead of using a node to deploy our smart contract, we are using a node to interact with our smart contract.
+:::
+
+We are using the `DefaultProviderUrls.BUILDNET` constant as our provider URL. This constant points to a node on the Massa buildnet.
+The boolean is a flag that indicates whether or not we want to provide an wallet account to sign transactions. Here it is set to false because we are not going to sign any transactions. Finally, we are setting the client object to the `web3client` state variable using the `setWeb3client` function, so that the web3 client is available to the rest of our application.
+
+:::info
+The buildnet is a test network that is used to test smart contracts before deploying them to the mainnet. It is similar to the Ethereum Sepolia network. You can learn more about Massa networks [here](/docs/build/networks-faucets/public-networks).
+:::
+
+
+- **Retrieving the Greeting**
+```tsx
+ async function funcGetGreeting() {
+ if (web3client) {
+ let res = await web3client
+ .publicApi()
+ .getDatastoreEntries([
+ { address: sc_addr, key: strToBytes("greeting") },
+ ]);
+ if (res[0].candidate_value) {
+ let greetingDecoded = bytesToStr(res[0].candidate_value);
+ setGreeting(greetingDecoded);
+ }
+ }
+ }
+```
+In the code above, we are retrieving the "Hello, World!" greeting message by directly reading the smart contract's storage.
+
+To do so, we are using the `getDatastoreEntries` method. This method takes an array of `DatastoreEntry` objects as a parameter. Each `DatastoreEntry` object contains the address of the smart contract and the key of the value we want to retrieve.
+In our case, the address of the smart contract is the one we got during contract deployment. The key is the string "greeting" [that we used to store the greeting message in the smart contract's storage](#step-1-writing-the-smart-contract).
+We retrieve the current greeting from the smart contract's storage and decode it using the `bytesToStr` function. Finally, we set the greeting to the `greeting` state variable using the `setGreeting` function.
+
+:::info
+As you can see, we cannot directly use the datastore entry returned by the smart contract. Indeed, the storage of the smart contract is a key value store that stores data in bytes. Thus, we need to decode the bytes returned by the smart contract to get the actual greeting message. That is why we have to use massa-web3 `bytesToStr` function. You can check massa-web3 utils [here](https://web3.docs.massa.net/modules/utils.html).
+:::
+
+- **User Interface**
+
+The user interface consists of a centered text display that shows the current greeting fetched from your smart contract's storage.
+
+## Testing your application
+
+Finally, let's start our application and perform some basic user acceptance testing!
+
+```bash
+npm run start
+```
+
+1. Open your web browser and navigate to [http://localhost:3000](http://localhost:3000)
+2. Here, you should see a greeting that says "Hello, World!" This is the message that was set in your smart contract.
+3. If you're able to see this greeting, your dApp is functioning correctly.
+
+🎉 Congratulations on building and testing your first dApp!
+
+Remember, Rome wasn't built in a day, and neither are amazing dApps! Keep learning!
+
+## Next steps
+
+Congratulations on writing and testing your first dApp using the Massa blockchain! You've taken a crucial step in your blockchain development journey.
+
+There's always more to learn. To continue exploring and expanding your knowledge, you can:
+
+- Review more detailed guides on [smart contract development](/docs/build/smart-contract/intro).
+- Check out more [complex examples](/docs/tutorial/home) of dApps built on Massa.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/home.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/build/home.mdx
new file mode 100644
index 000000000..02104dd45
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/home.mdx
@@ -0,0 +1,33 @@
+---
+id: home
+sidebar_label: Home
+---
+
+import { FeatureList, Feature } from "@site/src/components/featurelist";
+
+# Developer Documentation
+
+Greetings! Here you'll discover documentation on how to develop decentralized applications (dApps) on Massa.
+
+Whether you're a novice or unfamiliar with smart contract technology, rest assured that we'll swiftly bring you up to date with all the essential knowledge.
+
+
+
+
+
+
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/massa-web3/backend-usage-massa-web3.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/build/massa-web3/backend-usage-massa-web3.mdx
new file mode 100644
index 000000000..c313dd622
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/massa-web3/backend-usage-massa-web3.mdx
@@ -0,0 +1,25 @@
+---
+id: backend-usage-massa-web3
+title: Backend Usage
+---
+
+If you need to interact with the Massa network for your backend, you can use the Massa Web3 API without the wallet provider.
+Initialization of the client is shown in the [introduction](/docs/build/massa-web3#without-wallet-provider)
+of the Massa Web3.
+
+## Wallet & Account Management
+
+The Wallet API provides a range of methods for creating or importing an account, getting account information, sending transactions, signing
+messages, etc.
+
+A [complete example](https://github.com/massalabs/massa-web3/blob/main/examples/wallet/index.ts) of how to use the Wallet
+API is also available.
+
+You can also find the full typescript documentation [here](https://web3.docs.massa.net/classes/WalletClient.html).
+
+## Private and Public API
+
+All the operations needed to manage a node are available through the private API. The corresponding Typescript documentation can be found [here](https://web3.docs.massa.net/classes/PrivateApiClient.html).
+
+Reading the state of the blockchain can be done through the public API. The corresponding Typescript documentation can be found
+[here](https://web3.docs.massa.net/classes/PublicApiClient.html).
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/massa-web3/dapp-usage-massa-web3.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/build/massa-web3/dapp-usage-massa-web3.mdx
new file mode 100644
index 000000000..83803be65
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/massa-web3/dapp-usage-massa-web3.mdx
@@ -0,0 +1,55 @@
+---
+id: dapp-usage-massa-web3
+title: dApp Usage
+---
+
+Here are some examples of how to use the Massa Web3 API for dApp development.
+
+## Calling a smart contract
+
+Full code of the Age dApp is available [here](https://github.com/massalabs/massa-sc-examples/tree/main/age).
+
+The [age smart contract](https://github.com/massalabs/massa-sc-examples/blob/main/age/contracts/assembly/contracts/main.ts) stores the name and age of persons.
+This snippets shows how to call the smart contract and change the age value of Alice.
+
+After creating a react app and setting up the Massa Web3 API as described in the
+[installation](/docs/build/massa-web3#installation) section, we can call the smart contract method `changeAge` like this:
+
+```typescript
+let args = new Args().addString(inputName).addU32(newAge);
+let opId = await client.smartContracts().callSmartContract({
+ targetAddress: CONTRACT_ADDRESS,
+ functionName: "changeAge",
+ parameter: args.serialize(),
+ maxGas: BigInt(1000000),
+ coins: BigInt(0),
+ fee: BigInt(0),
+});
+```
+[Github redirection](https://github.com/massalabs/massa-sc-examples/blob/main/age/react/src/App.tsx#L77)
+
+Since that method requires a string and an integer as parameters, we need to serialize them first. The `Args` class
+provides a convenient way to do that. You can learn more about Args via the [source code](https://github.com/massalabs/web3-utils/blob/main/src/arguments.ts#L42)
+and its usage with the [examples](https://github.com/massalabs/massa-sc-examples/).
+
+If the call is successful, we get an operation id back, you can then use it to check the status of the operation with the [explorer](https://buildnet.massa.net/#explorer)
+
+## Reading a smart contract value
+
+You can directly read smart contract datastore values
+ with the `readSmartContractData` method, which does not require any gas or fee:
+
+```typescript
+ const res = await client.smartContracts().readSmartContract({
+ maxGas: BigInt(1000000),
+ targetAddress: CONTRACT_ADDRESS,
+ targetFunction: "getAge",
+ parameter: new Args().addString(inputName).serialize(),
+ });
+
+ const age = res.returnValue;
+```
+
+:::info
+Since the `getAge` method doesn't change the state of the smart contract, we don't need to use a client with an account linked to it.
+:::
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/massa-web3/massa-web3.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/build/massa-web3/massa-web3.mdx
new file mode 100644
index 000000000..a1075ec98
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/massa-web3/massa-web3.mdx
@@ -0,0 +1,270 @@
+---
+id: massa-web3-main
+title: Introduction
+---
+
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
+
+# Leveraging Javascript API for Massa interaction
+
+## What is Massa-Web3?
+
+Massa-web3 is an exhaustive library enabling interaction with the Massa blockchain. It can be used in a browser environment and Node.js runtime.
+
+:::note
+Massa-web3 operates by utilizing JsonRPC API in the background to facilitate blockchain communication. The API is divided into a Private and a Public segment, used for node management and blockchain interactions, respectively. For more information on the API, please refer to the [JsonRPC API documentation](/docs/build/api/jsonrpc).
+:::
+
+Massa-web3 will allow you to interact with the Massa blockchain in a variety of ways:
+
+- Send transactions
+- Deploy smart contracts
+- Create, manage and inspect addresses
+- Manage your node
+- Fetch events from the blockchain
+- And much more!
+
+In addition, the library includes a [collection of handy utility functions](/docs/build/massa-web3/massa-web3-utils) (e.g conversion between different units, etc).
+
+:::tip
+For a quick integration of Massa within a web browser, consider reading our Web Frontend Integration Guide.
+:::
+
+## Installation
+
+Massa-web3 can be used as a library for frameworks or as a stand-alone bundled js file which can be easily loaded into the browser.
+
+### Requirements
+
+- NodeJS 14+
+- npm / yarn (see package.json)
+
+### As a library (Node.js/React/Vue.js)
+
+Just install the library using npm:
+
+```shell
+npm install @massalabs/massa-web3
+```
+
+### In a browser
+
+If you want to use the library in a vanilla javascript project, please add the following script tag to your html file:
+
+```html
+
+```
+
+whereby the x.x.x is one of the available released versions under [Massa-web3's releases page](https://github.com/massalabs/massa-web3/releases):
+
+In your code, once the script is fully loaded, just use window.massa to access all massa-web3 exports.
+
+```ts
+
+```
+
+## Initialization
+
+Some usage of massa-web3 require an account. This account can be either provided using [Wallet-provider](/docs/build/wallet/wallet-provider) or directly in the code
+
+### With Wallet-provider
+
+The Wallet-provider allows you to easily connect your dApp to a user's wallet, without having to worry about
+secret keys and other sensitive information. The Wallet-provider will automatically detect if a wallet is installed and connect to it.
+
+
+
+
+Full code can be found [here](https://github.com/massalabs/massa-sc-examples/blob/main/age/react/src/App.tsx)
+
+```typescript
+useEffect(() => {
+ const registerAndSetProvider = async () => {
+ try {
+ let provider = (await providers(true, 10000))[0];
+ let accounts = await provider.accounts();
+ if (accounts.length === 0) {
+ setErrorMessage("No accounts found");
+ return;
+ }
+ setAccount(accounts[0]);
+ if (!account || !provider) {
+ return;
+ }
+ setClient(await ClientFactory.fromWalletProvider(provider, account));
+ } catch (e) {
+ console.log(e);
+ setErrorMessage(
+ "Please install massa station and the wallet plugin and refresh."
+ );
+ }
+ };
+ registerAndSetProvider();
+}, [account]);
+```
+
+
+
+
+Full code can be found [here](https://github.com/massalabs/massa-sc-examples/blob/main/age/html/js/index.js)
+
+```typescript
+let massa = window.massa;
+let wallet = window.wallet;
+
+let client = null;
+let account = null;
+
+const initializeClient = async () => {
+ try {
+ let provider = (await wallet.providers(true, 10000))[0];
+ let accounts = await provider.accounts();
+ if (accounts.length === 0) {
+ throw new Error("No accounts found");
+ }
+ account = accounts[0];
+ if (!account || !provider) {
+ throw new Error("No account or provider found");
+ }
+ client = await massa.ClientFactory.fromWalletProvider(provider, account);
+ } catch (e) {
+ console.error(e);
+ }
+};
+```
+
+
+
+
+### Without Wallet-provider
+
+You can easily initialize a client instance using the ClientFactory class:
+
+
+
+```typescript
+const baseAccount: IAccount = await WalletClient.getAccountFromSecretKey(
+ privateKey
+);
+const chainId = CHAIN_ID.MainNet;
+
+const testnetClient: Client = await ClientFactory.createDefaultClient(
+ DefaultProviderUrls.MAINNET,
+ chainId,
+ true, // retry failed requests
+ baseAccount // optional parameter
+);
+```
+
+
+
+```typescript
+const baseAccount: IAccount = await WalletClient.getAccountFromSecretKey(
+ privateKey
+);
+const chainId = CHAIN_ID.BuildNet;
+
+const testnetClient: Client = await ClientFactory.createDefaultClient(
+ DefaultProviderUrls.BUILDNET,
+ chainId,
+ true, // retry failed requests
+ baseAccount // optional parameter
+);
+```
+
+
+
+
+```typescript
+const baseAccount: IAccount = await WalletClient.getAccountFromSecretKey(
+ privateKey
+);
+const chainId = CHAIN_ID.LabNet;
+
+const testnetClient: Client = await ClientFactory.createDefaultClient(
+ DefaultProviderUrls.LABNET,
+ chainId,
+ true, // retry failed requests
+ baseAccount // optional parameter
+);
+```
+
+
+
+
+
+```typescript
+const baseAccount: IAccount = await WalletClient.getAccountFromSecretKey(
+ privateKey
+);
+const chainId = CHAIN_ID.Sandbox;
+
+const testnetClient: Client = await ClientFactory.createDefaultClient(
+ DefaultProviderUrls.LOCALNET,
+ chainId,
+ true, // retry failed requests
+ baseAccount // optional parameter
+);
+```
+
+
+
+
+You can also create a custom client connecting to a node whose ip and ports are to be specified by the user.
+
+```typescript
+const baseAccount: IAccount = await WalletClient.getAccountFromSecretKey(
+ privateKey
+);
+const chainId = CHAIN_ID.Sandbox;
+
+// initialize a custom client using an own provider
+const providers: Array = [
+ {
+ url: "http://127.0.0.1:33035",
+ type: ProviderType.PUBLIC,
+ } as IProvider,
+ {
+ url: "http://127.0.0.1:33034",
+ type: ProviderType.PRIVATE,
+ } as IProvider,
+];
+
+const customClient: Client = await ClientFactory.createCustomClient(
+ providers,
+ chainId,
+ true, // retry failed requests
+ baseAccount // optional parameter
+);
+```
+
+
+
+
+:::info
+When initializing the client, you have the option to specify a `baseAccount`. If provided, this account
+will be used as the default executor for upcoming calls. If you choose to initialize
+the client without a `baseAccount`, it becomes mandatory to specify the executor for each call that requires a signature.
+You can learn more about how to manage the base account in the [Wallet Operations](https://web3.docs.massa.net/classes/WalletClient.html) section.
+:::
+
+### Client exposed APIs
+
+Once there is an initialized client instance, it is straightforward to call methods on it:
+
+```ts
+const balance = await web3Client
+ .wallet()
+ .getAccountBalance("address")
+```
+
+You can find details for each of the exposed APIs with all the available methods in the following sections:
+
+- [Wallet Operations](https://web3.docs.massa.net/classes/WalletClient.html)
+- [Smart Contracts Operations](https://web3.docs.massa.net/classes/SmartContractsClient.html)
+- [Public API](https://web3.docs.massa.net/classes/PublicApiClient.html)
+- [Private API](https://web3.docs.massa.net/classes/PrivateApiClient.html)
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/massa-web3/utils.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/build/massa-web3/utils.mdx
new file mode 100644
index 000000000..bcf7bdf54
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/massa-web3/utils.mdx
@@ -0,0 +1,45 @@
+---
+id: massa-web3-utils
+title: Utils
+---
+
+### Massa Units
+
+All Massa values that are being used or returned by web3 (gas, fees, coins and rolls) are expressed via BigInt's. Massa-web3 has however a few convenience methods and converters that might come handy. Below is a summary of available methods:
+
+- Rolls: expressed in BigInt's. For Rolls there is no metric system as rolls are unit-less. 10 rolls is to be represented by a BigInt containing 10. Example:
+
+```ts
+const rolls = BigInt(10);
+// or. ...
+const rolls = 10n;
+```
+
+- Gas/MaxGas: expressed in BigInt's. For Gas/MaxGas there is no metric system as gas is unit-less. The gas represents the computational units required for a given operation to be executed by the network. Example:
+
+```ts
+const gas = BigInt(2000000);
+// or. ...
+const gas = 2000000n;
+```
+
+- Coins/Fees: expressed in BigInt's. Coins/fees do however have a metric system behind them. The smallest unit is 10**-9 Massa. All coins/fees are to be expressed as integers scaled by 10**9 and this way consumed by the network json-rpc protocol. Since gas/fees are to be used as BigInt's web3 adds in a few convenience utils allowing smaller units (e.g. 0.5 Massa) to be expressed.
+
+The util function `fromMAS` and `toMAS` are used exactly for the latter purpose. `fromMAS` receives any amount of type `number | string | BigNumber | bigint and returns a scaled bigint` for ready use. `toMAS` on the contrary converts any amount from `nanoMassa` to `Massa` and returns a `BigNumber` representing the amount as a decimal.
+
+Examples:
+
+```ts
+const coinsToTransfer = fromMAS("0.5"); // half a massa
+// or. ...
+const coinsToTransfer = 500n * MassaUnits.mMassa; // half a massa
+const coinsToTransfer = fromMAS("1"); // one massa
+// or. ...
+const coinsToTransfer = 1n * MassaUnits.oneMassa; // one massa
+```
+
+Web3 exposes a collection `MassaUnits` which has three convenience `BigInt` constants that could be used for amount scaling:
+
+- `MassaUnits.oneMassa` = $10^{9}$
+- `MassaUnits.mMassa` = $10^{6}$
+- `MassaUnits.uMassa` = $10^{3}$
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/networks-faucets/local-network.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/build/networks-faucets/local-network.mdx
new file mode 100644
index 000000000..51b77a4aa
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/networks-faucets/local-network.mdx
@@ -0,0 +1,92 @@
+---
+id: local-network
+sidebar_label: Local network (sandbox)
+---
+
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
+import VersionsTable from "@site/src/components/versions-table";
+
+# Local network generation
+Here, you will learn how to launch a local network with custom settings, initial coins and rolls distribution.
+
+This may be useful for instance if you want to build and test your integration on the latest version of the nodes.
+
+Clone massa:
+
+```bash
+git clone git@github.com:massalabs/massa.git
+```
+
+Compile it with the sandbox feature enabled:
+
+```bash
+cd massa && cargo build --release --features sandbox
+```
+
+Create a keypair in massa-client:
+
+```bash
+cd massa-client && cargo run
+wallet_generate_secret_key
+```
+
+For the rest of the tutorial we will use theses abbreviations:
+
+- `SECRETK`: The secret you just generated
+- `PUBK`: The public key corresponding to SECRETK
+- `ADDR`: The address corresponding to PUBK
+
+Setup your node to use the secret you just generated as its public key and staking key:
+- modify or create the file `massa-node/config/node_privkey.key`:
+
+ ```bash
+ {"secret_key":"SECRETK","public_key":"PUBK"}
+ ```
+
+- modify the file `massa-node/base_config/initial_ledger.json`:
+
+ ```javascript
+ {
+ "ADDR": {
+ "balance": "80000000",
+ "datastore": {},
+ "bytecode": []
+ }
+ }
+ ```
+
+- CLEAR and modify the file `massa-node/base_config/initial_rolls.json`:
+
+ ```javascript
+ {
+ "ADDR": 100
+ }
+ ```
+
+- CLEAR content of `massa-node/base_config/initial_vesting.json`:
+
+ ```javascript
+ {}
+ ```
+
+- You also have to modify the file `massa-node/base_config/config.toml` to match the same ChainID as a Sandbox node, as it defaults to the Mainnet ChainID of 77658377.
+ ```javascript
+ {
+ chain_id = 77
+ }
+ ```
+
+You can now launch your node:
+```bash
+cd massa-node && cargo run --features sandbox
+```
+
+On your client run the following command to add your secret key as staking key:
+
+```bash
+cd massa-client && cargo run node_start_staking ADDR
+```
+
+The local network and your node will start after 10 seconds. Once it is started, you can interact with it using the CLI
+client as you would with a node on a public network.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/networks-faucets/public-networks.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/build/networks-faucets/public-networks.mdx
new file mode 100644
index 000000000..ab90cf4eb
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/networks-faucets/public-networks.mdx
@@ -0,0 +1,107 @@
+---
+id: public-networks
+sidebar_label: Public networks & Faucets
+---
+
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
+import VersionsTable from "@site/src/components/versions-table";
+
+# Networks & Faucets
+
+Here's a handy table containing all you need to know about the different Massa networks and their faucets.
+
+
+
+
+
+
+
+:::note
+Each faucet allows for only one request per day.
+:::
+
+## What's a Network, Anyway?
+
+In the realm of blockchain technology, a network is a decentralized system of interconnected nodes.
+These nodes work in harmony to ensure the blockchain runs smoothly, validating transactions, adding them to the blockchain, and maintaining the integrity of the ledger.
+
+## What about Faucets?
+
+A faucet, in the context of blockchain, is a mechanism that provides small amounts of cryptocurrency to users for free.
+Think of it as a digital tap that drips a small portion of a specific cryptocurrency.
+
+Faucets play a crucial role in the blockchain ecosystem:
+
+- they offer a friendly introduction to new users by giving them a starting amount of cryptocurrency, and
+- they also aid developers in testing and building blockchain applications by providing the necessary tokens for experimentation.
+
+## What's Special About These Networks?
+
+### Mainnet
+
+The Massa Mainnet is the main network. It is the only Massa network for which MAS has a monetary value. As a result, no faucet is available for the Mainnet.
+
+### Buildnet
+
+The Massa Buildnet serves as your reliable playground for crafting and deploying smart contracts on the Massa blockchain. Buildnet follows a gradual upgrade cycle. This careful pace ensures its constant availability and stability - key factors that you, as a developer, rely on.
+
+At MassaLabs, we put significant effort into the careful maintenance of Buildnet. Our goal is to provide you with a platform where you can build robust, innovative applications.
+
+Leveraging Buildnet's unique features and capabilities, you can navigate the forefront of blockchain technology with confidence and peace of mind, knowing you have a stable and dependable environment for your projects.
+
+## Are There Any Requirements for Using Faucets?
+
+Sure! You'll need:
+
+- A Massa wallet (Don't have one yet? Generate addresses on the [Explorer website](https://massa.net/testnet/wallet))
+- A [Discord account](https://support.discord.com/hc/en-us/articles/360033931551-Getting-Started)
+
+## Library Compatibility with Massa Networks
+
+The following table outlines library compatibility across the Massa networks. Use this as a guide to select the appropriate library based on the network you're working with and your project needs.
+
+
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/sdk.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/build/sdk.mdx
new file mode 100644
index 000000000..541255424
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/sdk.mdx
@@ -0,0 +1,12 @@
+---
+id: tooling-versions
+title: Tooling Versions
+---
+
+import VersionsTable from "@site/src/components/versions-table";
+
+This table provides a concise overview of the different versions of our projects that are compatible with the different Networks.
+
+Take a look at the table below to identify the right version for your desired network.
+
+
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/smart-contract/_category_.json b/i18n/fr/docusaurus-plugin-content-docs/current/build/smart-contract/_category_.json
new file mode 100644
index 000000000..ad2d09dc0
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/smart-contract/_category_.json
@@ -0,0 +1,7 @@
+{
+ "position": 2,
+ "link": {
+ "type": "generated-index",
+ "description": "Punch line to do once everything else will be done for SC development."
+ }
+}
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/smart-contract/as-sdk.md b/i18n/fr/docusaurus-plugin-content-docs/current/build/smart-contract/as-sdk.md
new file mode 100644
index 000000000..d89e8e3fb
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/smart-contract/as-sdk.md
@@ -0,0 +1,46 @@
+---
+id: sdk
+sidebar_label: AS SDK
+---
+
+# AS-SDK
+
+AS-SDK is a software development kit designed specifically for Massa smart contracts written in AssemblyScript. It provides a set of functions and objects that wrap the ABIs exposed by the node.
+
+It includes several namespaces, each containing functions and objects that provide specific functionalities:
+
+## Coins
+
+The Coins namespace includes functions for interacting with wallet balances and transfers. For more information on this namespace, see the [AS-SDK Coins documentation](https://as-sdk.docs.massa.net/modules/Coins.html).
+
+
+
+## Context
+
+The Context namespace includes functions to interact with the execution context of a smart contract on the Massa blockchain. This namespace is particularly useful to retrieve information about the current state of a smart contract, such as the caller and callee of the current contract, the call stack, the amount of transferred coins, the remaining gas, and the timestamp. For more information on this namespace, see the [AS-SDK Context documentation](https://as-sdk.docs.massa.net/modules/Context.html).
+
+
+
+## Contract
+
+The Contract namespace includes functions to interact with other smart contract functions and manipulate their bytecode. This namespace is particularly useful to create new smart contracts and send messages to existing ones. For more information on this namespace, see the [AS-SDK Contract documentation](https://as-sdk.docs.massa.net/modules/Contract.html).
+
+
+
+## OpDatastore
+
+The OpDatastore namespace includes functions to interact with the operation datastore. This key/value storage can be filled by the operation creator and then used by the smart contract being executed. This namespace is particularly useful to read the data that is passed with the bytecode in an [execute smart contract operation](/docs/learn/architecture/basic-concepts#smart-contract-operations). For more information on this namespace, see the [AS-SDK OpDatastore documentation](https://as-sdk.docs.massa.net/modules/OpDatastore.html).
+
+
+
+## Storage
+
+The Storage namespace includes functions to interact with the key-value datastore. This namespace is particularly useful to read and write data that is expected to persist between contract executions, such as contract state or user information. For more information on this namespace, see the [AS-SDK Storage documentation](https://as-sdk.docs.massa.net/modules/Storage.html).
+
+
+
+## Utilities
+
+The Utilities namespace includes various utility functions, such as event generation, base58 encoding and decoding, and public key to address conversion. For more information on this namespace, see the [AS-SDK Utilities documentation](https://as-sdk.docs.massa.net/modules/Utilities.html).
+
+
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/smart-contract/intro.md b/i18n/fr/docusaurus-plugin-content-docs/current/build/smart-contract/intro.md
new file mode 100644
index 000000000..a8ddb4bb7
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/smart-contract/intro.md
@@ -0,0 +1,24 @@
+---
+sidebar_position: 1
+---
+
+
+# Introduction
+
+Smart contracts are programs that can interact with the blockchain, which can be viewed as a *decentralized database*. They allow developers to build decentralized applications (dApps) with controlled execution of contractual terms, where **code is law**.
+
+## But Technically, What is a Smart Contract?
+
+Smart contracts are human-readable code that can be compiled and deployed on a blockchain. In this context, a smart contract can be seen as a *stored procedure* that can modify the data, interact with other smart contracts, and can be called by end users.
+
+Thanks to the **asynchronous execution of smart contracts**, they can even automatically wake up at a specific time or when the ledger reaches a specific condition, such as the data of a smart contract having a specific value.
+
+## Limitations of Smart Contracts
+
+While smart contracts have many benefits, they also have limitations.
+
+For example, smart contracts:
+
+- Are small, and storage has a cost.
+- Have short execution times, and execution has a cost, often called gas, and there is a gas limit for a given slot.
+- Must be deterministic, which implies that all their parameters are public and they can only access information on the blockchain.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/smart-contract/prerequisites.md b/i18n/fr/docusaurus-plugin-content-docs/current/build/smart-contract/prerequisites.md
new file mode 100644
index 000000000..cf7bcc958
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/smart-contract/prerequisites.md
@@ -0,0 +1,32 @@
+---
+id: prerequisites
+sidebar_label: Prerequisites
+---
+
+# Prerequisites
+
+Before you can begin developing smart contracts on the Massa blockchain, you'll need to ensure that your development environment meets the following requirements:
+
+- [Node.js](https://nodejs.org/en/) installed on your system.
+
+
+:::tip
+We recommend updating Node.js and npm to the latest version for best performance and security.
+
+To update npm, run the following commands:
+```shell
+npm install -g npm
+```
+
+To update Node.js, the recommended way is to use `n`, the Node.js version manager.
+If you do not already have `n` installed, you can install it with the following command:
+```shell
+npm install -g n
+```
+Once `n` is installed, you can update to the latest version of Node.js with the following command:
+```shell
+n latest
+```
+:::
+
+Once you have an up-to-date Node.js, you're ready to start developing smart contracts on the Massa blockchain.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/smart-contract/webassembly-module.md b/i18n/fr/docusaurus-plugin-content-docs/current/build/smart-contract/webassembly-module.md
new file mode 100644
index 000000000..68a98e14d
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/smart-contract/webassembly-module.md
@@ -0,0 +1,28 @@
+---
+id: webassembly-module
+sidebar_label: WebAssembly Module
+---
+
+# WebAssembly Module
+
+Each smart contract is a WebAssembly module with exported functions, and has access to specific node ABIs. We will see these ABIs in the next chapter.
+
+WebAssembly code is compiled from AssemblyScript, a language created specifically for WebAssembly.
+
+AssemblyScript is very similar to TypeScript, but there are some important differences to keep in mind.
+For example, the basic types in AssemblyScript directly expose all integer and floating-point types available in WebAssembly.
+Union types and optional arguments/properties are not supported in AssemblyScript, and all objects are statically typed and do not allow for dynamically changing properties.
+Additionally, AssemblyScript does not support exceptions catching or closures yet.
+
+To learn more about AssemblyScript, WebAssembly modules, and ABIs, we invite you to check out the following resources:
+
+- [AssemblyScript home page](https://assemblyscript.org/), [its book](https://www.assemblyscript.org/introduction.html) and [its introduction from a JS perspective](https://www.assemblyscript.org/introduction.html#from-a-javascript-perspective).
+- [WebAssembly home page](https://webassembly.org/) and [MDN version](https://developer.mozilla.org/en-US/docs/WebAssembly).
+- [Wikipedia explaination of the concept of ABI](https://en.wikipedia.org/wiki/Application_binary_interface).
+
+:::caution
+Do not initialize a smart contract project following AssemblyScript documentation. It will be unnecessarily painful. Go back to the the ["Hello, World" dApp tutorial](/docs/build/hello-world-dapp) or use the following command:
+```shell
+npx clear-npx-cache && npx @massalabs/sc-project-initializer@buildnet init my-first-sc && cd my-first-sc
+```
+:::
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/standards.md b/i18n/fr/docusaurus-plugin-content-docs/current/build/standards.md
new file mode 100644
index 000000000..afbb47d68
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/standards.md
@@ -0,0 +1,37 @@
+---
+id: standards
+sidebar_label: Standards
+---
+
+# Massa Standard
+
+The Massa Standard is your comprehensive starting point for blockchain projects on the Massa network. Offering reference implementations of the most common smart contracts, it's the toolkit you need for tokens, NFTs, or wallet creation.
+
+Adhering to a standard like this in the blockchain world is important. Standards ensure all participants in a blockchain network can interact seamlessly because they follow a unified structure and protocol. This compatibility fosters a more robust and inclusive blockchain ecosystem, encouraging mass adoption and facilitating growth.
+
+## Fungible Tokens (FT)
+
+FT is a standard for creating fungible, tradable tokens on the Massa blockchain. It includes a set of functions that allow for seamless interaction with tokens within smart contracts and wallets.
+
+[View on GitHub](https://github.com/massalabs/massa-standards/tree/main/smart-contracts/assembly/contracts/FT)
+
+## Non-Fungible Tokens (NFT)
+
+NFT is a standard for creating unique, non-fungible tokens on the Massa blockchain. This allows the creation and management of tokens where each instance has a unique value or properties.
+
+[View on GitHub](https://github.com/massalabs/massa-standards/tree/main/smart-contracts/assembly/contracts/NFT)
+
+## Massa Domain Name Service (DNS)
+
+The DNS standard provides a foundational framework for managing Domain Name System (DNS) records within the Massa blockchain ecosystem. It streamlines the creation of a link between the hostname (website name), resolver address (where the smart contract and chunks of the website are located), and the DNS record owner.
+
+## Massa Units Standard
+The Massa Units standard defines common units of measurement for the Massa blockchain, including:
+
+- Massa coin
+
+- Gas
+
+- Rolls
+
+Learn more about [Massa Units Standard](https://github.com/massalabs/massa-standards/blob/main/units.md)
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/wallet/community-wallets.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/build/wallet/community-wallets.mdx
new file mode 100644
index 000000000..f8f53f790
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/wallet/community-wallets.mdx
@@ -0,0 +1,8 @@
+---
+id: community-wallets
+title: Community Wallets
+---
+
+| Name | Description |
+| ---- | ----------- |
+| [Bearby](https://bearby.io/) | Bearby provides a simple way to Connect any website to the Massa ecosystem. |
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/wallet/intro.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/build/wallet/intro.mdx
new file mode 100644
index 000000000..5e61977b0
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/wallet/intro.mdx
@@ -0,0 +1,21 @@
+---
+sidebar_position: 1
+---
+
+# Introduction
+
+A wallet is a fundamental tool for interacting with the blockchain.
+Consider it your digital identity, enabling you to send, receive, and manage assets on a blockchain.
+
+There are several wallets available that are compatible with the Massa blockchain.
+These wallets allow you to securely interact with the blockchain, including sending, receiving, and managing assets
+
+## Wallet Providers
+
+Here is a list of available wallet providers for the Massa blockchain:
+
+- [Massa Wallet](/docs/build/wallet/massa-wallet): Massa Station is an official wallet developed by the Massa team. It provides a user-friendly interface and robust security features.
+
+- [Community Wallets](/docs/build/wallet/community-wallets): Community wallets are developed and maintained by the Massa community. These wallets can vary in features and interfaces.
+
+- [Wallet Provider](/docs/build/wallet/wallet-provider): Wallet Provider offers a secure, reliable, and versatile wallet that supports the Massa blockchain.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/wallet/massa-station.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/build/wallet/massa-station.mdx
new file mode 100644
index 000000000..b17629dac
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/wallet/massa-station.mdx
@@ -0,0 +1,11 @@
+---
+id: massa-wallet
+title: Massa Wallet
+---
+
+# Massa Wallet
+
+[Massa Wallet](https://github.com/massalabs/station-massa-wallet) is a plugin for Massa Station that allows you to
+store your assets and interact with decentralized applications. It is the recommended way to interact with the Massa blockchain.
+
+Follow the link to [get started with Massa Wallet](/docs/massaStation/massa-wallet/getting-started) !
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build/wallet/wallet-provider.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/build/wallet/wallet-provider.mdx
new file mode 100644
index 000000000..95418944a
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/build/wallet/wallet-provider.mdx
@@ -0,0 +1,6 @@
+---
+id: wallet-provider
+title: Wallet Provider
+---
+
+This page should document the wallet provider package.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/Unlocked.png b/i18n/fr/docusaurus-plugin-content-docs/current/learn/Unlocked.png
new file mode 100644
index 000000000..118946da2
Binary files /dev/null and b/i18n/fr/docusaurus-plugin-content-docs/current/learn/Unlocked.png differ
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/architecture.drawio.svg b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/architecture.drawio.svg
new file mode 100644
index 000000000..7d619417c
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/architecture.drawio.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/basic-concepts.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/basic-concepts.mdx
new file mode 100644
index 000000000..24ca015d9
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/basic-concepts.mdx
@@ -0,0 +1,357 @@
+---
+id: basic-concepts
+sidebar_label: Basic concepts
+---
+
+# Basic concepts
+
+Let's dive into the basic definitions and concepts of Massa blockchain.
+
+The goal of the Massa network is to build a consensus between **nodes** to gather
+and order **blocks** that contain ordered lists of **operations**.
+An operation ultimate purpose once executed is to act as transitions for the global network state, called the **ledger**.
+
+Operations are produced by external clients and sent to the Massa network via a node.
+Some operations are containing code to be run as **smart contracts**, enabling complex programmatic
+modifications of the ledger.
+Nodes gather pending operations and group them into blocks. Each block has limited space to store operations.
+Traditional blockchains typically link blocks sequentially, including a hash of the previous block in the block
+header for temporal ordering. In contrast, Massa blocks are organized into a complex spatio-temporal structure,
+enabling parallelization and improved block-creation performance.
+
+Instead of one chain, there are exactly 32 **threads** of chains running in parallel, with blocks equally
+spread on each thread over time, and stored inside **slots** that are spaced at fixed time intervals:
+
+
+
+The time between two slots located on the same thread is called a **period** and lasts 16s (conventionally called $t_0$).
+Corresponding slots in threads are slightly shifted in time relative to one another, by one period divided by the number
+of threads, which is $16s/32 = 0.5s$, so that a period contains exactly 32 slots equally spaced over the 32 threads.
+A **cycle** is defined as the succession of 128 periods and so lasts a bit more than 34min. Periods are numbered by
+increments of one, so can be used together with a thread number to uniquely identify a block slot. Period 0 is the
+genesis and contains genesis blocks with no parents.
+
+The job of the Massa nodes network is to essentially collectively fill up slots with valid blocks. To do so,
+at each interval of 0.5s, a specific node in the network is elected to be allowed to create a block (more about
+the selection process and the proof of stake sybil resistance mechanism [here](/docs/learn/architecture/node-architecture#selector-module-proof-of-stake-sybil-resistance)),
+ and will be rewarded if it creates a valid block in time. It is also possible that a node misses its opportunity
+ to create the block, in which case the slot will remain empty (this is called a **block miss**).
+
+In traditional blockchains, blocks are simply referencing their unique parent, forming a chain. In the case of
+Massa, each block is referencing one parent block in each thread (so, 32 parents). Here is an example
+illustrated with one particular block:
+
+
+
+Let’s introduce some relevant definitions and concepts generally necessary to understand how the Massa network operates.
+We will then explain the node architecture and how the whole system works.
+
+## Ledger
+
+The ledger is a map that stores a global mapping between addresses and information related to these addresses.
+It is replicated in each node. The consensus building mechanism ensures that agreement on what operations have
+been finalized (and in what order) will be reached over the whole network. The ledger is the state of the Massa network,
+and operations (see below) are requests to modify the ledger.
+
+
+The information stored in the ledger with each address is the following:
+
++-------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| Ledger Information Associated with Each Address |
++=============+=================================================================================================================================================================================+
+| `balance` | The amount of Massa coins owned by the address. |
++-------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| `bytecode` | When the address references a smart contract, this is the compiled code corresponding to the smart contract (typically contains several functions that act as API entry points).|
++-------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| `datastore` | A key/value map that can store any persistent data related to a smart contract, its variables, etc. |
++-------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+
+
+In order to promote widespread adoption and facilitate node running with reduced entry fees, the size of the ledger in Massa
+has been limited to a maximum of 1 TB.
+This decision sets Massa apart from other benchmark blockchain ledgers and makes it more accessible to users.
+
+To achieve such a small ledger size, several technical decisions were made.
+Firstly, state changes that have been finalized and are found in the final Blocks no longer require record-keeping in the Ledger's memory.
+This optimization helps minimize the storage requirements for historical data, allowing the ledger to operate efficiently within the specified size limit.
+
+In addition to this, Massa has introduced [Storage Costs](/docs/learn/storage-costs) as a novel approach to enhance storage efficiency.
+Users are now required to lock a certain amount of coins when they claim storage space.
+This innovative correlation between storage and circulating coins ensures a balanced utilization of resources.
+By implementing this mechanism, Massa optimizes storage utilization while maintaining the integrity and security of the ledger.
+
+These technical decisions, including the exclusion of finalized state changes from ledger memory and the introduction of Storage
+Costs, play a crucial role in enabling the compact size of the ledger and ultimately facilitating a more efficient and accessible
+blockchain ecosystem.
+
+## Address
+
+An address on the Massa blockchain serves as your unique identity, granting you the ability to engage in various operations,
+store information, and exchange data with other participants. With an address, you gain access to a wide range of functionalities
+within the blockchain ecosystem.
+
+Using your address, you can initiate operations that interact with the blockchain.
+This includes executing transactions, submitting smart contract calls, and engaging in other blockchain activities.
+Your address acts as the key to unlock these capabilities, allowing you to participate fully in the decentralized network.
+
+Furthermore, your address enables you to store and retrieve information on the blockchain. Whether it's personal data, financial records, or any other form of digital information, you can securely store it using your address as the reference. This provides a reliable and immutable storage solution within the blockchain environment.
+
+Importantly, your address also facilitates communication and data exchange with other participants on the blockchain.
+By sharing your address with others, you can interact, transact, and collaborate with different individuals and entities
+within the blockchain network.
+This seamless exchange of data and value promotes a decentralized and interconnected ecosystem.
+
+
+Each user address on Massa has a public and private key associated with it.
+This is how messages can be signed and identity enforced.
+The address of an account is simply the hash of its public key.
+
+
+Addresses are generated using a specific format that includes a prefix `A` and a base58 encoding. The prefix distinguishes between user addresses, linked to a KeyPair, and smart-contract addresses, denoted by the prefixes `U` or `S` respectively.
+
+For user addresses (AU), the hash calculation involves taking the Blake3 hash of the byte representation of
+the user's public key.
+This process ensures a unique and secure identification for each user address within the system.
+
+## Smart Contract
+
+Smart contracts are a piece of code that can be run inside the Massa virtual machine, which can modify the ledger,
+and accept incoming requests through a public interface (via smart-contract operations).
+
+Smart contracts are currently written in AssemblyScript, a derivation from TypeScript, which is itself a
+type-safe version of JavaScript. AssemblyScript compiles to WebAssembly bytecode (wasm). Massa nodes Execution Module runs such bytecode.
+Smart contracts have access to their own datastore, so they can modify the ledger.
+
+Smart contracts follow a different hash calculation than user addresses. It begins by constructing a byte array comprising various elements.
+This array consists of the slot represented in 5 bytes, with 4 bytes allocated for the period (encoded as a u64 in big endian
+format), 1 byte for the thread, and an index that increments for each address created within the same slot.
+The index value is represented as a u64 in big endian format and is reset at the start of each new slot.
+Additionally, a single byte is appended to indicate whether the address is for real execution (1) or read-only execution (0).
+
+The resulting byte array is then subject to the Blake3 hash function, generating a unique
+hash value that serves as the SC address.
+
+### Autonomous Smart Contract Execution
+
+One particularity of Massa smart contracts compared to other blockchain smart contracts is their ability to wake
+up by themselves independently of an exterior request on their interface. We call them Autonomous Smart Contracts (ASCs),
+as they allow more autonomy and less dependency on external centralized services.
+
+ASCs offer a plethora of use cases that leverage their self wake-up functionality.
+In the realm of Decentralized Finance (DeFi), these contracts can automate liquidations,
+yield farming strategies, and portfolio rebalancing.
+Supply chain management benefits from autonomous contracts through automated inventory management and quality control processes.
+In the insurance industry, claims settlements can be accelerated with instant payments and parametric insurance.
+Gaming and NFT platforms can provide dynamic and interactive experiences with evolving NFTs and automated auctions.
+Additionally, real estate transactions can be streamlined with escrow automation and simplified rental agreements.
+These use cases exemplify the transformative potential of Autonomous Smart Contracts in enabling automated and efficient
+processes across various industries.
+
+:::info
+Learn more about Autonomous Smart Contracts [here](/docs/learn/asc/intro).
+:::
+
+## Storage costs
+
+In Massa, each network node maintains a full copy of the ledger. Having a massive ledger size (hundreds of terabytes), would pose high entry barriers for potential node runners. To ensure smooth operation and enable node hosting at home, it's essential to establish a reasonable size limit, and remove the need for excessive storage capacity. After careful consideration, we have determined that a storage size limit of 1TB strikes the right balance. This means that each participant can store data on the ledger until it reaches the 1TB threshold. By implementing this limit, we aim to promote widespread adoption and empower individuals to run nodes effortlessly.
+
+In order to enforce this limit, users are required to lock a corresponding amount of coins for each byte of storage they claim. This applies to various data elements such as your address, balance, keys in your datastore, bytecode, and more. By locking coins, you establish a commitment that ensures fair usage of storage resources. Once you release your allocated space in the storage, the locked coins are subsequently released as well. This mechanism guarantees a balanced and accountable approach to managing storage within the network.
+
+:::note
+Read more about storage costs [here](/docs/learn/storage-costs).
+:::
+
+
+## Gas
+
+In Massa, there is no Gas price.
+Each operation declares a max amount of gas that it can use, and provides a fee that is added to the rewards of the block in which the operation is executed.
+
+Block producers then choose which operations to include in their blocks to fit the max block gas and max block size constraints while maximizing the total fee.
+
+:::note
+Read more about gas [here](/docs/learn/gas).
+:::
+
+## Block
+
+A block is a data structure built by nodes and its function is to aggregate several operations. As explained above,
+for each new slot that becomes active, a particular node in the network is elected in a deterministic way with the
+task of creating the block that will be stored in that slot (more about this in the description of the Selector
+Module below). A block from a given thread can only contain operations originating from a creator_public_key whose
+hash’s five first bits designate the corresponding thread, thus implicitly avoiding collisions in operations integrated into parallel threads. Block size is limited to 1 MB.
+
+The content of a block is as follows:
+
+
+
+
Block header
+
+
+
slot
+
A description of the block slot, defined by a couple (period, thread) that uniquely identify it
+
+
+
creator_public_key
+
The public key of the block creator (32 bytes)
+
+
+
parents
+
A list of the 32 parents of the block, one parent per thread (parent blocks are identified by the block hash)
+
+
+
endorsements
+
A list of the 16 endorsements for the block (more about endorsements below)
+
+
+
operations_hash
+
A hash of all the operations included in the block (=hash of the block body below)
+
+
+
signature
+
Signature of all the above with the private key of the block creator
+
+
+
Block body
+
+
+
operations
+
The list of all operations included in the block
+
+
+
+## Operation
+
+At its core, the Massa network revolves around the aggregation, sequencing, and execution of operations. Operations are
+recorded inside blocks that are located in slots.
+
+Operations are denoted by a string prefixed with 'O' that encapsulate crucial information within a byte array.
+The byte array encompasses the version in a u64 varint format, the Blake3 hash of the fully serialized content
+of the operation, and the public key of the creator.
+By meticulously organizing and recording operations within blocks that reside in specific slots,
+the Massa network ensures the integrity and efficiency of its operations.
+
+
+### Operation types
+
+There are three types of operations: transactions, roll operations, and smart contract code execution.
+The general structure of an operation is the following, and the different types of operations differ by their payload:
+
++---------------------+------------------------------------------------------------+------------------+
+| Transaction Binary Representation |
++---------------------+------------------------------------------------------------+------------------+
+| Field | Description | Type |
++=====================+============================================================+==================+
+| `creator_public_key`| The public key of the operation creator | 32 bytes |
++---------------------+------------------------------------------------------------+------------------+
+| `expiration_period` | Period after which the operation is expired | u64 varint |
++---------------------+------------------------------------------------------------+------------------+
+| `fee` | The amount of fees the creator is willing to pay | u64 varint |
++---------------------+------------------------------------------------------------+------------------+
+| `type` | The type of operation | u64 varint |
+| | (from 0 to 4: transaction, rollbuy, rollsell, executesc, | |
+| | callsc) | |
++---------------------+------------------------------------------------------------+------------------+
+| `payload` | The content of the operation |see each operation|
++---------------------+------------------------------------------------------------+------------------+
+| `signature` | Signature of all the above with the private key of the | 64 bytes |
+| | operation creator | |
++---------------------+------------------------------------------------------------+------------------+
+
+
+#### Transaction operations
+
+Transactions are operations that move native Massa coins between addresses. Here is the corresponding payload:
+
++---------------------+----------------------------------+----------------------+
+| Transaction Payload Binary Representation |
++---------------------+----------------------------------+----------------------+
+| Field | Description | Type |
++=====================+==================================+======================+
+| `amount` | The amount of coins to transfer | u64 varint |
++---------------------+----------------------------------+----------------------+
+|`destination_address`| The address of the recipient | 32 bytes |
++---------------------+----------------------------------+----------------------+
+
+
+#### Buy/Sell Rolls operations
+
+Rolls are staking tokens that participants can buy or sell with native Massa coins. By owning rolls,
+addresses can participate in block creation [more about staking below](/docs/node/stake).
+This is done via special operations, with a simple payload:
+
++---------------------+-----------------------------------+-------------------+
+| Buy/Sell Rolls Payload Binary Representation |
++---------------------+-----------------------------------+-------------------+
+| Field | Description | Type |
++=====================+===================================+===================+
+| `nb_of_rolls` | The number of rolls to buy or sell| u64 varint |
++---------------------+-----------------------------------+-------------------+
+
+#### Smart Contract operations
+
+Smart Contracts are pieces of code that can be run inside the Massa virtual machine. There are two ways
+of calling for the execution of code; by direct execution of bytecode, and by a smart-contract function call.
+Former is done using the Execute SC operation, and latter with Call SC operation.
+
+1. Execute SC operation
+
+ The ExecuteSC operation provides a powerful functionality within the Massa network by enabling the execution of smart contracts
+ directly instead of storing them.
+ Instead of storing the bytecode, the code itself is placed within the operation as a smart contract.
+ When the ExecuteSC operation is executed, the blockchain triggers the execution of the main function within
+ the smart contract code. After the code is executed, the blockchain proceeds to other tasks while retaining
+ and reflecting the changes made to the ledger and other relevant data.
+ This approach ensures that the executed changes are recorded and maintained on the ledger, rather than
+ retaining the bytecode itself.
+ By executing smart contracts in this manner, the Massa network offers flexibility and efficiency
+ in managing and executing code within its blockchain ecosystem.
+
++---------------------------+---------------------------------------------------------------------------------------------------------------------+-------------------+
+| Execute SC Payload Binary Representation |
++---------------------------+---------------------------------------------------------------------------------------------------------------------+-------------------+
+| Field | Description | Type |
++===========================+=====================================================================================================================+===================+
+| `max_gas` | The maximum gas spendable for this operation | u64 varint |
++---------------------------+---------------------------------------------------------------------------------------------------------------------+-------------------+
+| `bytecode_len` | The length of the bytecode field | u64 varint |
++---------------------------+---------------------------------------------------------------------------------------------------------------------+-------------------+
+| `bytecode` | The bytecode to run (in the context of the caller address) | |
++---------------------------+---------------------------------------------------------------------------------------------------------------------+-------------------+
+| `datastore_len` | The number of the datastore keys (u64 varint), each record is then stored one after another | u64 varint |
++---------------------------+---------------------------------------------------------------------------------------------------------------------+-------------------+
+| list of datastore records | Concatenation of `key_len` (u8), `key`, `value_len` (u64 varint), `value` | |
++---------------------------+---------------------------------------------------------------------------------------------------------------------+-------------------+
+
+
+2. Call SC operation
+
+Here, the code is indirectly called via the call to an existing smart contract function, together with the required parameters:
+
++------------------------+------------------------------------------------------+------------------+
+| Call SC Payload Binary Representation |
++------------------------+------------------------------------------------------+------------------+
+| Field | Description | Type |
++========================+======================================================+==================+
+| `max_gas` | The maximum gas spendable for this operation | u64 varint |
++------------------------+------------------------------------------------------+------------------+
+| `coins` | The coins transferred in the call | u64 varint |
++------------------------+------------------------------------------------------+------------------+
+| `target_address` | The address of the targeted smart contract | 32 bytes |
++------------------------+------------------------------------------------------+------------------+
+| `function_name_length` | The length of the name of the function that is called| u8 |
++------------------------+------------------------------------------------------+------------------+
+| `function_name` | The name of the function that is called | utf8 |
++------------------------+------------------------------------------------------+------------------+
+| `param_len` | The number of parameters of the function call | u64 varint |
++------------------------+------------------------------------------------------+------------------+
+| `params` | The parameters of the function call | |
++------------------------+------------------------------------------------------+------------------+
+
+### Endorsements
+
+Endorsements are optionally included in the block, but their inclusion is incentivized for block creators. They are
+validations of the fact that the parent block on the thread of the block is the best parent that could have been
+chosen, done by other nodes that have also been deterministically selected via the proof of stake probability
+distribution. A comprehensive description of endorsements can be found [here](/docs/learn/architecture/consensus-quality#endorsement), so we will
+not go further into details in the context of this introduction.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/block_parents.drawio.svg b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/block_parents.drawio.svg
new file mode 100644
index 000000000..c90fc3782
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/block_parents.drawio.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/cliques.drawio.svg b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/cliques.drawio.svg
new file mode 100644
index 000000000..4d6d8c47b
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/cliques.drawio.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/consensus-quality.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/consensus-quality.mdx
new file mode 100644
index 000000000..f0b23abef
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/consensus-quality.mdx
@@ -0,0 +1,77 @@
+---
+id: consensus-quality
+sidebar_label: Consensus quality initiatives
+---
+# Consensus quality initiatives
+
+This section describes the mechanisms we use to maximize the consensus quality on Massa blockchain.
+
+## Endorsement
+
+Massa uses the Proof-of-Stake selection mechanism with Nakamoto consensus. In that context, when there are multiple cliques
+in close competition, we want all nodes to converge towards a single clique as fast as possible to minimize finality time
+and maximize the quality of the consensus. To achieve this, we draw inspiration from Tezos and introduce the concept of Endorsement.
+
+Each block header in Massa contains $E$ ordered endorsement slots. An endorsement includes the slot it belongs to, the hash
+of the endorsed block, the endorsement slot index, the creator's public key, and a signature. At each slot, a Proof-of-Stake
+selection mechanism chooses the block creator and E other stakers who can create endorsements for that slot. Endorsements can
+be seen as votes endorsing the parent block in the corresponding thread.
+
+The attacker's likelihood of consecutive PoS draws decreases exponentially. With endorsements, $E+1$ draws occur at each slot,
+increasing safety and convergence speed. The consensus algorithm selects the clique with the highest fitness as the blockclique, where
+the fitness is determined by the number of PoS draws involved in creating the block. This mechanism enhances safety and convergence
+speed by allowing block producers to select the best clique based on the endorsements' "votes."
+
+### Endorsement structure
+
+Note that the *WrappedEndorsement* structure includes the underlying *Endorsement* as well as the signature,
+and the public key of the endorsement producer.
+
+Within a block, endorsements are fully included inside the header.
+
+A header is invalidated if:
+
+- it contains strictly more than *E* endorsements
+- at least one of the endorsements fails deserialization or signature verification
+- at least one of the endorsements endorses a block different than the parent of the including block within its own thread
+- any of the endorsements should not have been produced at that (*endorsement.slot*, *endorsement.index*) according to the selector
+- there is strictly more than one endorsement with a given *endorsement.index*
+
+```rust
+pub struct Endorsement {
+ /// slot in which the endorsement can be included
+ pub slot: Slot,
+ /// endorsement index inside the including block
+ pub index: u32,
+ /// Hash of endorsed block.
+ /// This is the parent in thread `self.slot.thread` of the block in which the endorsement is included
+ pub endorsed_block: BlockId,
+}
+```
+
+### Endorsement lifecycle
+To create endorsements for a specific slot $S$, the Endorsement Factory wakes up at a certain timestamp and checks
+the endorsement producer draws for that slot. The factory asks Consensus for the latest blockclique block with a lower period than S.period to choose the block to endorse.
+The created endorsements are sent to the Endorsement Pool for future inclusion in blocks and propagated through the
+Protocol to other nodes.
+
+In the Protocol, endorsements can be received from other modules or nodes. Received endorsements are propagated and added
+to the Endorsement Pool if they are not already known. The Endorsement Pool stores a limited number of endorsements that
+can potentially be included in future blocks. Consensus notifies the Endorsement Pool of newly finalized blocks, allowing
+it to remove endorsements that can only be included in already-finalized slots.
+
+When the Block Factory produces a block and needs to include endorsements in its header, it requests the Endorsement Pool
+for the endorsements that endorse the block's parent in its thread and can be included in the block's slot.
+
+### Incentives and penalties
+To incentivize the creation and endorsement of blocks, as well as the inclusion of endorsements in blocks, a revenue split is implemented. The total revenue generated by a block, denoted as $R$, is divided into $1+E$ equal parts, where $E$ is the number of endorsements.
+
+Each part, denoted as $r$, is distributed as follows:
+
+- The block creator receives $r$ to motivate block creation, even without endorsements.
+- For each successfully included endorsement:
+ - The block creator receives $r/3$ to incentivize endorsement inclusion.
+ - The endorsement creator receives $r/3$ to motivate endorsement creation.
+ - The creator of the endorsed block receives $r/3$ to encourage timely block emission for endorsement.
+
+This revenue split increases the frequency at which stakers receive coins, reducing the need for staking pools.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/incompatibility_graph.drawio.svg b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/incompatibility_graph.drawio.svg
new file mode 100644
index 000000000..eaec7f6ce
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/incompatibility_graph.drawio.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/node-architecture.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/node-architecture.mdx
new file mode 100644
index 000000000..75bdb816a
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/node-architecture.mdx
@@ -0,0 +1,242 @@
+---
+id: node-architecture
+sidebar_label: Node architecture
+---
+
+# Architecture of Massa node
+
+:::note
+This section assumes some basic knowledge of the Massa protocol. If you are not familiar with the basic concepts of Massa,
+read the [Basic Concepts](/docs/learn/architecture/basic-concepts) section first.
+:::
+
+The section describes the global architecture of a Massa node, from the ground up.
+
+This is the diagram of the architecture of the software modules involved in building, endorsing and propagating blocks.
+The bottom part corresponds to a single process running in a node and is in charge of the execution and consensus building.
+The pool and factories, referred to as “factory”, can be potentially running in a different process or be part of the node.
+Overall, each of the modules described here runs inside one or more threads attached to their respective executable process
+(NB: the factory/node separation is not yet implemented, but will be soon).
+
+
+
+We will explain below the different modules present in this diagram, and simulate the production of an operation to show
+how it navigates through the different modules to better understand how blocks are produced and propagated.
+
+## Bootstrap Module
+
+The bootstrap module is responsible for the initial synchronization of the node with the rest of the network. It is responsible
+for downloading the list of peers, the current graph of blocks, the ledger, the asynchronous pool, state of the Proof-of-Stake
+and latests executed operations.
+
+The bootstrap will be done from a server that is listed on the configuration of the node. Bootstrap is the entry point of the
+network so you have to be careful on which node you connect to avoid downloading malicious data.
+
+## API Module
+
+The API Module is the public window of the node to the rest of the world. It allows for interactions with external clients or
+factories via a [JSON RPC](/docs/build/api/jsonrpc) and [gRPC](/docs/build/api/grpc) protocols.
+
+The API includes interfaces to do the following:
+
+- publish a new operation from a client
+- query the network about balances or ledger status
+- allow for synchronization between remote pool/factory nodes and the consensus nodes, by sending/asking for blocks, best
+ parents, draws, etc.
+
+## Protocol/Network Module
+
+The Protocol/Network Module implements the protocol connecting consensus nodes. This protocol is supported by a binary and optimized transport layer.
+
+The Protocol/Network Module will relay all operations/blocks creation and propagation, so that all other nodes in the
+network can synchronize their internal state, following a type of gossip synchronization protocol.
+
+The type of messages that can be relayed via the Protocol/Network Module include:
+
+- blocks/operations/endorsements propagation (either getting in or out of the node)
+- nodes ban requests
+- connectivity infos/stats.
+
+## Selector Module, Proof of Stake sybil resistance
+
+Every 0.5s, a new slot becomes active to receive a new block. A determinist selection mechanism ensures that one of
+the nodes in the network is elected to have the responsibility to build the block for that slot. This mechanism must have several key properties:
+
+- it should be sybil resistant, so that it is not possible to increase one’s odds of being elected by creating multiple
+ clones of oneself (sybil) without a cost that is equal or greater than the cost of increasing one’s odds for oneself only;
+
+- it should be deterministic, so that all nodes in the network will agree on the result of the selection at any given time;
+
+- it should be fair, so that each participant has a well-defined probability of being selected somehow proportional to
+ the cost of participating, and draws converge towards this probability distribution over time.
+
+The way sybil resistance is achieved here is via the proof of stake mechanism. Nodes who want to participate in the block
+creation lottery will have to stake “rolls” that they buy with Massa coins. If they try to cheat by creating fake blocks
+or multiple blocks on the same slot, their stake will be taken away from them (slashing) and they would suffer the loss.
+The probabilistic “surface” of a participant is equal to its total stake, which makes the creation of sybil accounts useless
+because the stake would have to be split between them anyway.
+
+:::note
+More about slashing mechanism [here](/docs/learn/architecture/consensus-quality#slashing)
+:::
+
+The method used to draw an elected node for a given slot is simply a random draw from a distribution where addresses are
+weighted by the amount of stake (=rolls) they hold. The schema below illustrates how the seed and probability distribution
+are built, based on past cycles (two cycles are needed for the distribution update to ensure that the balance finalization
+has occurred and the amount of rolls is accurate):
+
+
+
+The Selector Module is in charge of computing the formula and replying to requests regarding what node is elected for any
+given slot in the present or the past. The Execution Module (see below) is in charge of feeding the Selector Module with
+updates regarding balances, needed to compute the draws.
+
+## Graph/Consensus Module
+
+The Consensus Module is the heart of the machinery of the Massa Network. It is in charge of integrating proposed blocks
+into their respective slots and verifying the integrity of the result. We have not yet talked about the various constraints
+regarding block creation, and in particular how parents are to be selected. In traditional blockchains, the parent of a
+block is simply the previous valid block in the chain. In the context of the Massa network and the parallel chains in the
+32 threads, identifying the proper parent in a given thread requires a more sophisticated strategy involving the notion of block cliques.
+
+### Block cliques
+
+At any given time, the set of all the blocks that have been produced and propagated in the network constitutes a graph (more precisely
+a Directed Acyclic Graph or “DAG”), where each block, except the genesis blocks, has 32 parents. All the reasoning below can be in
+principle done on this increasingly vast set, but in practice, we will introduce a notion of “finalized” or “staled” blocks, that
+can be removed from the set and that will allow us to work on a smaller subset of recent blocks that are neither finalized nor
+staled, so “pending” blocks. This set of pending blocks is all the network needs to know in order to incrementally build up a
+consensus, therefore non-pending blocks will simply be forgotten (this is a striking difference with most other blockchains
+that store in each node the history of all past transactions). The main benefit of this block pruning is to allow for some of
+the algorithms below, which are in general NP-complete, to run fast enough on a smaller subgraph, and to allow for a practical implementation.
+
+Here is a simplified example of a graph of pending blocks over two threads, with blocks 3 and 4 competing for slot C1 (for example
+as a result of a multistaking attack where the block producer decided to create competing blocks for the same slot). Here the
+letter of a slot identifies it, while the number refers to its thread number:
+
+
+
+In this illustration we have shown only relevant parent links in blue, to make the whole diagram more readable, but in reality,
+each block has 32 parents, one in each of the 32 threads.
+
+An important notion we will use in the following is that of incompatibility between blocks. Excluding some edge cases with genesis
+blocks, there are two sources of incompatibilities defined for blocks:
+
+1. **thread incompatibility**: this occurs when two blocks in a given thread have the same parent in that thread.
+2. **grandpa incompatibility**: this corresponds to a case with two blocks B1 and B2 in threads t1 and t2, and where the block
+ B1 in t1 has a parent in t2 who is an ancestor of B2’s parent in t2, and symmetrically B2’s parent in t1 is an ancestor of
+ B1’s parent in t1.
+
+:::tip
+You will find a more formal mathematical definition of these incompatibility notions in the [whitepaper](https://arxiv.org/pdf/1803.09029.pdf)
+:::
+
+From these definitions, you can build another graph, called the incompatibility graph, which connects any two blocks that
+have any form of incompatibility together:
+
+
+
+As you can see, some blocks are isolated and therefore compatible with any other, while some are linked, because they have
+a form of incompatibility.
+
+This brings us to the notion of a maximal clique which is a subset of the incompatibility graph such as none of the block
+members are incompatible with each other (so, no internal link within the clique), and it is impossible to add an extra block
+to the set without introducing incompatibilities. In the above example, there are three maximal cliques that can be built,
+as illustrated below:
+
+
+
+They represent candidates to extend the set of already finalized blocks into a coherent set of new blocks. All we need to
+add to be able to build a consensus rule now is to introduce a deterministic metric to rank those candidates so that nodes
+can independently and consistently decide on which clique is the best candidate and keep building on top of it. In particular,
+once the best maximal clique is identified, it becomes trivial to define the list of the parents for a new block simply by
+picking the oldest block from that clique in each thread.
+
+The metric used in a traditional blockchain to rank competing chain candidates is habitually the length of the chain, or more
+precisely the total amount of work invested in the chain (also known as “Nakamoto consensus”). In the case of block cliques,
+we will introduce a notion of fitness for each block, and the fitness of the clique will simply be the sum of all its block’s
+fitness. The block fitness $f(b)$ is simply defined as $1+e, e$ being the number of endorsements registered in the block.
+
+Taking the maximal clique with the highest fitness (or some hash-based deterministic selection in case of equality), the
+Graph/Consensus module can define what is called the blockclique at the current time.
+
+### Finalized blocks, stale blocks
+
+The set of pending blocks is growing each time a new block is produced and added to the current set. As we mentioned previously,
+there is also a pruning mechanism in charge of reducing the size of the graph by removing blocks that are considered final, and
+also blocks that can be considered stale and will never finalize.
+
+If a block is only contained inside cliques that have a fitness lower than the fitness of the blockclique (the clique with the maximal fitness), minus a constant $\Delta_{f}^{0}$, then this block is considered stale. Also, any new block that includes in its parents a stale block is stale.
+
+A block is considered final if it is part of all maximal cliques, and included in at least one clique where the total sum of the fitness of all its descendants is greater than $\Delta_{f}^{0}$.
+
+$\Delta_{f}^{0}$ is defined as a constant $F$ multiplied by $1+E$
+($E$ being the total max number of endorsements in a block, currently 16), and $F$ effectively measuring the maximum span in fully endorsed blocks of a successful blockclique, or the number of fully endorsed blocks by which an alternative clique can be shorter than the blockclique before its blocks may be discarded as stale.
+
+### Graph/Consensus Module Function
+
+The Consensus Module (formerly known as the Graph) receives new block proposals, integrates them into the set of pending blocks,
+updating the blockclique with the method explained above, and verifying the legitimacy of the parenting of new blocks. It also
+informs other modules, like the Execution module, when blocks are finalized and the corresponding ledger modifications implied
+by their operations list should be made permanent.
+
+It is also able to answer queries about the current best parents for a new block (based on the current blockclique) or the list
+of current maximal cliques.
+
+## Execution Module
+
+The Execution Module is in charge of effectively executing the operations contained in blocks within the current blockclique,
+which is provided by the Graph/Consensus Module. Operations will typically modify the ledger, either by changing the balances
+of accounts or by modifying the datastore of smart contracts after the execution of some code. From an implementation point
+of view, ledger modifications are however stored as diff vs the current finalized ledger, until the corresponding blocks are
+marked as finalized by the Graph/Consensus Module.
+
+Block creators will typically need to query the Execution Module to check current balances at a given slot and verify if some
+operations can be run with sufficient funds or not, before being integrated into a new block.
+
+As a side note, it is also possible that blocks might include invalid operations, in which case the Execution Module will
+simply ignore them.
+
+Being the maintainer of the ledger, the Execution Module is also queried about address information in general, via the API,
+for any Module that needs it.
+
+Finally, the Execution Module will inform the Selector Module when new cycles are initiated as the finalization of blocks
+progresses.
+
+## Pool Module
+
+When new pending operations reach a node, they are not immediately processed but instead are stored in a pool of pending operations,
+to be used by the Factory Module. Similarly, proposed endorsements coming from the Endorsement Factory are buffered inside the pool,
+to be integrated into new blocks by the Block Factory Module.
+
+The origin of pending operations or endorsements inside the pool can be internal to the factory process or could come from remote
+nodes via the API Module. Similarly, locally produced pending endorsements are broadcasted via a gossip protocol to other pools
+via the API Module.
+
+Note that operations stored in the Pool are naturally discarded after a certain time, since operations come with an expiration
+date in the _expiration_period_ field. Still, some potential attacks can occur by trying to flood the pool with high fees
+operations that have no chance of being executed because the corresponding account does not have the required funds.
+Discussing about countermeasure for this is beyond the scope of this introduction.
+
+## Block/Endorsement Factory Module
+
+The Block Factory Module is in charge of creating new blocks when the corresponding node address has been designated to
+be the block creator for a given slot. This information is provided to the Factory Module from the Selector Module via
+the API Module.
+
+The Block Factory Module also needs information about the best parents (made of the latest blocks in each thread in
+the blockclique) from the Graph/Consensus Module. These parents will be included in the newly created block. Balance
+information, in order to assess the validity of pending operations, is obtained from the Execution Module, which
+maintains the ledger state from the point of view of the slot where the new block is supposed to be created.
+
+The Block Factory Module picks pending operations from the Pool Module. Note that the Block Factory will regularly
+query the Execution Module about finalized and executed operations, and internally cleanup operations that have been handled.
+
+Finally, the Block Factory will query the Pool Module and pick pending endorsements corresponding to the best parents
+that are selected for the block.
+
+With this information, it is able to forge a new block that will then be propagated to the Graph/Consensus Module
+via the API Module, as well as to other nodes via gossip, to maintain a global synchronized state.
+
+The Endorsement Factory Module works in a similar manner, requesting the Selector Module to find out when it has been
+designated to be an endorsement producer, then feeding new endorsements to the Pool Module and the API Module for global synchronization.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/operation-lifecycle.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/operation-lifecycle.mdx
new file mode 100644
index 000000000..4395ad83a
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/operation-lifecycle.mdx
@@ -0,0 +1,59 @@
+---
+id: operation-lifecycle
+sidebar_label: Operation lifecycle
+---
+# Operation lifecycle
+
+After learning about the Basic concepts and Massa's node architecture, we have all the elements and vocabulary
+in place to explore the lifecycle of an operation within the network; from creation to permanent execution in
+a finalized block.
+
+Operations originate externally from a client that is forging the operation, for example: a transaction or a
+smart contract code execution. The client will have to know the IP address of a Massa Node (this can be either
+because it is a node itself and will simply use localhost, or via some maintained list of known nodes and/or
+some browser plugin), and will then send the operation to the API.
+
+When an operation is made available in a given node, it will be broadcasted to all other nodes via the Protocol/Network
+Module and to factories via the API Module, so that it will eventually end up in all the Pool Modules of the network.
+
+Let’s assume we just got a code execution operation from an external client. Let’s suppose the client knows a
+particular node, which is running its block factory on the same machine, and sends the operation to this node.
+These are the different steps of the operation processing that will occur, as illustrated in the schema below:
+
+
+
+1. The operation enters the node via the API Module (the operation path is marked in blue)
+
+2. The API Module forwards the operation to the Pool Module and broadcasts it to other nodes via the Protocol/Network
+Module. Other nodes hearing about it will also broadcast it (gossip protocol), and feed it to their Pool Module.
+
+3. At that stage, the operation sits in the Pool Modules of most nodes
+
+4. The Selector Module elects a particular node to handle the block production of the next current slot
+
+5. The elected node Block Factory finds out about its election by querying a Selector Module
+
+6. It starts building a block by picking up pending operations in the Pool Module. The original operation is
+eventually picked and integrated into the block. It's worth to mention that only operations created by an address within the same thread as the block can be included. This is known as a 'transaction sharding' technique and it's used to prevent double spending problem. We will now follow the block around (the block path is marked in green)
+
+7. The newly produced block is sent to the Graph/Consensus Module
+
+8. The new block is processed by the Graph/Consensus Module to be included into the pending blocks DAG and
+potentially integrated into a new blockclique
+
+9. The Graph/Consensus Module sends the new block to other nodes via the Protocol/Network Module, to ensure
+synchronization of the information in the network. The new block reaching other nodes is similarly going to be integrated into their Graph/Consensus Module
+
+10. In general, the blockclique will be extended with the new block and so will reach the Execution Module
+from the Graph/Consensus Module via the notification of a new blockclique. Eventually, it will also be notified
+as a final block if it gets finalized.
+
+11. The Execution Module will run the blocks that are part of the updated blockclique, so the original block
+will eventually be executed. Within the block is the original operation that was originally sent and that will
+then be applied to the ledger for potential modifications. At this stage, the modifications are not permanent and
+simply stored in a diff compared to the finalized ledger
+
+12. Eventually, the block will be marked as final and the ledger modification, including the operation changes,
+will become final in the finalized ledger.
+
+
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/operation_lifecycle.drawio.svg b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/operation_lifecycle.drawio.svg
new file mode 100644
index 000000000..212679c8b
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/operation_lifecycle.drawio.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/selector.drawio.svg b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/selector.drawio.svg
new file mode 100644
index 000000000..2cdbb731d
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/selector.drawio.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/structure.drawio.svg b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/structure.drawio.svg
new file mode 100644
index 000000000..08def474d
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/structure.drawio.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/unfinalized_blocks_set.drawio.svg b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/unfinalized_blocks_set.drawio.svg
new file mode 100644
index 000000000..73adddac1
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/architecture/unfinalized_blocks_set.drawio.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/asc/autonomous-sc.webp b/i18n/fr/docusaurus-plugin-content-docs/current/learn/asc/autonomous-sc.webp
new file mode 100644
index 000000000..47198541b
Binary files /dev/null and b/i18n/fr/docusaurus-plugin-content-docs/current/learn/asc/autonomous-sc.webp differ
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/asc/intro.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/learn/asc/intro.mdx
new file mode 100644
index 000000000..52ad2d0ce
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/asc/intro.mdx
@@ -0,0 +1,39 @@
+---
+id: intro
+sidebar_label: Introduction
+---
+
+# Autonomous Smart Contracts
+
+## Introduction
+
+Massa Blockchain introduces a groundbreaking feature known as Autonomous Smart Contracts.
+These smart contracts possess a unique capability: they can independently determine their own activation without any external actors.
+By the end of this section, you will gain a fundamental understanding of:
+
+- The limitations of current smart contracts on existing blockchains
+- How Massa Blockchain overcomes these limitations by empowering pre-programmed execution
+- The inner workings and mechanisms behind autonomous smart contracts
+- The use cases enables by autonomous smart contracts
+
+## Challenges with Existing Smart Contracts
+
+In today's blockchain landscape, smart contracts face limitations when it comes to automating operations without external triggers.
+While automation lies at the heart of numerous industries, particularly in the realm of modern finance, only
+certain actions within decentralized finance (DeFi) protocols, such as lending and arbitration, are automated.
+However, even these actions are typically executed by off-chain bots. The absence of external calls prevents smart contracts,
+as they exist in current public blockchains, from performing automated operations.
+
+Many decentralized protocols rely on recurrent triggers to ensure their smooth operation.
+For example, in decentralized lending protocols, borrowers lock crypto assets as collateral when obtaining loans.
+If the value of the collateralized asset drops below a specified threshold, the borrower's position becomes under-collateralized
+and requires immediate action. To maintain the integrity of the protocol, such positions must be liquidated. Currently,
+these liquidations are executed by organizations or individuals who run bots, often on centralized cloud services.
+
+## The Need for a Reliable Automation Mechanism
+
+The reliance on recurrent triggers is a prevalent requirement across numerous applications.
+Consequently, significant time and effort have been invested in developing more dependable networks of bots to ensure
+the timely execution of transactions.
+However, since these solutions operate off-chain, there is no guarantee that the execution will be triggered effectively.
+In cases where bots fail to execute transactions, decentralized protocols face risks, as do the applications built on top of them.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/asc/on-blockchain.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/learn/asc/on-blockchain.mdx
new file mode 100644
index 000000000..ea71e86a9
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/asc/on-blockchain.mdx
@@ -0,0 +1,36 @@
+---
+id: massa-asc
+sidebar_label: Autonomous Smart Contracts
+---
+# Massa's Autonomous Smart Contracts
+
+Massa's Autonomous Smart Contracts address the challenges of reliability, sophistication, and centralization that plague dApps
+seeking to offer automated smart-contract execution on behalf of their users.
+These innovative smart contracts introduce the ability to self-wake, granting them the power to autonomously perform arbitrary operations.
+For instance, they can be programmed to trigger specific calls when predefined exchange rate targets are met in a decentralized exchange.
+
+## The Mechanism within Massa Network
+
+
+
+Standard operations are sent to an *operation pool* and are executed when they are included in a block. The cost of
+execution is paid by the sender of the operation when the operation is executed.
+
+Autonomous smart contracts works by emitting messages which will schedule the execution. Those messages are emitted
+by smart contracts, through operations sent by users or by autonomous operations. Messages are then stored in an
+*asynchronous pool*. Contrary to standard operations, the gas required by autonomous smart contracts is paid upfront.
+
+The asynchronous pool is deterministic by nature as it’s filled with messages that ultimately come from operations
+included in blocks, which are processed by every node of the network. The pool has a finite size and messages
+are removed based on the fees and after a certain number of slots if they were not executed.
+
+As for normal operations, the number of autonomous operations that can be executed is limited, through a maximum amount
+of gas. In practice, it’s possible that your message isn’t executed at the slot that you want, but in a later slot,
+when there is enough space to include your message. If you want your message to be included as soon as possible, the
+fees needs to be higher than other messages (just like standard operations).
+
+Messages are ordered using the following formula:
+
+$(Reverse(Ratio(msg.fee, max(msg.max_gas,1))), emission\_slot, emission\_index),$
+
+where $emission\_index$ is an index that differentiate multiple messages created in the same slot.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/asc/use-cases.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/learn/asc/use-cases.mdx
new file mode 100644
index 000000000..dd79878ca
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/asc/use-cases.mdx
@@ -0,0 +1,42 @@
+---
+id: use-cases
+sidebar_label: Use-cases
+---
+# Use-cases & Applications
+
+Autonomous smart contracts offers a wide range of compelling use-cases that were either impossible, too costly, or risky to do with benchmark are met.
+
+Here are some of the best use cases for autonomous smart contracts:
+
+1. **Decentralized Finance (DeFi)**: Autonomous smart contracts can revolutionize DeFi applications by enabling automated and self-executing actions. Some notable use cases include:
+ - Automated liquidations: Smart contracts can automatically trigger the liquidation of under-collateralized positions in lending protocols when predetermined thresholds are breached.
+ - Yield farming strategies: Contracts can autonomously perform yield farming strategies, automatically swapping and reinvesting tokens based on predefined conditions.
+ - Dynamic portfolio rebalancing: Smart contracts can automatically adjust portfolio allocations based on market conditions, ensuring desired asset ratios are maintained.
+
+2. **Supply Chain Management**: Autonomous smart contracts have the potential to streamline supply chain processes by automating specific actions triggered by predefined conditions. Key use cases include:
+ - Automatic inventory management: Contracts can initiate purchase orders or trigger production when inventory levels reach predefined thresholds, ensuring optimal stock levels.
+ - Quality control and compliance: Smart contracts can autonomously perform quality checks and audits based on predefined criteria, ensuring compliance with standards and regulations.
+
+3. **Insurance Claims**: Autonomous smart contracts can revolutionize the insurance industry by automating claims processes. Notable use cases include:
+ - Instant claims settlement: Contracts can automatically trigger claim payments when specific conditions, such as verified damage or loss, are met, accelerating the claims settlement process.
+ - Parametric insurance: Smart contracts can leverage external data feeds, such as weather or seismic information, to autonomously determine and process claims without human intervention.
+
+4. **Gaming and NFTs**: Autonomous smart contracts can bring enhanced functionality and interactivity, and cost-reduction in on-chain execution, to gaming and non-fungible token (NFT) platforms. Key use cases include:
+ - Dynamic NFTs: Contracts can imbue NFTs with evolving characteristics or abilities based on predefined conditions, creating captivating and unique gaming experiences.
+ - Automated auctions: Contracts can autonomously initiate and manage auctions for rare items, with bidding and settlement executed automatically when predetermined criteria are met.
+
+5. **Decentralized Autonomous Organizations (DAOs)**: Autonomous smart contracts are instrumental in enabling self-governance and decision-making within DAOs. Notable use cases include:
+ - Voting and governance: Contracts can autonomously trigger voting processes based on predefined conditions, empowering token holders to participate in important decision-making. There are various applications for this: from voting in local communities to democratic processes in corporate governance.
+ - Automated fund management: Smart contracts can autonomously allocate funds, distribute dividends, or trigger investments based on predefined rules and performance metrics.
+
+6. **Real Estate Transactions**: Smart contracts can streamline various aspects of real estate transactions, increasing efficiency and reducing the need for intermediaries. Key use cases include:
+ - Escrow and payment automation: Contracts can securely hold funds in escrow and automatically release them when specific conditions, such as successful property transfer or completion of milestones, are met.
+ - Streamlined rental agreements: Contracts can automate rental payments, manage security deposits, and enforce the terms and conditions stipulated in the agreement.
+
+These examples illustrate just a few of the many compelling use cases for autonomous smart contracts.
+The self wake-up functionality empowers automated processes, reduces reliance on intermediaries, and enhances efficiency and
+transparency across diverse industries.
+
+## Going further
+
+If you want to go further and start coding your own autonomous smart contract, head to the [Build section](/docs/build/home).
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/bootstrap.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/learn/bootstrap.mdx
new file mode 100644
index 000000000..ce21ff8b3
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/bootstrap.mdx
@@ -0,0 +1,83 @@
+---
+id: bootstrap
+sidebar_label: Bootstrapping in Massa
+---
+
+# Bootstrapping in Massa
+
+## Introduction
+
+Nodes that are already part of the network are able to follow the State by observing the blocks passing through the network, verifying them, and applying the state changes they cause.
+
+However, new nodes joining the network need to get an absolute "current" version of the state, which is called "bootstrapping". In some blockchains like Bitcoin, full nodes joining the network are recommended to download all blocks from the beginning (genesis) of the blockchain in order to re-verify the whole state change history.
+
+However, Massa has a triple decentralization/security/performance goal:
+- maximal decentralization requires that node hardware requirements stay consistent with a typical consumer desktop computer to lower the entry barrier of becoming a node runner
+- maximal security requires that all nodes verify all blocks and operations
+- maximal performance requires using the node hardware to its fullest (CPU, network, memory, storage)
+
+This means that the State in Massa evolves almost as fast as typical consumer desktop computers can run blocks, which implies that catching up blocks since genesis goes only slightly faster than new blocks appear in the meantime, and would take a very long time. Moreover, Massa aims at processing thousands of operations per second, which means that it produces a lot of block data every second, thus preventing nodes with the target hardware from storing the full block history and making bootstrapping from genesis impossible since old blocks are forgotten.
+
+Massa nodes joining the network must therefore bootstrap by downloading the absolute current State.
+
+Note that nodes can recover from short-term disconnects by asking for missing data from nodes around them once they come back in the network. However, since Massa nodes only store a short history of blocks and forget older ones, it is impossible to recover from long disconnects since the surrounding nodes have forgotten the blocks needed by the recovering node. In that case, a new State bootstrap is required.
+
+## Security model
+
+### The example of Bitcoin
+
+To understand the security model of node bootstrap, Bitcoin is a good starting example.
+
+When Bitcoin node runners decide to join the network, they first download the node software from a central source (eg. bitcoin.org). If that source is compromised, the node might end up on a different network, and/or private key theft might happen. Bitcoin therefore requires trust in the entity sourcing the node software.
+
+Note that optionally, if the nodes don't wish to download the full block history they resort to trusting a more recent "checkpoint" state encoded in the node software. If that state is compromised, the node's knowledge of the whole ledger might be skewed.
+
+Assuming the node software is not corrupted, new nodes joining the network need an initial list of peer nodes to which they need to connect first in order to discover the network. This list is hardcoded in the node software (see the bitcoin docs). If all peers pointed by this initial list are compromised, the node can end on a different (non-bitcoin) network, even if the node software itself is not compromised. Bitcoin therefore also requires trust in at least one of the initial peers.
+
+Note that ending up on the wrong network can be detected by checking block hashes with an external source. But this requires trusting yet another source of data.
+
+### The case of Massa
+
+The Massa case is very similar to Bitcoin's. Node runners also need to trust the source of the node software they download, as well as the initial list of peers.
+
+Similarly to Bitcoin checkpoints, bootstrapping Massa nodes must obtain the current State from a trusted source, ideally the same source as the one they downloaded the node software from, in order to avoid having to trust multiple entities.
+
+Downloading the state from an untrusted source can result in major issues such as coin theft. As such, bootstrapping from untrusted sources should be discouraged, and bootstrapping other nodes should be opt-in for node runners to avoid "bootstrap lists" circulating as the default way of bootstrapping from unaware node runners.
+
+## Implementation details
+
+### Procedure from the point of view of the node being bootstrapped
+
+Massa nodes that bootstrap start by connecting to a randomly chosen node among the ones listed in `massa-node/base_config/config.toml`.
+
+The bootstrap process uses a separate port and protocol than the normal Massa peer communication.
+
+All communications with the chosen bootstrap node are authenticated using the public key (node ID) of the bootstrap node in the `config.toml` file to prevent man-in-the-middle attacks.
+
+The node being bootstrapped then attempts to download the current State, as well as an initial list of peers from the bootstrap node.
+
+Once successfully bootstrapped, the node can then connect to peers, discover the rest of the network, and process live incoming blocks to keep its state up to date.
+
+In Massa, the hash of the state is used as part of the proof-of-stake seed, which is a safety mechanism against malicious bootstrap nodes sending a compromised State. It ensures that nodes with an altered State eventually end up isolated from the real network because their proof-of-stake draws differ which causes them to discard incoming honest blocks. Note however that a PoS seed mismatch can take up to 2 cycles to be detected.
+
+In case of bootstrap failure, the bootstrapping node retries with another randomly chosen bootstrap node after a delay.
+
+### Procedure from the point of view of the bootstrap node
+
+Massa nodes can bootstrap other nodes, with certain limitations because the procedure is heavy for the bootstrap node.
+
+The bootstrap system listens on the address/port defined in `massa-node/base_config/config.toml`. The node's bootstrap server can be disabled by removing the `bind` entry from the config file.
+
+The Massa State is large (terabytes in the worst case), and takes time to upload to bootstrapping nodes. During that time, new changes to the state continue to appear, so new changes affecting already-uploaded parts need to be sent on-the-fly.
+
+By default, Massa nodes only allow a whitelist of IP addresses to bootstrap from them. This list is present in the `massa-node/base_config/bootstrap_whitelist.json` file. This list is intended to prevent flooding attacks by attackers pretending to be bootstrapping, and also makes it more difficult for node runners to bootstrap from untrusted sources. If you wish to disable whitelisting and allow anyone to bootstrap from your node, simply delete the `bootstrap_whitelist.json` file and restart your node.
+
+A complementary `bootstrap_blacklist.json` (absent by default) can also be created alongside `bootstrap_whitelist.json` (and following the same syntax) in order to explicitly prevent certain IP addresses from bootstrapping from the node.
+
+Once a node has accepted to bootstrap an incoming node, it adds the incoming node's IP address to a local cache preventing that IP from bootstrapping again for a time defined in `massa-node/base_config/config.toml` (section `bootstrap/per_ip_min_interval`) by refusing subsequent connections from that IP during the config-defined delay. The exclusion delay is not extended if the remote IP attempts new connections during the exclusion delay. The exclusion delay is however applied if the bootstrap was accepted but failed for any reason. This aims at limiting the load on individual bootstrap nodes, and spreading the load among bootstrap nodes.
+
+The number of nodes simultaneously bootstrapping from the local node is limited (`massa-node/base_config/config.toml` section `bootstrap/max_simultaneous_bootstraps`). Excess attempts are refused but do not trigger the exclusion delay mechanism.
+
+## Future optimizations
+
+We plan to add the possibility to download bootstrap data from untrusted sources for load-balancing, but then check the hash of the obtained state from trusted sources, and only fallback to downloading everything from trusted sources if multiple bootstrap attempts from this hybrid approach fail.
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/decentralized-web.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/learn/decentralized-web.mdx
new file mode 100644
index 000000000..ef503896a
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/decentralized-web.mdx
@@ -0,0 +1,42 @@
+---
+id: decentralized-web
+sidebar_label: Decentralized Web
+---
+
+# Decentralized Web
+
+The *code is law* rule is a cornerstone of DeFi. It states among other things that once successfully audited, a
+program can remain trusted. This implies that the program of a successfully audited smart contract may never be
+unexpectedly changed by an outsider. Popular ETH smart contracts essentially follow that rule.
+
+However, most DeFi web3 apps such as [app.uniswap.org](https://app.uniswap.org/) are typically used through an
+otherwise normal website that talks to a browser plugin (typically
+[Metamask](https://github.com/MetaMask/metamask-extension)) allowing the webpage to interact with the user's wallet
+and the blockchain. The website that serves as an entry point to the dApp is neither decentralized nor
+immutable-once-audited. This breaks the very foundation of blockchain security.
+
+This attack vector has been well identified by exploiters and, as smart contracts become more robust, exploiters are
+increasingly targeting front ends. For instance, in 2022, one of the major DeFi protocols,
+[Curve Finance](https://curve.fi/), fell victim to [DNS hijacking](https://rekt.news/curve-finance-rekt/),
+with hackers managing to steal as much as $575k from users.
+As long as decentralized applications rely on Web 2.0 infrastructure, these attacks are bound to happen
+[regularly](https://twitter.com/LefterisJP/status/1540306236087877635).
+
+## Massa Station
+
+The goal of Massa's decentralized web is to allow users to store websites without using any centralized party in between
+your client and the blockchain. Since the front-end is hosted on the blockchain, anyone can access it using a Massa
+node.
+
+To this end Massa has developed a client that acts as a gateway to the blockchain preventing you from using any
+centralized servers effectively maximizing your security with immutable and censorship-resistant websites.
+That way, Massa allows deploying fully decentralized code-is-law apps, as it was meant to be!
+
+Start your decentralized web3 journey now, and install [**Massa Station**](https://station.massa.net).
+Massa Station allows you to navigate Massa web3 content and to store your own website.
+
+:::note
+Note that you would typically not host all assets, images and other non-essential data on-chain, but only the
+critical functioning parts that need auditing and the subsequent security guarantees. The rest can typically be hosted
+on IPFS or some other decentralized storage solution.
+:::
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/distribution.png b/i18n/fr/docusaurus-plugin-content-docs/current/learn/distribution.png
new file mode 100644
index 000000000..93e91ac5e
Binary files /dev/null and b/i18n/fr/docusaurus-plugin-content-docs/current/learn/distribution.png differ
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/gas.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/learn/gas.mdx
new file mode 100644
index 000000000..d4dfed95a
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/gas.mdx
@@ -0,0 +1,67 @@
+---
+id: gas
+sidebar_label: Gas
+---
+
+# Gas
+
+## Introduction
+
+In Massa, there are 2 slots per second. At each slot, an ensemble of autonomous smart contracts, as well as a block, are executed.
+If a smart contract being called executed contains an infinite loop, it might hang the whole network.
+To prevent this, it is required to cap the computation time of each slot below 500 milliseconds to allow the network to follow the slot schedule.
+
+To do this we define a deterministic unit of computation time calibrated on a reference instance of the recommended hardware.
+We call this unit `gas`.
+Each smart contract instruction consumes a defined amount of `gas` when executed.
+
+Protocol-defined gas limits ensuring a total slot execution time remains below 300 milliseconds
+on the reference hardware are set as follows:
+* the execution of autonomous smart contracts at each slot: `MAX_ASYNC_GAS = 1_000_000_000`
+* the execution of all the operations of a block: `MAX_BLOCK_GAS = 4_294_967_295`
+
+
+## Gas in operations
+
+Block producers aim at maximizing their revenue by executing the operations that give them the highest total `fee` in their blocks,
+while respecting the protocol-defined block size and gas limits to avoid their blocks from being rejected.
+Having many pending operations compete for a limited amount of block space and gas creates a market for those resources.
+This means that if the `fee` of an operation is not set high enough to make it competitive given the space and gas it consumes,
+it less likely to be included by block producers.
+They would prefer allocating those resources to other operations that are more profitable to them.
+
+Given the high throughput of the network and the low hardware requirements for block producers,
+it is not computationally feasible for block producers to simulate the execution of some types of operations
+in order to estimate the amount of gas their execution would require.
+Operations such as `CallSC` or `ExecuteSC` therefore contain a declarative `max_gas` field
+that caps the amount of `gas` that can be consumed by the execution of the operation.
+The sum of the `max_gas` of all the operations of a block must not exceed `MAX_BLOCK_GAS`.
+Beyond that, any excess operations in the block are not executed and do not profit to the block producer.
+It is the responsibility of the operation sender to set a `max_gas` value that is high enough.
+If the execution of the operation exceeds its declared `max_gas`,
+the `fee` is still paid but any other effects of the execution are reverted.
+
+The gas usage of an operation can be estimated by its sender by using the read-only mode.
+The used gas is returned by the read-only calls/executions.
+
+## Gas in autonomous smart contracts
+
+Autonomous smart contract also compete for a finite `MAX_ASYNC_GAS` per slot.
+When emitting an autonomous smart contract message, the sender speficies a `fee` and a `max_gas` in the arguments.
+Autonomous smart contracts do not involve block producers, so the `fee` is simply burned at emission.
+
+To replicate the priorization behavior of block producers in a deterministic way,
+the autonomous smart contract pool sorts the autonomous smart contract messages
+by their profitability defined by the `fee/max_gas` ratio.
+
+The pool is of finite size `MAX_ASYNC_POOL_LENGTH = 10_000`.
+Expired messages are automatically dropped from that pool.
+Despite this, if the pool still grows beyond its length limit,
+the least profitable messages are dropped to fit the limit.
+When a message is dropped, its `coins` are reimbursed to the sender but not its `fee`.
+
+At each slot `S`, the autonomous smart contract messages that can be executed at `S`
+are picked from the most profitable to the least profitable and executed in that order
+until their cumulated `max_gas` reaches `MAX_ASYNC_GAS`.
+Autonomous smart contract messages are removed from the pool once they are executed.
+
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/home.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/learn/home.mdx
new file mode 100644
index 000000000..71e70ddc5
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/home.mdx
@@ -0,0 +1,67 @@
+---
+id: home
+sidebar_label: Home
+---
+
+import { FeatureList, Feature } from "@site/src/components/featurelist";
+
+# General Documentation
+
+Welcome! On this page you'll find various resources explaining some concepts introduced by the Massa protocol and how the Massa protocol operates.
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/inflation.png b/i18n/fr/docusaurus-plugin-content-docs/current/learn/inflation.png
new file mode 100644
index 000000000..53d9ee6d5
Binary files /dev/null and b/i18n/fr/docusaurus-plugin-content-docs/current/learn/inflation.png differ
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/introduction.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/learn/introduction.mdx
new file mode 100644
index 000000000..b9b2059a2
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/introduction.mdx
@@ -0,0 +1,13 @@
+---
+id: introduction
+sidebar_label: Welcome to Massa
+---
+
+# What is Massa?
+
+Massa is a public blockchain built to be scalable, efficient and secure. Massa uses a novel [Proof-of-Stake](https://en.wikipedia.org/wiki/Proof_of_stake) consensus mechanism that massively increases throughput by [parallelizing block creation](https://arxiv.org/abs/1803.09029), allowing up to 10'000 transactions per second.
+
+Massa provides the following key innovations:
+1. **Autonomous Smart Contracts**: Massa's smart contracts can be programmed to execute autonomously, without the need for any external triggers or oracles.
+2. **Decentralized Web**: decentralized applications can be hosted entirely on the Massa blockchain, reducing the exposure of dApps to centralized services.
+3. **Developer Friendly**: Massa's smart contracts are written in TypeScript, a popular programming language that is familiar to many developers.
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/operation-format-execution.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/learn/operation-format-execution.mdx
new file mode 100644
index 000000000..d12a18002
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/operation-format-execution.mdx
@@ -0,0 +1,812 @@
+---
+id: operation-format-execution
+sidebar_label: Detailed operation format and execution sequence
+---
+
+# Detailed operation format and execution sequence
+
+Massa's maximal theoretical throughput is about 10k operations per second, with low hardware requirements for validators to improve decentralization.
+This puts constraints on how operations are executed and finalized in Massa:
+* parallelization techniques are required for processing operations fast enough
+* nodes are unable to store the whole history of previously executed operations (for example to ensure that an old operation is not being re-executed)
+* block producers do not have enough computing power to simulate the execution of all candidate operations to choose which ones to include in their blocks
+* security must always be guaranteed against malicious actors
+
+Massa addresses these issues through multiple techniques.
+
+## Operation format and legality
+
+An operation is considered legal if it properly deserializes, its field values are legal and mutually consistent,
+and it passes signature verification.
+
+### Operation
+
+Binary serialization format of an operation:
+
++---------------------------------+-----------------------------------+-------------------+
+| Operation Binary Representation |
++---------------------------------+-----------------------------------+-------------------+
+| Field | Description | Type |
++=================================+===================================+===================+
+| `signature` | See [Signature section](#signature) |
++---------------------------------+-----------------------------------+-------------------+
+| `sender public key` | See [Public Key section](#public-key) |
++---------------------------------+-----------------------------------+-------------------+
+| `serialized operation contents` | See [Operation Contents section](#operation-contents) |
++---------------------------------+-----------------------------------+-------------------+
+
+Legality checks performed on deserialization:
+* the signature is legal (see [Signature section](#signature))
+* the public key is legal (see [Public Key section](#public-key))
+* the serialized operation contents are legal (see [Operation Contents section](#operation-contents))
+
+### Operation contents hash
+
+The operation contents hash is computed as follows:
+
+```
+operation_contents_hash = blake3_hash(concatenate(serialize_binary(chain_id), serialize_binary(public_key), serialize_binary(operation_contents)))
+```
+
+Blake3 is 12 times faster than sha256 and is not subject to [length extension attacks](https://en.wikipedia.org/wiki/Length_extension_attack) contrary to sha256.
+See the [Chain id section](#chain-id), the [Public Key section](#public-key) and [Operation Contents](#operation-contents) sections for details on the binary serialization formats of these fields.
+
+This hash is a deterministic fingerprint of the non-malleable parts of the operation (excluding the signature) that can be considered unique in practice.
+
+Because the operation contents hash uniquely identifies an operation,
+if another operation containing the same values in its operation contents is created,
+both operations will be considered to be the same operation that can only be executed at most a single time (see [Operation execution](#operation-execution)).
+In Massa, there is no Nounce in operations.
+Resolving potential conflicts can be done adjusting the expiry period of the operation being created.
+
+### Operation ID
+
+The ID of an operation has the following binary representation:
+
++---------------------------+-----------------------------------------------------------------+-----------------------------------+
+| Operation ID Binary Representation |
++---------------------------+-----------------------------------------------------------------+-----------------------------------+
+| Field | Description | Type |
++===========================+=================================================================+===================================+
+| `version number` | Varint unsigned 64-bit integer using protobuf conventions. | between 1 and 9 bytes (inclusive) |
+| | Indicates the operation's version. | |
++---------------------------+-----------------------------------------------------------------+-----------------------------------+
+| `operation_contents_hash` | See [Operation contents hash section](#operation-contents-hash) | 32 bytes |
++---------------------------+-----------------------------------------------------------------+-----------------------------------+
+
+Legality checks performed on binary deserialization:
+* the version number must be 0
+* the operation contents hash must be legal (see [Operation contents hash section](#operation-contents-hash))
+
+
+The ID of an operation has the following UTF-8 ASCII-compatible text representation:
+
++-------------------------+--------------------------------------------------------------------------------------------------------------------+----------------------------------+
+| Operation ID Text Representation |
++-------------------------+--------------------------------------------------------------------------------------------------------------------+----------------------------------+
+| Field | Description | Type |
++=========================+====================================================================================================================+==================================+
+| `prefix letter 'O'` | Not a zero but the letter O. | |
+| | A constant prefix indicating that it is an operation ID | |
+| | to avoid ambiguity with other IDs (e.g., Block IDs are prefixed with 'B') | 1 letter (1 byte) |
++-------------------------+--------------------------------------------------------------------------------------------------------------------+----------------------------------+
+| `operation ID contents` | Base58check (no version, with checksum) representation of the binary serialization of the operation ID (see above) | 18 to 62 characters (18 to 62 bytes) |
++-------------------------+--------------------------------------------------------------------------------------------------------------------+----------------------------------+
+
+Note that the base58check encoding is the same one as the one used by bitcoin but without version number as it is already included in the underlying binary serialization of the operation ID.
+
+Here is the entire encoding process for an operation ID in text format:
+* serialize the operation ID in binary format (see above)
+* compute the SHA256 hash of the binary serialization
+* append the first 4 bytes of the sha256 hash at the end of the binary serialization of the ID. This is used as a checksum to detect typing errors as operation IDs are also meant to be written on paper by humans.
+* encode the resulting byte array using the base alphabet `123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz`. Similar looking characters (eg 0 vs O) are excluded to avoid human confusion.
+* prepend the letter 'O'
+
+Legality checks performed on text deserialization:
+* the text must be valid UTF-8 and ASCII with only alphanumeric characters
+* the prefix letter must be 'O'
+* the base58check must use the legal alphabet described above and the checksum must verify
+* the decoded binary serialization of the operation ID must be legal (see above)
+
+Example of legal operation ID: `O19DQAos5Dw6z4BVzQPYxj9g8v6H5W3HuKV7dFuYEpc2YNWopEz`
+
+To maximize performance by having the same hash re-used for signature and ID computation,
+the ID uses the `operation_contents_hash` which does not include the signature in the hashing process.
+This has the consequence of enabling malleability on operation signatures, which is explicitly tolerated by Massa.
+
+### Signature
+
+The signature of an operation is computed in the following way:
+
+```
+ed25519_sign(operation_contents_hash)
+```
+
+Signature verification is a CPU time-intensive process and is done in a deferred, parallelized and batched fashion.
+The following function is used for signature verification: https://docs.rs/ed25519-dalek/2.0.0/ed25519_dalek/fn.verify_batch.html
+
+For maximal robustness and future-proofing, Massa tolerates operation signature malleability.
+
+
+Binary serialization format of the signature:
+
++---------------------+-------------------------------------------------------------------------------------------------------+---------------------------------------------+
+| Signature Binary Representation |
++---------------------+-------------------------------------------------------------------------------------------------------+---------------------------------------------+
+| Field | Description | Type |
++=====================+=======================================================================================================+=============================================+
+| `version number` | Varint unsigned 64-bit integer using protobuf conventions | Between 1 (included) and 9 (included) bytes |
++---------------------+-------------------------------------------------------------------------------------------------------+---------------------------------------------+
+| `signature content` | Constant-size ed25519 signature made of the concatenation of its R (32-bit) and s (32-bit) components | 64 bytes |
++---------------------+-------------------------------------------------------------------------------------------------------+---------------------------------------------+
+
+Legality checks performed on deserialization:
+* the version number must be 0
+* the signature must be 64 bytes long
+
+Signature verification with respect to data and public key is not performed on signature deserialization.
+Invalid field elements in the signature are not checked on signature deserialization but on signature verification.
+
+### Secret key
+
+
+The secret key has the following binary representation:
+
++----------------------------+------------------------------------------------------------------------------------------------+---------------------------------------------+
+| Secret Key Binary Representation |
++----------------------------+------------------------------------------------------------------------------------------------+---------------------------------------------+
+| Field | Description | Type |
++============================+================================================================================================+=============================================+
+| `version number` | Varint unsigned 64-bit integer using protobuf conventions. Indicates the secret key version. | Between 1 (included) and 9 (included) bytes |
++----------------------------+------------------------------------------------------------------------------------------------+---------------------------------------------+
+| `cryptographic secret key` | ed25519 secret key bytes | 32 bytes |
++----------------------------+------------------------------------------------------------------------------------------------+---------------------------------------------+
+
+Legality checks performed on binary deserialization:
+* the version number must be 0
+* the cryptographic secret key bytes must be 32 bytes long
+
+
+Secret keys have the following UTF-8 ASCII-compatible text representation:
+
++-----------------------+-------------------------------------------------------------------------------------------------------+---------------------------------------------+
+| Secret Key Text Representation |
++-----------------------+-------------------------------------------------------------------------------------------------------+---------------------------------------------+
+| Field | Description | Type |
++=======================+=======================================================================================================+=============================================+
+| `prefix letter 'S'` | A constant prefix indicating that it is a secret key to avoid ambiguity with other IDs | 1 letter (1 byte) |
+| | (e.g., Block IDs are prefixed with 'B') | |
++-----------------------+-------------------------------------------------------------------------------------------------------+---------------------------------------------+
+| `secret key contents` | Base58check (no version, with checksum) representation of the binary serialization of the secret key | 18 (included) to 62 (included) characters |
+| | (see above) | (18 to 62 bytes) |
++-----------------------+-------------------------------------------------------------------------------------------------------+---------------------------------------------+
+
+Note that the base58check encoding is the same one as the one used by bitcoin but without version number as it is already included in the underlying binary serialization of the secret key.
+
+Here is the entire encoding process for a secret key in text format:
+* serialize the secret key in binary format (see above)
+* compute the SHA256 hash of the binary serialization
+* append the first 4 bytes of the sha256 hash at the end of the binary serialization of the key. This is used as a checksum to detect typing errors as secret keys are also meant to be written on paper by humans.
+* encode the resulting byte array using the base alphabet `123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz`. Similar looking characters (eg 0 vs O) are excluded to avoid human confusion.
+* prepend the letter 'S'
+
+Legality checks performed on text deserialization:
+* the text must be valid UTF-8 and ASCCII with only alphanumeric characters
+* the prefix letter must be 'S'
+* the base58check must use the legal alphabet described above and the checksum must verify
+* the decoded binary serialization of the secret key must be legal (see above)
+
+Example of legal secret key: `S1CkpvD4WMjJWxR2WZcrDEkJ1kWG2kKe1e3Afe8miqmskHqovvA`
+
+### Public key
+
+Binary serialization format of the public key:
+
++----------------------------+------------------------------------------------------------+---------------------------------------------+
+| Public Key Binary Representation |
++----------------------------+------------------------------------------------------------+---------------------------------------------+
+| Field | Description | Type |
++============================+============================================================+=============================================+
+| `version number` | Varint unsigned 64-bit integer using protobuf conventions | Between 1 (included) and 9 (included) bytes |
++----------------------------+------------------------------------------------------------+---------------------------------------------+
+| `cryptographic public key` | Compressed ed25519 public key | 32 bytes |
++----------------------------+------------------------------------------------------------+---------------------------------------------+
+
+The cryptographic public key is compressed in the following way to take only 32 bytes instead of 64:
+* the first 255 bits represent the `y` coordinate
+* the high bit of the 32nd byte gives the sign of `x`
+Using this data, and through symetries in the ed25519 curve, it is possible to deduce the `x` coordinate.
+In Massa, public key decompression is performed on public key deserialization,
+and because decompression is a CPU time-heavy operation,
+each connected peer has a dedicated CPU thread performing its deserializations.
+
+Legality checks performed on deserialization:
+* the version number must be 0
+* the cryptographic public key must be 32 bytes long
+* the compressed public key `y` component must be valid for the ed25519 curve
+
+Public keys have the following UTF-8 ASCII-compatible text representation:
+
++-----------------------+-------------------------------------------------------------------------------------------------------+---------------------------------------------+
+| Public Key Text Representation |
++-----------------------+-------------------------------------------------------------------------------------------------------+---------------------------------------------+
+| Field | Description | Type |
++=======================+=======================================================================================================+=============================================+
+| `prefix letter 'P'` | A constant prefix indicating that it is a secret key to avoid ambiguity with other IDs | 1 letter (1 byte) |
+| | (e.g., Block IDs are prefixed with 'B') | |
++-----------------------+-------------------------------------------------------------------------------------------------------+---------------------------------------------+
+| `public key contents` | Base58check (no version, with checksum) representation of the binary serialization of the public key. | 18 (included) to 62 (included) characters. |
+| | See above. | 18 to 62 bytes |
++-----------------------+-------------------------------------------------------------------------------------------------------+---------------------------------------------+
+
+Note that the base58check encoding is the same one as the one used by bitcoin but without version number as it is already included in the underlying binary serialization of the public key.
+
+Here is the entire encoding process for a public key in text format:
+* serialize the public key in binary format (see above)
+* compute the SHA256 hash of the binary serialization
+* append the first 4 bytes of the sha256 hash at the end of the binary serialization of the key. This is used as a checksum to detect typing errors as public keys are also meant to be written on paper by humans.
+* encode the resulting byte array using the base alphabet `123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz`. Similar looking characters (eg 0 vs O) are excluded to avoid human confusion.
+* prepend the letter 'P'
+
+Legality checks performed on text deserialization:
+* the text must be valid UTF-8 and ASCCII with only alphanumeric characters
+* the prefix letter must be 'P'
+* the base58check must use the legal alphabet described above and the checksum must verify
+* the decoded binary serialization of the public key must be legal (see above)
+
+Example of legal public key: `P1t4JZwHhWNLt4xYabCbukyVNxSbhYPdF6wCYuRmDuHD784juxd`
+
+### Address
+
+Addresses can be of two categories in Massa:
+* Externally Owned Account addresses are used to identify users that hold a private key and can sign operations
+* Smart Contract Account addresses are used to identify smart contracts that are not linked to any private key
+
+Binary serialization format of an address:
+
++---------------------+------------------------------------------------------------+---------------------------------------------+
+| Address Binary Representation |
++---------------------+------------------------------------------------------------+---------------------------------------------+
+| Field | Description | Type |
++=====================+============================================================+=============================================+
+| `address category` | Varint unsigned 64-bit integer using protobuf conventions: | Between 1 (included) and 9 (included) bytes |
+| | - value 0 for externally owned accounts, | |
+| | - value 1 for smart contracts | |
++---------------------+------------------------------------------------------------+---------------------------------------------+
+| `version number` | Varint unsigned 64-bit integer using protobuf conventions | Between 1 (included) and 9 (included) bytes |
++---------------------+------------------------------------------------------------+---------------------------------------------+
+| `underlying hash` | Underlying blake3 hash | 32 bytes |
++---------------------+------------------------------------------------------------+---------------------------------------------+
+
+The underlying hash of an externally owned account address is computed by taking the blake3 hash
+of the binary serialization of the account's public key (see [Public Key section](#public-key)).
+The Blockclique sharding thread of an externally owned account address is computed
+by taking the first 5 bits of its underlying hash.
+
+The underlying hash of a smart contract account address is computed
+by taking the blake3 hash of a deterministic seed.
+Because this seed can be rewritten by Blockclique changes,
+always wait for finality before using the address of a newly created smart contract.
+
+Legality checks performed on binary deserialization:
+* the address category must be 0 or 1
+* the version number must be 0
+* the underlying hash must be 32 bytes long
+
+
+Text serialization of an address:
+
++---------------------+----------------------------------------------------------------------------------------------------+-------------------------------------------+
+| Address Text Representation |
++---------------------+----------------------------------------------------------------------------------------------------+-------------------------------------------+
+| Field | Description | Type |
++=====================+====================================================================================================+===========================================+
+| `prefix letter 'A'` | A constant prefix indicating that it is an address to avoid ambiguity with other IDs. | 1 letter (1 byte) |
+| | (e.g., Block IDs are prefixed with 'B') | |
++---------------------+----------------------------------------------------------------------------------------------------+-------------------------------------------+
+| `address contents` | Base58check (no version, with checksum) representation of the binary serialization of the address. | 18 (included) to 74 (included) characters |
+| | See above. | 18 to 74 bytes |
++---------------------+----------------------------------------------------------------------------------------------------+-------------------------------------------+
+
+Here is the entire encoding process for an address in text format:
+* serialize the address in binary format (see above)
+* compute the SHA256 hash of the binary serialization
+* append the first 4 bytes of the sha256 hash at the end of the binary serialization of the address. This is used as a checksum to detect typing errors as addresses are also meant to be written on paper by humans.
+* encode the resulting byte array using the base alphabet `123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz`. Similar looking characters (eg 0 vs O) are excluded to avoid human confusion.
+* prepend the letter 'A'
+
+Legality checks performed on text deserialization:
+* the text must be valid UTF-8 and ASCCII with only alphanumeric characters
+* the prefix letter must be 'A'
+* the base58check must use the legal alphabet described above and the checksum must verify
+* the decoded binary serialization of the address must be legal (see above)
+
+Example of legal address in text format: `AU12v83xmHg2UrLM8GLsXRMrm7LQgn3DZVT6kUeFsuFyhZKLkbQtY`
+
+### Coin amounts
+
+Coin amounts represent a quantity of Massa native coins and are positive or zero, fixed-point numbers.
+The fixed point precision is `1e-9`.
+The minimal coin amount that can be represented is is `0`
+and the maximal coin amount that can be represented is `18,446,744,073.709551615`.
+Floating point numbers should never be used for amount computations to avoid determinism problems and rounding errors.
+
+Binary serialization format of a coin amount:
+
++---------------------+-------------------------------------------------------------------------------------------------------+---------------------------+
+| Coin Amount Binary Representation |
++---------------------+-------------------------------------------------------------------------------------------------------+---------------------------+
+| Field | Description | Type |
++=====================+=======================================================================================================+===========================+
+| `mantissa` | Varint unsigned 64-bit integer using protobuf conventions. | From 1 byte (included) to |
+| | The mantissa is deduced by multiplying the represented coin amount by `1e9`. | 9 bytes (included) |
++---------------------+-------------------------------------------------------------------------------------------------------+---------------------------+
+
+No checks are performed on deserialization except the validity of the varint itself
+and that its value fits in an unsigned 64bit integer.
+
+In text representation, coin amounts are represented as a traditional decimal number utf-8 string without zero padding and with the `.` decimal separator.
+
+Here are some examples of valid coin amounts in text format:
+* `123456.789012345`
+* `0.001`
+* `0`
+
+On text format deserialization, the following legality checks are performed:
+* the string is valid UTF-8
+* there is at least one character
+* only alphanumeric characters and the `.` decimal separator are allowed
+* the `.` decimal separator must appear zero or one time
+* the `.` decimal separator must not be the first nor the last character
+* deserialization does not under/over-flow the allowed coin amount range
+* deserialization into the underlying unsigned 64 bit representation does not cause precision loss (no rounding or truncation allowed)
+
+### Operation contents
+
+Operation contents are represented with a common set of properties (`fee`, `expire_period`) and a specific payload
+depending on the operation type among:
+* `Transaction`
+* `CallSC`
+* `ExecuteSC`
+* `RollBuy`
+* `RollSell`
+
+Binary serialization format of operation contents:
+
++---------------------+-------------------------------------------------------------------------------------------------------+---------------------------+
+| Operation Contents Binary Representation |
++---------------------+-------------------------------------------------------------------------------------------------------+---------------------------+
+| Field | Description | Type |
++=====================+=======================================================================================================+===========================+
+| `fee` | Coin amount in binary format (see [Coin amount section](#coin-amounts)) | From 1 byte (included) to |
+| | | 9 bytes (included) |
++---------------------+-------------------------------------------------------------------------------------------------------+---------------------------+
+| `expire_period` | Varint unsigned 64-bit integer using protobuf conventions. | From 1 byte (included) to |
+| | | 9 bytes (included) |
++---------------------+-------------------------------------------------------------------------------------------------------+---------------------------+
+| `type identifier` | Varint unsigned 32-bit integer using protobuf conventions. | From 1 byte (included) to |
+| | | 5 bytes (included) |
++---------------------+-------------------------------------------------------------------------------------------------------+---------------------------+
+| `op` | Binary-serialized operation payload (see below). | Size varies |
++---------------------+-------------------------------------------------------------------------------------------------------+---------------------------+
+
+The type identifier indicates the payload type:
+* `Transaction = 0`
+* `RollBuy = 1`
+* `RollSell = 2`
+* `ExecuteSC = 3`
+* `CallSC = 4`
+
+Legality checks performed on deserialization:
+* the fee must be legal (see [Coin amount section](#coin-amounts))
+* the type identifier must be one of the ones listed above
+* the operation payload defined by the type identifier must be legal (see below)
+
+#### Transaction operation payload
+
+The binary serialization format of the payload of a transaction operation follows:
+
++---------------------+-------------------------------------------------------------------------------------------------------+-----------------------+
+| Transaction Operation Payload Binary Representation |
++---------------------+-------------------------------------------------------------------------------------------------------+-----------------------+
+| Field | Description | Type |
++=====================+=======================================================================================================+=======================+
+|`destination address`| Transfer destination address binary representation, see [Address section](#address). | From 34 (included) to |
+| | | 50 bytes (included) |
++---------------------+-------------------------------------------------------------------------------------------------------+-----------------------+
+| `amount` | Coin amount binary representation, see [Coin amount section](#coin-amounts). | From 1 (included) to |
+| | | 9 bytes (included) |
++---------------------+-------------------------------------------------------------------------------------------------------+-----------------------+
+
+Legality checks performed on deserialization:
+* the destination address must be legal (see [Address section](#address))
+* the amount must be legal (see [Coin amount section](#coin-amounts))
+
+#### RollBuy operation payload
+
+The binary serialization format of the payload of a roll buy operation follows:
+
++---------------------+-------------------------------------------------------------------------------------------------------+---------------------------+
+| Payload of a Roll Buy Operation Binary Representation |
++---------------------+-------------------------------------------------------------------------------------------------------+---------------------------+
+| Field | Description | Type |
++=====================+=======================================================================================================+===========================+
+| `rolls` | Varint unsigned 64-bit integer using protobuf conventions. | From 1 byte (included) to |
+| | | 9 bytes (included) |
++---------------------+-------------------------------------------------------------------------------------------------------+---------------------------+
+
+No particular checks performed at deserialization except that the varint must be valid
+and fit in an unsigned 64bit integer.
+
+#### RollSell operation payload
+
+The binary serialization format of the payload of a roll sell operation follows:
+
++---------------------+------------------------------------------------------------+---------------------------+
+| Payload of a Roll Sell Operation Binary Representation |
++---------------------+------------------------------------------------------------+---------------------------+
+| Field | Description | Type |
++=====================+============================================================+===========================+
+| `rolls` | Varint unsigned 64-bit integer using protobuf conventions. | From 1 byte (included) to |
+| | | 9 bytes (included) |
++---------------------+------------------------------------------------------------+---------------------------+
+
+No particular checks performed at deserialization except that the varint must be valid
+and fit in an unsigned 64bit integer.
+
+#### ExecuteSC operation payload
+
+The binary serialization format of the payload of a an Execute SC operation follows:
+
++------------------------------+------------------------------------------------------------------------------+---------------------------+
+| Payload of a ExecuteSC Operation Binary Representation |
++------------------------------+------------------------------------------------------------------------------+---------------------------+
+| Field | Description | Type |
++==============================+==============================================================================+===========================+
+| `max_gas` | Varint unsigned 64-bit integer using protobuf conventions. | From 1 byte (included) to |
+| | | 9 bytes (included) |
++------------------------------+------------------------------------------------------------------------------+---------------------------+
+| `max_coins` | Coin amount binary serialization (see [Coin amount section](#coin-amounts)). | From 1 byte (included) to |
+| | | 9 bytes (included) |
++------------------------------+------------------------------------------------------------------------------+---------------------------+
+| `bytecode_length` | Varint unsigned 64-bit integer using protobuf conventions. | From 1 byte (included) to |
+| | | 9 bytes (included) |
++------------------------------+------------------------------------------------------------------------------+---------------------------+
+| `bytecode` | Raw bytes of bytecode to execute. | From 0 to 10,000,000 bytes|
++------------------------------+------------------------------------------------------------------------------+---------------------------+
+| `operation_datastore_length` | Varint unsigned 64-bit integer using protobuf conventions. | From 1 byte (included) to |
+| | | 9 bytes (included) |
++------------------------------+------------------------------------------------------------------------------+---------------------------+
+| `operation_datastore_items` | Concatenated datastore items. | See below. |
++------------------------------+------------------------------------------------------------------------------+---------------------------+
+
+Datastore item binary format:
+
++---------------------+------------------------------------------------------------+----------------------------+
+| Datastore Item Binary Representation |
++---------------------+------------------------------------------------------------+----------------------------+
+| Field | Description | Type |
++=====================+============================================================+============================+
+| `key length` | Varint unsigned 64-bit integer using protobuf conventions. | From 1 byte (included) to |
+| | | 9 bytes (included) |
++---------------------+------------------------------------------------------------+----------------------------+
+| `key` | Raw key byte array. | From 0 byte (included) to |
+| | | 255 bytes (included) |
++---------------------+------------------------------------------------------------+----------------------------+
+| `value length` | Varint unsigned 64-bit integer using protobuf conventions. | From 1 byte (included) to |
+| | | 9 bytes (included) |
++---------------------+------------------------------------------------------------+----------------------------+
+| `value` | Raw value byte array. | From 0 byte (included) to |
+| | | 10,000,000 bytes (included)|
++---------------------+------------------------------------------------------------+----------------------------+
+
+Legality checks performed at binary deserialization:
+* bytecode length is inferior or equal to 10,000,000
+* datastore length is inferior or equal to 128
+* all datastore key lengths are inferior or equal to 255
+* all datastore value lengths are inferior or equal to 10,000,000
+
+
+#### CallSC operation payload
+
+
+The binary serialization format of the payload of a an Call SC operation follows:
+
++------------------------+--------------------------------------------------------------------------------+-------------------------------------------------------+
+| Payload of a Call SC Operation |
++------------------------+--------------------------------------------------------------------------------+-------------------------------------------------------+
+| Field | Description | Type |
++========================+================================================================================+=======================================================+
+| `max_gas` | Varint unsigned 64-bit integer using protobuf conventions. | From 1 byte (included) to 9 bytes (included) |
++------------------------+--------------------------------------------------------------------------------+-------------------------------------------------------+
+| `coins` | Coin amount binary serialization (see [Coin amount section](#coin-amounts)). | From 1 byte (included) to 9 bytes (included) |
++------------------------+--------------------------------------------------------------------------------+-------------------------------------------------------+
+| `target_address` | Target address binary representation, see [Address section](#address). | From 34 bytes (included) to 50 bytes (included) |
++------------------------+--------------------------------------------------------------------------------+-------------------------------------------------------+
+| `function_name_length` | Varint unsigned 16-bit integer using protobuf conventions. | From 1 byte (included) to 3 bytes (included) |
++------------------------+--------------------------------------------------------------------------------+-------------------------------------------------------+
+| `function_name` | Name of the function to call encoded as UTF-8 string without null termination. | From 0 bytes (included) to 65535 bytes (included) |
++------------------------+--------------------------------------------------------------------------------+-------------------------------------------------------+
+| `param_length` | Varint unsigned 64-bit integer using protobuf conventions. | From 1 byte (included) to 9 bytes (included) |
++------------------------+--------------------------------------------------------------------------------+-------------------------------------------------------+
+| `param` | Raw bytes to pass as argument to the called function. | From 0 byte (included) to 10,000,000 bytes (included) |
++------------------------+--------------------------------------------------------------------------------+-------------------------------------------------------+
+
+
+Legality checks performed at binary deserialization:
+* coins must be a legal coin amount (see [Coin amount section](#coin-amounts))
+* target address must be a legal address (see [Address section](#address))
+* function name length must be inferior or equal to 65535
+* function name must be valid UTF-8
+* param length must be inferior or equal to 10,000,000
+
+### Chain id
+
+The chain id is an unsigned 64 bit value used to avoid replay attacks between Massa networks.
+
++---------------------+-------------------------------------------+
+| Chain id values |
++---------------------+-------------------------------------------+
+| Network | Value |
++=====================+===========================================+
+| MainNet | 77658377 |
++---------------------+-------------------------------------------+
+| BuildNet | 77658366 |
++---------------------+-------------------------------------------+
+| SecureNet | 77658383 |
++---------------------+-------------------------------------------+
+| LabNet | 77658376 |
++---------------------+-------------------------------------------+
+| Sandbox | 77 |
++---------------------+-------------------------------------------+
+
+Binary serialization format of the chain id:
+
++---------------------+---------------------------------------------+---------------------------------------------+
+| Signature Binary Representation |
++---------------------+---------------------------------------------+---------------------------------------------+
+| Field | Description | Type |
++=====================+=============================================+=============================================+
+| `chain id` | unsigned 64-bit integer as big endian bytes | 8 bytes |
++---------------------+---------------------------------------------+---------------------------------------------+
+
+### Example of legal operation with valid signature
+
+* Chain id: 77658383
+* Sender Secret key in text format: `S1CkpvD4WMjJWxR2WZcrDEkJ1kWG2kKe1e3Afe8miqmskHqovvA`
+* Sender Public key in text format: `P1t4JZwHhWNLt4xYabCbukyVNxSbhYPdF6wCYuRmDuHD784juxd`
+* Sender Address in text format: `AU12m1gXHUGxBZsDF4veeWfYaRmpztBCieHhPBaqf3fcRF2LdAuZ7`
+* Operation fee: `0.001`
+* Operation expiry period: `1000`
+* Operation type: `Transaction`
+* Transaction operation payload:
+ * Destination address in text format: `AU12v83xmHg2UrLM8GLsXRMrm7LQgn3DZVT6kUeFsuFyhZKLkbQtY`
+ * Amount: `3.1`
+
+Resulting operation ID in text format: `O12CRpeqSW1NenBZ7pN79ZZz454xkbeQBGspyu4gKVXcYndm8gxw`
+
+Raw bytes in hexadecimal representation of the binary serialization of the operation:
+
+```
+00 FE C0 79 BE 60 05 EF D4 2A 1D 6A 03 0D D3 FB
+99 56 F9 FC C7 C8 78 9B 11 8D 25 1A 58 72 16 4F
+10 48 51 F2 57 20 FD 48 F9 FD 24 C3 6D 5B D3 16
+47 E9 B7 05 E2 DE F8 6C F3 B5 CE BA D2 9F 86 26
+0A 00 73 EE 58 D3 51 9D 54 03 E9 8F EF 60 35 4C
+DE 6C 7D A1 73 C1 6C 8C 6C 58 CF C8 6E E5 21 51
+3C A6 C0 84 3D E8 07 00 00 00 FC 50 AB 9B 1B 78
+4A B1 93 0E 5C F3 84 3E 8A E6 7C 59 42 1B 01 55
+10 82 B0 25 90 91 4B 4C 2A 0A 80 FE 98 C6 0B
+```
+
+## Operation propagation
+
+To reduce network usage and achieve high throughput while maintaining decentralization and security,
+operations are propagated using optimized gossip algorithms.
+
+### Operation submission
+
+When the API of a peer is called to submit an operation:
+* the operation is [checked for legality](#operation-format-and-legality)
+ * if the operation is not legal, it is rejected and an error message is returned by the API
+* the operation is [added to the operation pool of the peer](#operation-pool-and-operation-inclusion)
+* the operation is submitted to a [broadcasting thread](#operation-broadcasting)
+
+
+### Operation broadcasting
+
+The broadcasting thread keeps sumbitted operations in memory for at least 32 seconds with a cap of 32000 operations being propagated at the same time.
+It also keeps LRU caches of operations already processed by the current peer, and by other peers it is connected to.
+
+When an operation is submitted to the broadcasting thread, it is first checked for expiry (expired operations are dropped),
+and ignored if it is already being propagated.
+
+The broadcasting thread announces the operation IDs of the operations being broadcast to connected peers with batching.
+Only operation IDs not already known by a given peer are announced to it.
+The announcement batches are made of operation IDs truncated down to 17 bytes to save bandwidth usage.
+
+When a peer receives a batch of operation announcements,
+it ignores all the operation IDs that it already knows about and submits the remaining ones to the retrieval thread.
+The remote peer announcing operations is marked as knowing about these operation IDs in the current peer's caches.
+
+### Operation retrieval
+
+The retrieval thread uses an optimized queue-based algorithm to ask connected peers for batches of operations given their IDs.
+Remote peers that are known to be aware of a given operation ID are prioritized over other peers.
+Timeouts are applied as well to re-attempt retrieval from other peers in case of failure.
+
+When a batch of full operations is received:
+* the sender peer is marked as knowing about these operations in the current peer's caches.
+* the operations are checked for legality with batched parallel signature verification (see [operation legality section](#operation-format-and-legality))
+ * if any of the operations is not legal, the batch is dropped, and the sender peer is bannned
+* the operations are added to the peer's operation pool (see [Pool and Operation inclusion](#operation-pool-and-operation-inclusion))
+* the operations are submitted to the broadcasting thread
+
+### Operation propagation within blocks
+
+Blocks contain arbtirary operations chosen by the block producer.
+Block retrieval in Massa makes use of the propagation caches to only ask for operations that are not already known by the current peer.
+This effectively avoids re-doing operation propagation and legality checks for block operations that have already propagated by themselves previously.
+
+When a block is received, if any of the following happen the block is rejected (and its senders are banned):
+* any included operation is not legal (see the [legality section](#operation-format-and-legality))
+* the batched parallel signature verification of all the block operations is not a success
+* the block operations root hash does not match the one in the header
+* the cumulated size of all the operations in the block is strictly above 1MB
+
+This detects non-legal blocks early and prevents them from propagating in the network.
+
+## Operation total gas
+
+The `total_gas` of an operation is the total amount of gas reserved for its processing, preparation and execution.
+It depends on the type of operation.
+
+
+### Transaction, RollBuy, RollSell operations
+
+The `total_gas` of those types of operations is always 800000 which corresponds to their base processing cost.
+
+### CallSC operations
+
+The `total_gas` of a CallSC operation `op` is computed as follows:
+```
+total_gas =
+ 800000 (base operation processing gas cost)
+ + op.max_gas (the maximum gas reserved for bytecode execution, as provided in the `max_gas` field of the operation)
+```
+
+### ExecuteSC operations
+
+The `total_gas` of an ExecuteSC operation `op` is computed as follows:
+```
+total_gas =
+ 800000 (base operation processing gas cost)
+ + 314000000 (on-the-fly single-pass WASM compilation cost)
+ + op.max_gas (the maximum gas reserved for bytecode execution, as provided in the `max_gas` field of the operation)
+```
+
+
+## Operation execution
+
+When the consensus algorithm outputs the list of slots to execute,
+that list is fed to the Execution thread that executes slots asynchronously, in time order.
+
+The execution thread executes slots in order following two cursors: a candidate cursor and a final cursor.
+
+The candidate cursor attempts to execute all slots up to 2 seconds in the past.
+If a blockclique change happens, the candidate cursor is rolled back to the earliest slot that changed,
+and re-executes all the slots from there.
+This means that the execution state and outcomes of an operation executed in a non-final slot can change at any time.
+The 2 second latency serves the purpose of avoiding constant re-execution of the very volatile latest slots
+in order to save resources.
+This means that the candidate execution state of an operation can be observed after two seconds (or more)
+following the propagation of the block in which it was included.
+Overall, the deeper the slot is in the past, the exponentially more stable its candidate execution state is,
+up to finality after which it is guaranteed not to change anymore.
+
+The final cursor attempts to execute all final slots up to the latest one.
+Final execution is prioritary over candidate execution:
+as long as there are slots to finalize, they are processed before candidate slots.
+If a finalizing slot was previously executed as candidate and neither itself nor any if its ancestors has changed since the execution,
+the results of the slot's candidate execution are simply written to the final state to avoid re-executing it.
+
+When a slot is executed, if it contains a block, that block is executed.
+THe block's operations are tentatively executed in the order they appear in the block.
+For each operation in a block, the following is performed:
+* Gas check: if the remaining block gas (starting from `MAX_BLOCK_GAS = 4294967295`) is not enough to supply the operation's `total_gas`, the operation is ignored.
+* Thread check: if the thread of the operation sender does not match the thread of the block, the operation is ignored.
+* Period check: if the slot period of the block is not within the range of validity periods of the operation, the operation is ignored. The validity period interval of an operation `Op` is: `[expiration_period - 10, expiration_period]`.
+* Reuse check: if the operation is in the list of executed operations, the operation is ignored.
+* Fee spending: spend the fee from the sender's account. If this spending fails, ignore the operation.
+* Subtract the operation's `total_gas` from the remaining block gas.
+* Add the operation to the list of executed operations. Note that operations with an expiry period that is earlier or equal to the latest final period in the operation's thread are removed from this list after 10 extra periods in order to cap memory use.
+* If any of the previous steps failed, the operation is considered **NOT EXECUTED**, it is ignored and the block producer does not pocket any fees from it while wasting block space. Block producers should therefore be careful about the operations they choose to include or they might not get any fees from them. Thanks to sharding and the declarative `max_gas` and `max_coins` operation fields, block prodcuers can keep track of balances and gas usage without having to simulate the complete execution of candidate operations in order to avoid this pitfall.
+* From there on, the operation is considered executed.
+* Run the payload of the operation (for example call a smart contract). This can succeed or fail.
+ * In case of payload run failure, all the consequences of the payload run are rolled back, but the fee is still spent and the operation is still considered executed. This is because block producers have not enough computing power to simulate running all pending operations: this failure is the operation producer's responsibility. In this case, the operation is then considered **EXECUTED WITH FAILURE**.
+ * In case of payload run success, the consequences of the execution are kept, and the operation is considered **EXECUTED WITH SUCCESS**.
+
+Different types of operations have different payload run failure cases:
+* `Transaction`: fails if the balance of the origin account is not enough to cover the amount of the transaction.
+* `RollBuy`: fails if the balance of the origin account is not enough to cover the amount of the roll buy.
+* `RollSell`: fails if the the origin account has not enough rolls to sell.
+* `CallSC`: fails if any of the following happen:
+ * the balance of the origin account is not enough to cover the coins being transferred
+ * the target smart contract is not found
+ * the target smart contract has invalid bytecode
+ * the target smart contract exposes no function with the given name and expected prototype.
+ * the smart contract execution in the VM exceeds `max_gas`
+ * the smart contract execution in the VM raises a runtime exception
+* `ExecuteSC`: fails if any of the following happen:
+ * the bytecode is invalid
+ * the bytecode does not expose a `main` function with the right prototype
+ * the smart contract execution in the VM exceeds `max_gas`
+ * the smart contract execution in the VM raises a runtime exception
+ * the smart contract execution spends more than `max_coins` from the sender account
+
+The operation execution process in Massa implies some peculiarities:
+* the same operation can be included zero, one or many times in the same block or in different blocks but is executed either 0 or 1 times in total
+* it is not because an operation is included in a final block that the operation is executed as final
+
+## Operation pool and operation inclusion
+
+When creating blocks, block producers are free to include the operations they want in their blocks with certain constraints
+that would make the block non-legal and rejected at reception if they are not respected:
+* all operations in the block need to be well-formed
+* all the signatures of the included operations need to be legal
+* the cumulated size of all the operations in the block must be at most 1MB
+
+Block producers keep candidate operations in their operation pool.
+However, memory constraints on block producer hardware require regular pruning of this pool to keep it small and tailored to the block producer's needs:
+* discard operations that do not match the legality constraints listed above
+* discard operations that can not be included by this block producer given the expiry periods of the operation and proof-of-stake draws
+
+Block producers maximize their gains by prioritizing the operations that maximize their expected rewards.
+However, they don't have the computational power to simulate the execution of all potential operations.
+
+To solve this problem, operations are scored by block producers to estimate their expected rewards.
+This is done by a scoring algorithm that takes into account:
+* the expected rewards coming from the operation's `fee`
+* the probability of executing of the operation based on:
+ * whether the operation was already executed previously
+ * the number of opportunities other block producers have to execute the operation before the current node gets a chance to include it based on proof-of-stake selections
+* the usage of resources by the operation:
+ * the operation size (occupying space in the finite block size)
+ * the operation `total_gas` (occupying gas in the finite block gas `MAX_BLOCK_GAS`)
+Operations are then kept sorted by score, and the ones with the worst scores are discarded to respect the max size of the pool.
+
+Sorted operations are then scanned based on their declarative coin spending (`fee + max_coins`)
+and operations that overflow their sender's candidate balance given those cumulated spendings are discarded.
+The accurate evaluation of the balance without execution is made possible by sharding:
+no operation executed in blocks being created elsewhere at the same time can spend those coins.
+This protects the pool from flood attacks and guarantees that the operation fees can be spent.
+
+In Massa, operation pools are highly non-deterministic and depend on each block producer's proof-of-stake draws.
+The operation pool can therefore not be used as a reliable source of information about the propagation state of an operation.
+
+## Operation execution status and finality
+
+Because of the peculiar way Massa handles operations to achieve its scalability, security and decentralization goals,
+tracking the state of execution of an operation requires understanding certain principles.
+
+At the output of an executed slot `S`, an operation can be in one of the following observable states:
+* `EXECUTABLE_OR_EXPIRED`: the operation is not in the list of previously executed operations at the output of `S`:
+ * If the operation's expiry date is earlier or equal to the period of `S`, then the operation can not be executed anymore:
+ * The operation might never have been executed previously
+ * The operation might have been executed in a slot that finalized more than 10 periods ago. This is because the list of executed operations is pruned to limit its memory usage (see [operation execution section](#operation-execution)).
+ * Otherwise, it means that the operation was never executed and can be executed in the future.
+* `EXECUTED_WITH_SUCCESS`: the operation was executed at or before `S` and its payload run was successful (see [operation execution section](#operation-execution)). The operation can not be executed anymore.
+* `EXECUTED_WITH_FAILURE`: the operation was executed at or before `S` and its payload run generated errors (see [operation execution section](#operation-execution)). The operation can not be executed anymore.
+
+If the slot `S` is the latest candidate slot, then the observed status of a given operation at the output of `S` is considered candidate.
+As candidate slots are executed, candidate operation states can transition from any state into any other because blockclique changes might happen and rewrite the slot history.
+
+If the slot `S` is the latest executed final slot, then the observed status of a given operation at the output of `S` is considered final.
+As final slots are executed, the following final operation state transitions can be observed:
+* `EXECUTABLE_OR_EXPIRED` -> `EXECUTED_WITH_SUCCESS`: the operation was executed as final with success
+* `EXECUTABLE_OR_EXPIRED` -> `EXECUTED_WITH_FAILURE`: the operation was executed as final with failure
+* `EXECUTED_WITH_SUCCESS` -> `EXECUTABLE_OR_EXPIRED`: the operation was executed as final with success and then it expired and was pruned away
+* `EXECUTED_WITH_FAILURE` -> `EXECUTABLE_OR_EXPIRED`: the operation was executed as final with failure and then it expired and was pruned away
+
+Operations are guaranteed to be kept in the `EXECUTED_WITH_SUCCESS` or `EXECUTED_WITH_FAILURE` state for at least 10 periods (2 minutes and 40 seconds)
+to give enough time for operators to register those states before they are pruned.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/storage-costs.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/learn/storage-costs.mdx
new file mode 100644
index 000000000..8af727139
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/storage-costs.mdx
@@ -0,0 +1,89 @@
+---
+id: storage-costs
+sidebar_label: Storage costs
+---
+
+# Storage costs
+
+In Massa, each network node maintains a full copy of the ledger.
+To prevent the requirement of massive storage capacities, a ledger-size limit of 10TB has been set.
+This limit is essential to encourage widespread adoption and enable users to run nodes from their homes.
+To ensure compliance with this limit, a mechanism has been established that correlates storage space with locked coins.
+
+For every byte of storage space claimed, whether it's for storing address and balance information,
+keys in the datastore, bytecode, or other data elements, users are required to lock a corresponding amount of coins.
+These locked coins act as a commitment and are released when the allocated storage space is released.
+
+To determine the amount of coins needed to lock for each byte of storage, the value of 0.0001 Massa coin (MAS) has been chosen.
+This value ensures that if all of the total initial coin supply (1,000,000,000 MAS) is locked for storage only,
+the 10TB limit is reached and no account can push this limit further because there are no more coins available.
+
+The initial ledger entry for address and balance incurs a cost of 0.001 MAS.
+
+Datastore entries also occupy space:
+* a base size of 4 bytes that represents the average storage used for storing an empty key-value entry
+* the length of the key
+* the length of the value
+
+To calculate the storage cost for a specific address in the ledger, the formula includes the address size, balance constant, bytecode length,
+and the sum of constants for each datastore key and its corresponding value size.
+
+The overall formula is:
+
+$$
+Cost_{MAS} = 0.001 + 0.0001 * BytecodeSize + 0.0001 * \sum_i (4 + DataStoreKeySize_i + DatastoreValueSize_i)
+$$
+
+It's important to note that the storage costs are always paid by the address that initiates the Application Binary Interface (ABI) call.
+For example, if the ABI functions [setBytecode](https://as-sdk.docs.massa.net/functions/setBytecode.html) or [setBycodeOf](https://as-sdk.docs.massa.net/functions/setBytecodeOf.html) are used,
+the associated storage costs will be charged to the address making the call.
+
+
+## Examples
+
+### Transferring coins to a non-existing account
+
+
+When creating a new account in Massa, a minimum of 0.001 MAS needs to be sent alongside the operation that creates the new account (e.g., a transfer).
+This cost covers the creation of the address and its associated balance.
+
+You create a new account using the Massa Client `massa-client`, you can generate a secret key `(wallet_generate_secret_key)`) and verify its address using the `wallet_info` function.
+However, that operation is done fully offline and the new account does not appear in the blockchain just yet.
+
+Now imagine a sender account wants to send `10 MAS` to your new account using a Transaction operation transferring `10 MAS` to your newly generated address.
+Since the newly created account is not in the state just yet,
+`0.001` coins from the transferred amount are reserved for writing the account address and balance,
+and your newly created account's balance becomes `9.999`.
+Note that if the transferred amount is lower than `0.001 MAS`, the new destination account can not be written and the operation payload run fails.
+
+In any subsequent transfers towards your now-written account,
+no coins will be reserved for storage and you will receive the full transferred amount.
+
+### Datastore handling in a smart contract
+
+Suppose you want to store your username "kevin" under the key "username" in the datastore of an existing account, both in utf-8 bytes.
+The value is 5 bytes long and the key is 8 bytes long and we assume that that entry did not exist before in the datastore of the account.
+In that case, you need to send an operation that creates this new entry in your datastore using a Smart Contract.
+Storing the entry locks `0.0001 * (4 + 8 + 5) = 0,0017` MAS coins.
+
+Now suppose that you change that existing entry to a new nickname "kev".
+The new value is shorter: freeing 2 bytes causes `0.0001 * 2 = 0.0002` coins to be refunded.
+
+Now let's change the nickname again from "kev" to "ned". This does not change the datastore size and does not change the coin balance.
+
+Now, let's change the nickname again from "ned" to "pierre".
+This uses 3 extra byte and therefore locks `0.0001 * 3 = 0.0003` MAS coins.
+
+In case you then delete the "nickname" datastore entry (with the "pierre" value),
+`0.0001 * (4 + 8 + 6) = 0.0018` coins are refunded.
+
+:::info
+
+In the case of a refund for storage costs, the address that receives the refund is the one that initiates the ABI call
+([setBytecode](https://as-sdk.docs.massa.net/functions/setBytecode.html) or [setBycodeOf](https://as-sdk.docs.massa.net/functions/setBytecodeOf.html) for example),
+ which may differ from the address that initially paid for the storage.
+
+If you are a Smart Contract developer and want your users to cover the storage costs for your contract, you can utilize the coins passed via the "`coins`" parameter of the "`CallSC`" operation.
+Additionally, you can save their addresses in your datastore to facilitate future refunds.
+:::
+
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/learn/tokenomics.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/learn/tokenomics.mdx
new file mode 100644
index 000000000..01e3ece4c
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/learn/tokenomics.mdx
@@ -0,0 +1,119 @@
+---
+id: tokenomics
+sidebar_label: Tokenomics
+---
+
+# Massa Tokenomics
+
+## Introduction
+
+:::note
+This page reproduces most of the whitepaper's Tokenomics section, with additional details and updates.
+:::
+
+Massa, true to its values, has implemented a unique tokenomics model that emphasizes fairness and decentralization. This model ensures that the Massa token is distributed widely among the community, reducing the risk of centralization that can result in unfair voting practices, price manipulation, and security issues:
+- **Unfairly-distributed voting**: When a small number of entities control a significant portion of a blockchain's tokens, they can disproportionately influence governance decisions, undermining the democratic principles that underpin decentralized systems.
+- **Price manipulation**: Token centralization can also lead to price manipulation, as large holders can exert undue influence on the market, creating artificial fluctuations that distort the true value of the token.
+- **Security issues**: A centralized token distribution can lead to security vulnerabilities, as malicious actors can target the limited number of entities controlling a large portion of the token supply. It also generates centralization in block production, leading to protocol-level risks.
+
+Massa is committed to maintaining the highest standards of decentralization, with the goal to achieve a Nakamoto coefficient of over `1,000`, ensuring that control and decision-making power are widely distributed across the community. Achieving this not only requires efforts on the technical and legal design, but also on the coin distribution. On this aspect, we crafted three main particularities compared to other L1 blockchain coin distributions:
+- **Less tokens for the company/founders**: Massa Labs and founders are allocated `12%` of the total supply.
+- **Less tokens for insiders**: The maximum number of tokens bought per entity in all ourtoken sales is relatively small. For instance, the cap was `1%` of the total supply in the
+seed sale, allowing a record number of `100` backers in such a sale. Also, the supply allocated to these private sales is only `16%` in total.
+- **More tokens for future builders and stakers**: the Decentralization Program sets aside `30%` of the supply to grow the future builders and stakers community, with the aim to achieve full decentralization in a transparent way.
+
+These steps together improve the token decentralization, limit the influence of early insiders and VCs, and limit the formation of whales whose only remaining option is to buy on the market.
+
+## Initial Coin Distribution
+
+The total initial token supply is `1,000,000,000` Massa tokens. These initial tokens are created in the genesis ledger. They are distributed as follows.
+
+
+
+- **Massa Labs & Founders**: `12%`, `120,000,000` tokens. This allocation goes to the team, the founders and a reserve for Massa Labs, to ensure that the main development team is invested in the project's long-term success. These coins are vested linearly for `60` months, with a `5%` initial unlock.
+- **Private Sales**: Up to `16%`, `160,000,000` tokens. These coins are vested linearly for `24` months, with a `30%` initial unlock.
+- **Community and Ecosystem**: `31%`, `310,000,000` tokens. This allocation is managed by the Massa Foundation. Its purpose is to foster the growth of the Massa community and ecosystem in the long term through grants, marketing actions, partnerships and other programs. These coins are vested linearly for `60` months, with a `5%` initial unlock.
+- **Testnet Incentive Program**: up to `8%`, `80,000,000` tokens. The Testnet Incentive Program rewards the thousands of node runners who successfully participated in the testnet. These coins are vested linearly for `24` months, with a `30%` initial unlock.
+- **Public Sale**: `3%`, `30,000,000` tokens. These coins are going to be vested for some time, cf future updates.
+- **Decentralization Program**: `30%`, `300,000,000` tokens. In the initial ledger, these coins are vested for `60` months with a `24`-month cliff and then `36` months linear. Tokens not distributed after `96` months will be burnt. They are composed of:
+ - **100k-nodes Program**: `20%`, `200,000,000` tokens. The goal of this pool is to grow the number of individual stakers participating in the security of the network and in the core governance. Compared to the coin distribution of other L1s biased towards insiders who later sell large chunks in opaque deals or on the market, this alternative mechanism provides more transparency and decentralization. This pool, managed by the Foundation, is dedicated to be bought by new node runners with a low cap per person and at a slow pace between `2` and `8` years post-mainnet, with vesting.
+ - **2k-builders Program**: `10%`, `100,000,000` tokens. The goal of this program is to grow a larger builder community with many grants, involving the Massa holders in the decisions to give grants. These grants have a smaller size than with the main grant program: they are capped at `50k` tokens per project.
+
+## Nakamoto Coefficient
+
+With this data, we can compute the Nakamoto coefficient of the coin after full distribution. The Nakamoto coefficient is computed as the minimum number of independent entities/persons required to reach `50%` of the total supply. We take the most concentrated categories and count the expected number of entities/people until we reach `50%`:
+- Massa Labs: `12%`, at least `100` people
+- Private sales: `16%`, at least `100` people
+- Community and Ecosystem: expecting `1,000+` people in the first `22%`.
+
+Thanks to the fair distribution with smaller pools for insiders and larger pools dedicated to the community, the Nakamoto coefficient of Massa aims to be well over `1,000` on the long-term when all the categories are distributed. On the short-term, only parts of these categories will be effectively disctributed. The next section describes the distribution right on mainnet launch.
+
+## Genesis Ledger
+
+The genesis ledger is the initial distribution of coins when the network starts. Some of these coins appear as initial rolls instead of tokens (1 roll = 100 tokens) giving the ability to stake right from launch.
+
+The genesis ledger files have been set up in this GitHub [folder](https://github.com/Massa-Foundation/genesis-ledger/tree/main/node_initial_setup).
+
+- [genesis_timestamp.json](https://github.com/Massa-Foundation/genesis-ledger/blob/main/node_initial_setup/genesis_timestamp.json): file containing the start date of the Massa mainnet.
+- [initial_ledger.json](https://raw.githubusercontent.com/Massa-Foundation/genesis-ledger/main/node_initial_setup/initial_ledger.json): file containing the initial unlocked coins.
+- [initial_rolls.json](https://github.com/Massa-Foundation/genesis-ledger/blob/main/node_initial_setup/initial_rolls.json): file containing the initial rolls: more than `1,000` node runners have registered to be initial stakers right from launch!
+- [deferred_credits.json](https://raw.githubusercontent.com/Massa-Foundation/genesis-ledger/main/node_initial_setup/deferred_credits.json): file containing all the scheduled unlocking of coins.
+
+The total number of tokens in `initial_ledger.json`, `initial_rolls.json` (`x100` tokens per roll), and `deferred_credits.json` is exactly `1,000,000,000`. These files have been generated with a [script](https://github.com/Massa-Foundation/genesis-ledger/blob/main/generator.py), from this [data](https://github.com/Massa-Foundation/genesis-ledger/tree/main/input_listings), where you can find the following:
+- [backers.json](https://github.com/Massa-Foundation/genesis-ledger/blob/main/input_listings/backers.json): backers of Massa Labs who gave their addresses in time. Backers who did not provide their addresses have their coins kept in address `AU1PGvG4x1rmFaYBgSNVmgpPDkWvGtNqS2Jc7BjupmVjkce8dBai` for now.
+- [dashboard_data.json](https://raw.githubusercontent.com/Massa-Foundation/genesis-ledger/main/input_listings/dashboard_data.json): here you can find participants of the dashboard campaign, ambassadors, and testnet node runners who were eligible for a reward, with corresponding coins and if they want to be initial stakers. These tokens are vested for `24` months, with a `30%` initial unlock, and the release is approximately once per month, with some random noise to smooth the unlockings (e.g. on month `3`, a user might get tokens released on day `3` while another gets tokens on day `10`).
+- [foundation.json](https://github.com/Massa-Foundation/genesis-ledger/blob/main/input_listings/foundation.json): here are the three main addresses of the Massa Foundation. The first corresponds to the `310,000,000` tokens from category "Community and Ecosystem", from which above rewards were deducted. These tokens are vested for `60` months. The second is reserved for a public sale. These tokens are unlocked for now, but they are going to move to a vested smart contract for users to claim their tokens. The third address is the decentralization program address, with `2` years cliff and then `3` years linear vesting.
+- [founders.json](https://github.com/Massa-Foundation/genesis-ledger/blob/main/input_listings/founders.json) is an allocation reserved for founders. These tokens are unlocked at genesis and will be moved just after launch to a vested smart contract where tokens will be claimable, with `5%` initially unlocked and `95%` vested for `60` months.
+- [labs.json](https://github.com/Massa-Foundation/genesis-ledger/blob/main/input_listings/labs.json). These are Massa Labs' tokens, with `5%` as initial rolls to start staking right from launch, together with the community, and the other `95%` vested for `60` months. Massa Labs will thus start staking with `35,000` rolls. This is a large proportion of the total stake at launch, but it is expected to decrease significantly in the next days and weeks after launch when all other categories will ramp up with setting up their nodes.
+
+
+## Expected Unlocked Supply
+
+Taking into account the vesting schedules of all categories, we can estimate the evolution of the unlocked supply. Note that many of these unlocked tokens will not be effectively circulating, because they will be held as reserves by Massa Labs and Massa Foundation.
+This figure does not account for staking rewards (see next section).
+
+
+
+## Staking Rewards
+
+Staking is the process of running a validator node verifying the blockchain and creating blocks. In Massa as in other Proof-of-Stake blockchains, nodes are selected to create blocks based on their deposited coins –their stake in the blockchain.
+
+As staking improves the decentralization and security of the network, this behavior is incentivized by staking rewards: the higher the number of staked coins, the higher the number of created blocks and received rewards.
+
+To improve decentralization and dedicate rewards to independent node runners, there is no delegation mechanism in Massa, and custodial staking is limited by the [community charter](https://github.com/massalabs/massa/blob/main/COMMUNITY_CHARTER.md).
+
+A minimum number of coins must be deposited to be able to stake, corresponding to one roll. The number of coins in a roll is set to `100`. Users deposit coins to get a number of rolls and stake with these rolls. When they want to stop staking, they can get back their coins after a small locking period and lose the corresponding rolls. When the staking address is selected to produce a block, the node is expected to produce exactly one block.
+
+If the node is offline for some reason, it misses the opportunity to produce the block and to get the reward. If the node is missing these opportunities too often, it is automatically deactivated and its rolls are sold and fully given back as coins. If the node produces more than one block in a selected slot, this is considered as bad behavior and is punished with slashing: one roll is slashed, completely lost and no coins are given back.
+
+At each slot, one staking address is selected to produce a block, and in order to improve consensus speed, `16` other addresses are selected to create endorsements —votes about the best blocks. A maximum minted reward of `1.02` tokens is distributed per slot. If there was a block in this slot, the reward is distributed as follows:
+- `0.06` tokens are given to the block creator
+- For each endorsement included in the block (up to `16`)
+ - `0.02` tokens are given to the block creator
+ - `0.02` tokens are given to the endorsement creator
+ - `0.02` tokens are given to the creator of the endorsed block
+
+Block and endorsement creators also share the gas fees of all transactions included in the block, and half of the slashed coins, the other half being burnt. However, all the fees of autonomous smart contracts are burnt as they run outside blocks.
+
+There are `2` slots per second in Massa architecture, so these rewards add up to a maximum of `64,377,504` newly-minted Massa tokens per year, distributed to active staking nodes. The inflation rate is therefore approximately `6.4%` during the first year, and decreases each year as the total supply increases.
+
+As less than the total supply is expected to be staking at any point in time, the actual return per year for active stakers will be higher than this percentage. The next figure shows the maximum inflation rate and an estimation of the annual percentage return (APR) for staking nodes over time.
+
+
+
+
+
+### Example: How to compute my expected staking rewards ?
+
+Let's assume I currently have `20` initial rolls from genesis, and after launch I buy `3` other rolls, that's `23` rolls in total, equivalent to `2,300` tokens, that I currently use to stake with my node.
+
+I can monitor the total number of rolls currently staked on the network on the Massa [explorer](https://explorer.massa.net/). Let's assume I see that `500,000` rolls are staked (low number, maybe only in the first weeks after mainnet). I thus produce `0,0046%` of blocks and endorsements.
+
+There are `172,800` blocks per day, so I expect to produce `8` blocks per day on average, but also approximately `127` endorsements per day. The maximum rewards given per block is `1.02` tokens (for block and endorsement producers), which is `176,256` tokens per day. Thus I can expect `176,256 * 0,0046% = 8.1` tokens per day for my `23` rolls, assuming `500,000` rolls are staked in total, and assuming I am always online and I don't miss a block!
+
+These rewards do not take into account potential gas fees that will be set by users if the network becomes congested one day.
+
+The staking rewards are unlocked, so after `13` days, I should have `105` tokens and I will be able to buy a `24th` roll!
+
+
+
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/browse-decentralized-application.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/browse-decentralized-application.mdx
new file mode 100644
index 000000000..efa120595
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/browse-decentralized-application.mdx
@@ -0,0 +1,21 @@
+---
+id: browse-decentralized-application
+title: Browse Decentralized Application
+---
+
+## Browse Decentralized Application
+
+*Massa Station* enables you to browse decentralized applications (dApps) hosted on the blockchain and interact with them.
+
+### Browsing Steps
+
+1. Open *Massa Station*.
+2. Click on the **Search Massa ecosystem** button.
+
+
+
+3. Search for the website you want to browse.
+
+
+
+4. Click on it to open it in your web browser.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/browse-decentralized-application_scroll.png b/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/browse-decentralized-application_scroll.png
new file mode 100644
index 000000000..42d8e21b6
Binary files /dev/null and b/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/browse-decentralized-application_scroll.png differ
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/browse-decentralized-application_search_ecosystem.png b/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/browse-decentralized-application_search_ecosystem.png
new file mode 100644
index 000000000..042e8e6c2
Binary files /dev/null and b/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/browse-decentralized-application_search_ecosystem.png differ
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/faq.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/faq.mdx
new file mode 100644
index 000000000..e696d52c2
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/faq.mdx
@@ -0,0 +1,137 @@
+---
+id: faq
+title: FAQ
+---
+
+## Massa Station Installation
+
+### How do I install Massa Station?
+
+You can install Massa Station by following the instructions on the [installation page](/docs/massaStation/install).
+
+### How do I update Massa Station?
+
+You can update Massa Station by following the same instructions as the installation process. You can find the instructions on the [installation page](/docs/massaStation/install).
+
+### How do I uninstall Massa Station?
+
+You can uninstall Massa Station by following the instructions on the [uninstallation page](/docs/massaStation/uninstall).
+
+### Installation failed, what do I do?
+
+If you are having trouble installing Massa Station, please check the [installation troubleshooting page](/docs/massaStation/troubleshooting) for help.
+
+### Installation fails because of unsupported OS version. What to do?
+
+For now, Massa Station is only supported on Windows 10 and 11, MacOS 12 and later, and Debian based Linux distributions.
+
+If you are using an unsupported operating system, you can still try to install Massa Station manually by following the instructions on the [manual installation page](/docs/massaStation/manual-install).
+
+### Antivirus blocked installation of Massa Station. What to do?
+
+We want to assure you that Massa Station is free from viruses, and the antivirus warning is a false positive. We're in the process of obtaining necessary certificates (such as from Apple for MacOS versions), which can trigger such warnings.
+Being a blockchain app, Massa Station interacts with distant servers and performs cryptographic operations. Antivirus warnings for new apps in this category are common but are mostly not indicative of any threat. If you are using an antivirus that blocks Massa Station, you can try to add Massa Station to the whitelist.
+
+Massa Station’s code is publicly accessible and auditable on [GitHub](https://github.com/massalabs/station), which means that anybody can check what’s happening. It’s part of our commitment to transparency and security.
+
+## Massa Station Usage
+
+### How do I use Massa Station?
+
+We have detailed instructions on how to use Massa Station such as:
+
+- [Browse Decentralized Apps](/docs/massaStation/browse-decentralized-application)
+- [Install Massa Wallet](/docs/massaStation/massa-wallet/getting-started)
+
+### Why can't I use Massa Station on mobile?
+
+Massa Station is a desktop super-app that, once opened, operates within your web browser. A mobile version is not available at this time.
+
+### How to connect Massa Station to my own node
+
+For users operating on Debian, Ubuntu, navigate to `~/.config/massa-station`.
+For macOS systems, navigate to `~/Library/Application Support/massa-station`.
+If you are using Windows, the corresponding directory is `%APPDATA%\massa-station`.
+Once there, locate and modify the `config_network.yaml`.
+You'll want to append the following lines to the bottom of the file:
+
+```yaml
+NodeName:
+ URLs:
+ - https://my-node-url
+ ChainID:
+ Default: false # or true if you want to set this node as the default
+```
+
+Replace `NodeName` with a name of your choosing for the node, this will appear in the dropdown menu.
+
+Make sure that the URL exactly matches the RPC endpoint of your node. This URL is how Massa Station will communicate with your node.
+
+Additionally, suppose you frequently access a particular node and prefer Massa Station to automatically select this node on start-up.
+In that case, you can make it the default node by changing the `Default` field to `true`,
+and change the default field for the mainnet node to `false`.
+
+After these lines are added, close and reopen Massa Station. Your newly named node will now be a part of the network selection dropdown menu.
+Selecting it will connect Massa Station and its plugins, such as Massa Wallet, to your specified node.
+
+For those whose nodes are on the MainNet, it's essential that the `ChainID` accurately reflects the MainNet's chain ID,
+By ensuring the correct `ChainID` is set, your Massa Station will be in sync with the intended network.
+
+### Why can't I access Massa Station from my browser?
+
+Massa Station must be installed and running on your computer to be able to access it from your browser. If you have installed Massa Station, please make sure it is running.
+
+If Massa Station is running, please check that you are using the correct URL. The URL should be `https://station.massa/`.
+
+If you are still having trouble accessing Massa Station, please check the [troubleshooting page](/docs/massaStation/troubleshooting) for help.
+
+### "Install" module button doesn't work. What to do?
+
+This is a known issue that happens when a module is stored on GitHub. We are investigating the issue.
+
+In the meantime, you can install the module manually by following the instructions on the right panel of the module store.
+
+For example with the Massa Wallet module:
+
+1. Go to the [latest Massa Wallet release page](https://github.com/massalabs/station-massa-wallet/releases/latest).
+2. Copy the URL of the `.zip` file corresponding to your operating system.
+3. Paste the URL in the right panel of the module store and click on "Install".
+
+### Why isn't Massa Station working on Safari?
+
+Massa Station is only available in HTTP on Safari. Supporting HTTPS on Safari is on our roadmap but we don't have an ETA yet.
+
+To use Massa Station in HTTP on Safari, simply modify the URL to http://station.massa/ (or click on the link).
+
+### How to enable HTTPS on unsupported browsers?
+
+To enable HTTPS on unsupported browsers, you need to install the Massa Station certificate authority.
+
+1. Locate the certificate authority file at the following path:
+ - On Windows, follow those steps:
+ 1. Copy this path: `C:\Program Files (x86)\MassaStation\certs\`
+ :::caution
+ The path might be different if you changed Massa Station location
+ :::
+ 2. Open the File Explorer
+ 3. Paste the path you copied previously in the address bar
+ 4. Press enter
+ - On Macos, follow those steps:
+ 1. Copy this path: `/etc/massastation/certs/`
+ 2. Open finder
+ 3. Click on the "Go" button at the top left of your screen
+ 4. Click on the "Go to folder..." button at the bottom of the menu
+ 5. Paste the path you copied previously
+ 6. Press enter
+ - On Linux, the file is located in `/etc/massastation/certs/`
+2. In this folder, you will find a file named `rootCA.pem`. Keep this folder open, you will need it in the next steps.
+3. Open your browser's settings or preferences.
+4. Search for the "Security" or "Privacy" section, and look for an option related to certificates.
+5. Find the option to import or add a certificate authority.
+6. Choose the `rootCA.pem` file from the specified path.
+
+## Massa Wallet installation
+
+### How to solve a `Wallet can't be opened` issue?
+
+It depends on your OS and its configuration, please check the [troubleshooting page](/docs/massaStation/troubleshooting#linux-3)
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/guidelines.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/guidelines.mdx
new file mode 100644
index 000000000..7615910fb
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/guidelines.mdx
@@ -0,0 +1,75 @@
+---
+id: guidelines
+title: Plugin Creation Guidelines
+---
+
+# Plugin Creation Guidelines
+
+One of the advantages of Massa Station is its flexibility in allowing plugins to be developed in any programming language. In order for modules to work with Massa Station, they must adhere to specific guidelines and specifications.
+
+## Plugin Overview
+
+Massa Station plugins are essentially binaries with a few specific requirements, as defined in this document.
+
+Since Massa Station plugins are binaries, developers have the freedom to use their preferred programming language to create plugins that work seamlessly with Massa Station. Most of our Massa Station products and documentation are using Go because it's the language we use internally. However, we encourage developers to use any language they prefer.
+
+For detailed steps on creating a plugin, please refer to the [create plugin guide](/docs/massaStation/hello-world-plugin).
+
+## Plugin binary specifications
+
+When Massa Station starts a plugin, it generates a unique ID for the plugin and passes it as a parameter to the plugin binary. Once the plugin has started, it must register itself to Massa Station to confirm that it is running properly.
+
+Plugins are started as follows:
+
+```bash
+./plugin-binary
+```
+
+At startup, the plugin must retrieve the plugin ID from the command line arguments.
+Following the startup, the plugin must register itself by calling the `/plugin-manager/register` endpoint of Massa Station, providing the assigned ID.
+
+:::info
+Massa Station will respond with a 204 status code if the registration is successful. In case of failure, the plugin must exit with a non-zero exit code.
+:::
+
+## Plugin Packaging
+
+To be installed in Massa Station, a plugin must be packaged as a Zip Archive, tailored for each targeted operating system.
+
+### Supported OS Configurations
+
+Currently, Massa Station supports the following OS configurations:
+
+- Windows 10/11, AMD64
+- Linux, AMD64
+- macOS, AMD64
+- macOS, ARM64
+
+
+### Archive Structure
+
+A plugin Zip Archive must contain the following files and adhere to the specified structure:
+
+1. **Plugin Binary**: The plugin's binary, withch should follow the statdards
+2. **Logo**: The archive must include a valid image file that serves as the plugin's logo. Refer to [the Mozilla Developer Network](https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types) for valid image formats.
+ :::tip
+ This logo will be displayed in the Massa Station interface. To ensure a good user experience, we recommend using a square image with a minimum size of 128x128 pixels.
+ :::
+
+3. **Manifest**: The plugin must have a `manifest.json` file at the root of the Zip Archive. This manifest provides essential information to Massa Station for displaying the plugin in the user interface. The `manifest.json` file must include the following properties:
+
+ | Field | Description | Format | Specifications |
+ | ----------- | ----------------------------- | ------ | ---------------------------------------------------------------- |
+ | Author | Module author's name | text | Maximum 30 characters |
+ | Name | Module name | text | Maximum 30 characters |
+ | Description | Module short description text | text | Maximum 80 characters |
+ | Logo | Module logo file name | text | Example: logo.png |
+ | Home | URL to module home page | URL | Format: `http(s)://example.com` |
+ | Version | Module version | text | Follow [Semantic Versioning 2.0](https://semver.org/spec/v2.0.0) |
+ | APIspec | API specifications | text | Swagger file |
+
+ :::info
+ See the example manifest of the Hello-World plugin: [Hello-World Manifest](https://github.com/massalabs/station-massa-hello-world/blob/v0.0.8/manifest.json)
+ :::
+
+4. **Optional: Additional Resources**: Any additional resources for the plugin such as configuration files, images, etc.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/hello-world-page.png b/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/hello-world-page.png
new file mode 100644
index 000000000..b9d373834
Binary files /dev/null and b/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/hello-world-page.png differ
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/hello-world-plugin.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/hello-world-plugin.mdx
new file mode 100644
index 000000000..d41b48579
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/massaStation/hello-world-plugin.mdx
@@ -0,0 +1,783 @@
+---
+id: hello-world-plugin
+sidebar_label: '"Hello, World!" Plugin'
+---
+
+# Build a Hello World Massa Station plugin
+
+Welcome, Developer! You're about to embark on an exciting journey where you'll build your very first Massa Station
+plugin. If you're thrilled about the world of blockchain, smart contracts, and dApps, you've come to the right place!
+
+As the most decentralized blockchain, Massa is a community-driven project. Thus, we tried to make as few assumptions as
+possible about the form and features that a module should have. As a result, *Massa Station* modules can be developed in
+any language, be more web2 or web3-oriented, and can be as simple or complex as you want them to be. In this tutorial,
+we are going to build the simplest of the programs; a "Hello, World!" *Massa Station* plugin.
+
+:::info
+If you don't know what are Massa Station and Massa Station Plugins, you can read this quick introduction [here](/docs/massaStation/home.mdx).
+:::
+
+## What are we going to do?
+
+In this tutorial, we are going to develop a simple "Hello, World!" Massa Station plugin. This plugin will be composed of two parts: a back end and a front end. The back end will be a simple API that will allow Massa Station to interact with the plugin. The front end will be a simple web page that will be displayed when the plugin is called without any endpoint specified.
+
+- **Prerequisites**: We will install the necessary tools to develop the plugin.
+- **Part 1**: We will create an API server using go-swagger.
+- **Part 2**: We will register our API server to Massa Station.
+- **Part 3**: We will define our endpoint.
+- **Part 4**: We will add a frontend to the plugin.
+
+## Prerequisites
+
+### Install Golang
+
+Make sure that you have [Golang](https://go.dev/doc/install) installed on your machine. You can check if it is installed by running `go version` in your terminal. If you don't have Golang installed, you can follow the [official installation guide](https://go.dev/doc/install). Make sure you add `go` to the PATH environment variable.
+
+### Install Go Swagger
+
+Make sure you have [Go Swagger](https://pkg.go.dev/github.com/go-swagger/go-swagger) installed on your machine. If you don't have Go Swagger installed, you can follow the [official installation guide](https://pkg.go.dev/github.com/go-swagger/go-swagger). Also, make sure that the folder containing the Go Swagger binary is added to the PATH environment variable. It's usually located in the default go workspace folder: `$GOPATH/bin`. Once installed, you can check if it is installed by running `swagger version` in your terminal.
+
+### Install Massa Station
+
+Make sure that you have [Massa Station](https://station.massa.net) installed on your machine. You can install it by downloading the installer on the official [Massa Station website](https://station.massa.net). Once downloaded, run the installer and let it guide you through the installation process.
+
+If you can produce a similar output in your terminal, then you should be good to go:
+
+```bash
+❯ go version
+go version go1.21.0 linux/amd64
+❯ swagger version
+version: v0.30.5
+commit: (unknown, mod sum: "h1:SQ2+xSonWjjoEMOV5tcOnZJVlfyUfCBhGQGArS1b9+U=")
+❯ massastation
+2023-08-22T15:28:25.058+0200 INFO logger/global.go:51 Connected to node server https://buildnet.massa.net/api/v2 (version DEVN.24.1)
+2023-08-22T15:28:25.060+0200 INFO logger/global.go:62 Serving massastation at http://[::]:80
+2023-08-22T15:28:25.061+0200 INFO logger/global.go:62 Serving massastation at https://[::]:443
+
+```
+
+## Setting up the project and creating the plugin's API.
+
+### Initialize the project
+
+Navigate to your favorite folder and create a new folder for your project. In this tutorial, we will name it `my-plugin`. Navigate to the `my-plugin` folder and initialize it as a go module by running the following command:
+```bash
+go mod init my-plugin
+```
+This will create a `go.mod` file in the `my-plugin` folder.
+
+### Define the server stub configuration
+
+Now, let's create the server stub. To do so, we will use the [go-swagger](https://pkg.go.dev/github.com/go-swagger/go-swagger) tool. Go Swagger allows you to generate a server stub from a swagger file. The server stub will contain the API's endpoints and the necessary code to run the server.
+
+So go ahead and create an `api` folder in the `my-plugin` folder.
+Then, create a `swagger.yml` file in the `my-plugin/api` folder. This file will contain the server specification. Add the following configuration to the `swagger.yml` file:
+
+```yaml
+consumes:
+ - application/json
+info:
+ description: Hello world plugin API.
+ title: hello-world-plugin
+ version: 0.0.0
+produces:
+ - application/json
+schemes:
+ - http
+swagger: "2.0"
+paths:
+ /:
+ get:
+ operationId: defaultPage
+ responses:
+ "301":
+ description: Move to the default endpoint
+```
+
+Now we are going to need a target directory to store the generated server stub.
+So go ahead and in the `my-plugin/api` folder, create a new folder named `server`.
+
+Navigate back to the root directory `my-plugin` and create a `generate.go` file. This file will contain the command that generates the server stub from the swagger file when you run `go generate ./...`.
+
+Add the following code to `generate.go`:
+
+```go
+package main
+
+//go:generate swagger generate server --quiet --target api/server --name my-plugin --spec api/swagger.yml --exclude-main
+```
+
+:::note
+Here we are using the `swagger generate server` command to generate the server stub. The `--target` flag is used to specify the target directory. The `--name` flag is used to specify the name of the server. The `--spec` flag is used to specify the swagger file. The `--exclude-main` flag is used to exclude the `main` function from the generated code. We will add our own `main` function later on.
+:::
+
+### Generate the server stub
+
+Now that we have defined the server configuration, we can generate the server stub. To do so, run the following command in the root directory `my-plugin`:
+```bash
+go generate ./...
+```
+This will generate the server stub in the `my-plugin/api/server` folder. At this point, you should have the following folder structure:
+
+```bash
+my-plugin
+├── generate.go
+├── go.mod
+├── api
+│ ├── swagger.yml
+│ ├── server
+│ │ ├── restapi
+│ │ │ ├── server.go
+│ │ │ ├── configure_my-plugin.go
+│ │ │ ├── doc.go
+│ │ │ ├── embedded_spec.go
+│ │ │ ├── operations
+│ │ │ │ ├── default_page.go
+│ │ │ │ ├── default_page_parameters.go
+│ │ │ │ ├── default_page_responses.go
+│ │ │ │ ├── default_page_urlbuilder.go
+│ │ │ │ ├── my_plugin_api.go
+
+```
+Once you are done generating the server stub, we are going to need to edit one of the generated file. Indeed, the default CORS setting will block requests between Massa Station plugins. But as requests between Massa Station plugins are local, there is no risk with allowing CORS.
+So go ahead and open the `my-plugin/api/server/restapi/configure_my-plugin.go` file.
+Delete the current `setupGlobalMiddleware` function and replace it with the following code:
+
+```go
+func setupGlobalMiddleware(handler http.Handler) http.Handler {
+ handleCORS := cors.New(cors.Options{}).Handler
+
+ return handleCORS(handler)
+}
+```
+
+:::tip
+At the beginning of the file, you should see the following comment:
+```go
+// This file is safe to edit. Once it exists it will not be overwritten
+```
+This comment indicates that the file will not be overwritten when you re-generate the server stub. So you shouldn't have to edit it again when regenerating the server stub.
+:::
+
+We will also need to install the `cors` package with the following command:
+```bash
+go get github.com/rs/cors
+```
+Then we will need to import it in the `my-plugin/api/server/restapi/configure_my-plugin.go` file. So go ahead and open the `configure_my-plugin.go` file and add the following line to the imports section:
+
+```go
+ "github.com/rs/cors"
+```
+
+### Create the logic of the API
+
+Create `my-plugin.go` in the root of your project and add the following code that implements the API's logic:
+
+```go
+package main
+
+import (
+ "fmt"
+ "os"
+ "os/signal"
+ "syscall"
+ "time"
+
+ "my-plugin/api/server/restapi"
+ "my-plugin/api/server/restapi/operations"
+
+ "github.com/go-openapi/loads"
+)
+func killTime(quit chan bool) {
+ // creates a ticker that will send a message every 5 seconds
+ ticker := time.NewTicker(5 * time.Second) //nolint:gomnd
+
+ fmt.Fprintf(os.Stdout, "Plugin is initializing.\n")
+
+ for {
+ select {
+ case <-ticker.C:
+ fmt.Fprintf(os.Stdout, "Tic!\n") // logs a message every 5 seconds
+ case <-quit:
+ fmt.Fprintf(os.Stdout, "Plugin is shutting down.\nBye!\n") // logs a message when the plugin is shutting down
+
+ return
+ }
+ }
+}
+
+func initializeAPI() *restapi.Server {
+ swaggerSpec, err := loads.Analyzed(restapi.SwaggerJSON, "") // loads the swagger file
+ if err != nil {
+ panic(err)
+ }
+
+ pluginAPI := operations.NewMyPluginAPI(swaggerSpec) // initializes the API
+ server := restapi.NewServer(pluginAPI) // creates the server
+
+ server.ConfigureAPI() // configures the API
+
+ return server
+}
+
+func main() {
+ quit := make(chan bool) // creates a channel to receive the interrupt signal
+ intSig := make(chan os.Signal, 1) // notifies the channel when the interrupt signal is received
+ signal.Notify(intSig, syscall.SIGINT, syscall.SIGTERM)
+
+ go killTime(quit) // starts the killTime function in a goroutine
+
+ server := initializeAPI() // initializes the API
+
+ if err := server.Serve(); err != nil {
+ panic(err)
+ }
+
+ <-intSig
+ quit <- true
+}
+```
+
+:::info
+The `killTime` function logs a message every 5 seconds. It is used to show that the plugin is running.
+
+The `initializeAPI` function initializes the API and returns the server.
+:::
+
+Once you have created the `my-plugin.go` file, and copied the code, we are going to install the imported packages. To do so, run the following command in the root directory `my-plugin`:
+```bash
+go mod tidy
+```
+
+### Test the API
+
+Once you are done editing the `my-plugin.go` file, you should be able to test the API by running:
+
+```bash
+go run ./my-plugin.go
+```
+
+After five seconds, you should get a similar output:
+
+```bash
+❯ go run ./my-plugin.go
+Plugin is initializing.
+2023/08/22 15:04:39 Serving my plugin at http://[::]:39725
+Tic!
+```
+
+:::tip
+The last numbers correspond to the port the API is running on. It will change each time you restart the plugin.
+:::
+
+At this stage, we are running the API in standalone mode. In the next section, we will register the API with Massa Station, to make it run through Massa Station.
+
+## Register to Massa Station
+
+### Install the Massa Station Plugin package
+
+To be able to register the plugin with Massa Station, we need to install the Massa Station Plugin package. Indeed, this package contains the `RegisterPlugin` function that allows us to register the plugin to Massa Station.
+
+Install the following package:
+```bash
+go get github.com/massalabs/station-massa-hello-world
+```
+
+This package will be imported to `my-plugin.go` file. So go ahead and add the following line to the imports section of `my-plugin.go`:
+```go
+ "github.com/massalabs/station-massa-hello-world/pkg/plugin"
+```
+The import section of your `my-plugin.go` file should look like this:
+
+```go
+import (
+ "fmt"
+ "net/http"
+ "os"
+ "os/signal"
+ "syscall"
+ "time"
+
+ "my-plugin/api/server/restapi"
+ "my-plugin/api/server/restapi/operations"
+
+ "github.com/go-openapi/loads"
+ "github.com/rs/cors"
+
+ "github.com/massalabs/station-massa-hello-world/pkg/plugin"
+)
+```
+Once this is done, we will add the registration logic to our main function. We want to add the following lines to the main function:
+
+```go
+ listener, err := server.HTTPListener()
+ if err != nil {
+ panic(err)
+ }
+
+ plugin.RegisterPlugin(listener) // registers the plugin
+```
+They should be added right after the `server := initializeAPI()` line. In the end, your main function should look like this:
+
+```go
+func main() {
+ quit := make(chan bool) // creates a channel to receive the interrupt signal
+ intSig := make(chan os.Signal, 1) // notifies the channel when the interrupt signal is received
+ signal.Notify(intSig, syscall.SIGINT, syscall.SIGTERM)
+
+ go killTime(quit) // starts the killTime function in a goroutine
+
+ server := initializeAPI() // initializes the API
+
+ listener, err := server.HTTPListener()
+ if err != nil {
+ panic(err)
+ }
+
+ plugin.RegisterPlugin(listener) // registers the plugin
+
+ if err := server.Serve(); err != nil {
+ panic(err)
+ }
+
+ <-intSig
+ quit <- true
+}
+```
+
+:::info
+`plugin.RegisterPlugin` is a function available in the [hello-world plugin package](https://github.com/massalabs/station-massa-hello-world/blob/main/pkg/plugin/register.go).
+
+It facilitates the registration of a plugin with Massa Station, assigning a unique correlation ID to the plugin for identification purposes within the Massa Station system.
+:::
+
+### Build the plugin binary and move it to the Massa Station plugin folder
+
+Now that we have implemented the logic to register the plugin with Massa Station, we are going to build the plugin binary, and move it to the Massa Station plugin folder. By doing so, we will make the binary available to Massa Station.
+
+So, go ahead and build a binary of the plugin with the following command:
+```bash
+mkdir build && go build -o build/my-plugin
+```
+
+In addition to the binary, Massa Station needs a manifest file to be able to identify the plugin. So go ahead and create a `manifest.json` file in the root directory `my-plugin`. Add the following configuration to the `manifest.json` file:
+
+```json
+{
+ "author": "Your name",
+ "name": "Hello World",
+ "description": "Hello world plugin",
+ "logo": "hello_world.svg",
+ "home": "",
+ "version": "0.0.1"
+}
+```
+Feel free to edit the `manifest.json` file to match your name and the name of the plugin.
+
+As you can see, we referenced a `.svg` file. This file will be the logo of your plugin, that will appear on the Massa Station modules page. So go ahead and create a `web` folder in the root directory `my-plugin`. Then, create a `content` folder in the `my-plugin/web` folder. Finally, add the `hello_world.svg` file that you can download [here](https://github.com/massalabs/station-massa-hello-world/blob/main/web/content/hello_world.svg) to the `my-plugin/web/content` folder.
+
+Finally, move the plugin binary, the manifest, and the `.svg` file to the Massa Station plugin folder. The location of the Massa Station plugin folder depends on your operating system:
+
+On linux or macOS you can use the following command to move the files:
+
+```bash
+mkdir -p /usr/local/share/massastation/plugins/my-plugin
+cp build/my-plugin /usr/local/share/massastation/plugins/my-plugin
+cp web/content/hello_world.svg /usr/local/share/massastation/plugins/my-plugin
+cp manifest.json /usr/local/share/massastation/plugins/my-plugin
+```
+
+On Windows, you can use the following command in the PowerShell:
+
+```powershell
+# Create the directory
+$destinationDir = "C:\Program Files (x86)\MassaStation\plugins\my-plugin"
+New-Item -ItemType Directory -Force -Path $destinationDir
+
+# Copy the files
+$sourceDir = "build\my-plugin"
+Copy-Item $sourceDir\my-plugin $destinationDir -Force
+
+$sourceDir = "web\content"
+Copy-Item $sourceDir\hello_world.svg $destinationDir -Force
+
+Copy-Item manifest.json $destinationDir -Force
+```
+
+### Restart Massa Station and access the module page
+
+Restart Massa Station and access [the module page](https://station.massa/web/store). You should see the plugin in the list of available plugins.
+
+
+
+For now, we cannot access it because we haven't implemented any endpoint. So let's do that in the next section.
+
+## Define your endpoint
+
+We are going to add a new endpoint to our plugin that will display a message when called. To do so, we will add a new endpoint to the swagger file, generate the code, add a handler, and register the handler.
+
+### Add a new endpoint to the swagger file
+
+So go ahead and open the `swagger.yml` file in the `api` folder, and append the following code at the end of the file:
+
+```yaml
+ /api/hello:
+ put:
+ operationId: hello
+ parameters:
+ - in: query
+ name: name
+ type: string
+ description: the name of the person to be greeted.
+ produces:
+ - application/json
+ responses:
+ "200":
+ description: Greeting content.
+ schema:
+ type: object
+ required:
+ - message
+ properties:
+ message:
+ description: Greeting message.
+ type: string
+ x-nullable: false
+ "500":
+ description: Internal Server Error - The server has encountered a situation it does not know how to handle.
+```
+
+### Generate the server stub
+
+Once you are done editing the `swagger.yml` file, we are going to re-generate the server stub based on the new configuration. To do so, run the following command in the root directory `my-plugin`:
+
+```bash
+go generate ./...
+```
+
+### Add a handler
+
+Now we are going to add a handler for our new endpoint. To do so, we will create an `endpoints.go` file that will contain the logic of the handler.
+So go ahead and create the file `endpoints.go` in the `my-plugin/api` folder.
+Add the following code to the `endpoints.go` file:
+
+```go
+package api
+
+import (
+ "fmt"
+
+ "my-plugin/api/server/restapi/operations"
+
+ "github.com/go-openapi/runtime/middleware"
+)
+
+func Hello(params operations.HelloParams) middleware.Responder {
+ target := "World"
+ if params.Name != nil {
+ target = *params.Name
+ }
+
+ return operations.NewHelloOK().WithPayload(
+ &operations.HelloOKBody{Message: fmt.Sprintf("Hello, %s!", target)},
+ )
+}
+```
+
+:::info
+Here, we are simply returning a 200 OK response with a greeting message that takes the name of the person to be greeted from the query parameters.
+:::
+
+### Register the handler
+
+Now we are going to set the handler for our newly created `hello` endpoint. To do so, we will add the following line to the `initializeAPI` function in the `my-plugin.go` file:
+
+```go
+pluginAPI.HelloHandler = operations.HelloHandlerFunc(api.Hello)
+```
+
+So go ahead and in the `my-plugin.go` file, replace the current `initializeAPI` function with the following code snippet:
+
+```go
+func initializeAPI() *restapi.Server {
+ swaggerSpec, err := loads.Analyzed(restapi.SwaggerJSON, "") // loads the swagger file
+ if err != nil {
+ panic(err)
+ }
+
+ pluginAPI := operations.NewMyPluginAPI(swaggerSpec) // initializes the API
+ server := restapi.NewServer(pluginAPI) // creates the server
+ server.ConfigureAPI() // configures the API
+ pluginAPI.HelloHandler = operations.HelloHandlerFunc(api.Hello) // sets the handler for the Hello endpoint
+
+ return server
+}
+```
+
+### Re-build and re-deploy the plugin
+
+Now that we have created our endpoint and the corresponding handler, we need to re-build and re-deploy the plugin. We are going to follow the same steps 2 and 3 of the previous section.
+Start by building the binary with the following command:
+```bash
+go build -o build/my-plugin
+```
+
+Then, move the binary, to the Massa Station plugin folder. The location of the Massa Station plugin folder depends on your operating system.
+
+On linux or macOS:
+
+```bash
+cp build/my-plugin /usr/local/share/massastation/plugins/my-plugin
+```
+
+On Windows, you can use the following commands in the PowerShell:
+
+```powershell
+# Copy the files
+$sourceDir = "build\my-plugin"
+Copy-Item $sourceDir\my-plugin $destinationDir -Force
+```
+
+### Test the endpoint
+
+We are going to test the endpoint by calling it with `curl`. The url of the endpoint will vary depending on the naming you used in the previous steps. So the easiest way will be to go to the Massa Station module page, locate your plugin, launch it and copy the url.
+In my case, it is: `https://station.massa/plugin/your-name/hello-world/`.
+
+Run the following command to test the `hello` endpoint we implemented, and don't forget to replace the url with yours:
+
+```bash
+curl -X PUT "api/hello?name=John" -H "accept: application/json""
+```
+
+You should see the following output:
+
+```bash
+{ "message": "Hello, John!" }
+```
+
+Great! We have successfully added a new endpoint to our plugin.
+
+The next step will be to add a frontend to our plugin.
+
+## Add a frontend to the plugin
+
+We are going to add a frontend to our plugin. The process is quite similar to the one we followed in the previous section.
+We will add a new endpoint to the swagger file, generate the code, add a handler, and register the handler. Then, we will create a basic HTML page and add the handler to the `initializeAPI` function.
+
+### Add a new endpoint to the swagger file
+
+Once again, we will add a new endpoint to the API. This time, we will add an endpoint that will allow us to serve a static website. To do so, we will add a new endpoint to the swagger file. So go ahead and open the `swagger.yml` file in the `api` folder, and append the following code at the end of the file:
+
+```yaml
+ /web/{resource}:
+ get:
+ operationId: web
+ produces:
+ - application/json
+ - text/javascript
+ - text/html
+ - text/css
+ - text/webp
+ - image/png
+ parameters:
+ - in: path
+ name: resource
+ type: string
+ required: true
+ description: Website resource.
+ responses:
+ "200":
+ description: Page found
+ "404":
+ description: Resource not found.
+```
+
+### Generate the server stub
+
+Once you are done editing the `swagger.yml` file, we are going to re-generate the server stub based on the new configuration. To do so, run the following command in the root directory `my-plugin`:
+
+```bash
+go generate ./...
+```
+
+### Create an HTML page
+
+Now we are going to create a basic HTML page that will be served by the plugin. So go ahead and create an `index.html` file in the `my-plugin/web/content` folder.
+Add the following code to the `index.html` file:
+
+
+```html
+
+
+