├── .dockerignore ├── .editorconfig ├── .env ├── .github └── workflows │ └── build-docs.yml ├── .gitignore ├── .vscode └── settings.json ├── Dockerfile ├── README.md ├── nginx.conf ├── package-lock.json ├── package.json ├── packages ├── community │ ├── components │ │ ├── Logo.jsx │ │ └── PageHead.tsx │ ├── global.css │ ├── index.js │ ├── next-env.d.ts │ ├── next.config.js │ ├── package.json │ ├── pages │ │ ├── _app.mdx │ │ ├── _meta.json │ │ ├── cb-rpgf-round-1.mdx │ │ ├── community-builder-handbook.mdx │ │ ├── index.mdx │ │ ├── trusted-setup.mdx │ │ └── validators.mdx │ ├── public │ │ ├── favicon-16x16.png │ │ ├── favicon-32x32.png │ │ ├── favicon.ico │ │ ├── opengraph.png │ │ └── voting-weights.png │ ├── theme.config.tsx │ └── tsconfig.json ├── docs │ ├── components │ │ ├── DocsAscii.tsx │ │ ├── Expandable.tsx │ │ ├── Logo.tsx │ │ ├── PageHead.tsx │ │ └── ZoomImage.tsx │ ├── global.css │ ├── index.js │ ├── next-env.d.ts │ ├── next.config.js │ ├── package.json │ ├── pages │ │ ├── _app.mdx │ │ ├── _meta.json │ │ ├── index.mdx │ │ ├── integrating-with-namada.mdx │ │ ├── integrating-with-namada │ │ │ ├── _meta.json │ │ │ ├── indexer.mdx │ │ │ ├── sdk.mdx │ │ │ └── sdk │ │ │ │ ├── _meta.json │ │ │ │ ├── constructing-transfers.mdx │ │ │ │ ├── generating-accounts.mdx │ │ │ │ ├── interface-integration.mdx │ │ │ │ ├── setting-up-a-client.mdx │ │ │ │ └── setting-up-a-wallet.mdx │ │ ├── introduction.mdx │ │ ├── introduction │ │ │ ├── _meta.json │ │ │ ├── install.mdx │ │ │ ├── install │ │ │ │ ├── _meta.json │ │ │ │ ├── binaries.mdx │ │ │ │ ├── binaries │ │ │ │ │ ├── _meta.json │ │ │ │ │ ├── overview-of-binaries.mdx │ │ │ │ │ └── prerequisites.mdx │ │ │ │ ├── docker.mdx │ │ │ │ ├── source.mdx │ │ │ │ └── source │ │ │ │ │ ├── _meta.json │ │ │ │ │ ├── pre-requisites.mdx │ │ │ │ │ └── troubleshooting.mdx │ │ │ ├── installing-cometbft.mdx │ │ │ ├── privacy.mdx │ │ │ ├── quick-start.mdx │ │ │ └── security.mdx │ │ ├── networks.mdx │ │ ├── networks │ │ │ ├── mainnets.mdx │ │ │ ├── testnets.mdx │ │ │ └── testnets │ │ │ │ ├── _meta.json │ │ │ │ ├── campfire.mdx │ │ │ │ ├── environment-setup.mdx │ │ │ │ ├── faq.mdx │ │ │ │ ├── genesis-validator-apply.mdx │ │ │ │ ├── joining-the-testnet.mdx │ │ │ │ ├── migrating-testnets.mdx │ │ │ │ ├── post-genesis-validator.mdx │ │ │ │ ├── pow.mdx │ │ │ │ ├── pre-genesis.mdx │ │ │ │ └── testnet-history.mdx │ │ ├── operators.mdx │ │ ├── operators │ │ │ ├── _meta.json │ │ │ ├── eth-bridge.mdx │ │ │ ├── eth-bridge │ │ │ │ └── relaying.mdx │ │ │ ├── hardware.mdx │ │ │ ├── ibc.mdx │ │ │ ├── ledger.mdx │ │ │ ├── ledger │ │ │ │ ├── _meta.json │ │ │ │ ├── base-directory.mdx │ │ │ │ ├── env-vars.mdx │ │ │ │ ├── logging-config.mdx │ │ │ │ └── running-a-full-node.mdx │ │ │ ├── networks.mdx │ │ │ ├── networks │ │ │ │ ├── _meta.json │ │ │ │ ├── genesis-flow.mdx │ │ │ │ ├── genesis-flow │ │ │ │ │ ├── _meta.json │ │ │ │ │ ├── coordinator.mdx │ │ │ │ │ └── participants.mdx │ │ │ │ └── local-network.mdx │ │ │ ├── remote-signing.mdx │ │ │ ├── troubleshooting.mdx │ │ │ ├── validators.mdx │ │ │ └── validators │ │ │ │ ├── _meta.json │ │ │ │ ├── jailing.mdx │ │ │ │ ├── proof-of-stake.mdx │ │ │ │ ├── staking.mdx │ │ │ │ └── validator-setup.mdx │ │ ├── users.mdx │ │ └── users │ │ │ ├── _meta.json │ │ │ ├── delegators.mdx │ │ │ ├── fees.mdx │ │ │ ├── governance.mdx │ │ │ ├── governance │ │ │ ├── _meta.json │ │ │ ├── off-chain-governance.mdx │ │ │ └── on-chain-governance.mdx │ │ │ ├── ibc.mdx │ │ │ ├── public-goods-stewards.mdx │ │ │ ├── public-goods-stewards │ │ │ ├── _meta.json │ │ │ ├── electing.mdx │ │ │ ├── proposing.mdx │ │ │ └── voting.mdx │ │ │ ├── shielded-accounts.mdx │ │ │ ├── shielded-accounts │ │ │ ├── shielded-rewards.mdx │ │ │ └── shielded-transfers.mdx │ │ │ ├── transparent-accounts.mdx │ │ │ ├── transparent-accounts │ │ │ ├── multisignature.mdx │ │ │ └── send-and-receive-nam-tokens.mdx │ │ │ ├── wallet.mdx │ │ │ └── wallet │ │ │ ├── _meta.json │ │ │ ├── file-system-wallet.mdx │ │ │ ├── hardware-wallet.mdx │ │ │ └── web-wallet.mdx │ ├── public │ │ ├── favicon-16x16.png │ │ ├── favicon-32x32.png │ │ ├── favicon.ico │ │ ├── images │ │ │ ├── Download_Tendermint_Binaries.png │ │ │ ├── NamadaBannerImage.png │ │ │ ├── Namada_Full_RGB_Yellow.png │ │ │ ├── namada-logo.svg │ │ │ ├── namada_docs_ascii_dark.png │ │ │ ├── namada_docs_ascii_light.png │ │ │ ├── scripts │ │ │ │ ├── testnet_flowchart.dot │ │ │ │ └── testnet_flowchart.sh │ │ │ └── testnet_flowchart.png │ │ └── opengraph.jpg │ ├── theme.config.tsx │ └── tsconfig.json └── specs │ ├── components │ ├── Logo.jsx │ ├── PageHead.tsx │ └── SpecsAscii.jsx │ ├── global.css │ ├── index.js │ ├── next-env.d.ts │ ├── next.config.js │ ├── package.json │ ├── pages │ ├── _app.mdx │ ├── _meta.json │ ├── base-ledger.mdx │ ├── base-ledger │ │ ├── _meta.json │ │ ├── block-space-allocator.mdx │ │ ├── consensus.mdx │ │ ├── execution.mdx │ │ ├── fee-system.mdx │ │ ├── images │ │ │ ├── block-space-allocator-bins.svg │ │ │ └── block-space-allocator-example.svg │ │ ├── replay-protection.mdx │ │ └── replay-protection │ │ │ ├── _meta.json │ │ │ └── optimizations.mdx │ ├── further-reading.mdx │ ├── index.mdx │ ├── modules.mdx │ └── modules │ │ ├── _meta.json │ │ ├── ethereum-bridge.mdx │ │ ├── ethereum-bridge │ │ ├── _meta.json │ │ ├── bootstrapping.mdx │ │ ├── ethereum_events_attestation.mdx │ │ ├── ethereum_smart_contracts.mdx │ │ ├── proofs.mdx │ │ ├── security.mdx │ │ ├── transfers_to_ethereum.mdx │ │ └── transfers_to_namada.mdx │ │ ├── governance.mdx │ │ ├── governance │ │ ├── _meta.json │ │ ├── off-chain.mdx │ │ ├── on-chain.mdx │ │ ├── proposal.mdx │ │ ├── public-goods-funding.mdx │ │ ├── public-goods-funding │ │ │ ├── _meta.json │ │ │ ├── becoming-a-steward.mdx │ │ │ ├── electing.mdx │ │ │ ├── funding.mdx │ │ │ ├── incentives.mdx │ │ │ ├── public-goods-stewards.mdx │ │ │ └── storage.mdx │ │ └── storage.mdx │ │ ├── ibc.mdx │ │ ├── images │ │ ├── cubic_slash.png │ │ ├── inflation.png │ │ ├── inflation.svg │ │ ├── locking.png │ │ └── locking.svg │ │ ├── masp.mdx │ │ ├── masp │ │ ├── _meta.json │ │ ├── asset-type.mdx │ │ ├── burn-and-mint.mdx │ │ ├── convert-circuit.mdx │ │ ├── ledger-integration.mdx │ │ ├── shielded-pool-incentives.mdx │ │ └── trusted-setup.mdx │ │ ├── multisignature.mdx │ │ ├── multitoken.mdx │ │ ├── proof-of-stake.mdx │ │ └── proof-of-stake │ │ ├── _meta.json │ │ ├── cubic-slashing.mdx │ │ ├── inflation-system.mdx │ │ ├── objects-and-txs.mdx │ │ └── reward-distribution.mdx │ ├── public │ ├── favicon-16x16.png │ ├── favicon-32x32.png │ ├── favicon.ico │ ├── images │ │ ├── namada_specs_ascii_dark.png │ │ ├── namada_specs_ascii_light.png │ │ ├── transfer-to-eth-flow.svg │ │ └── trusted-setup-assets │ │ │ ├── contribution-sequence-diagram.png │ │ │ ├── namada-ts-arch.png │ │ │ ├── namda-ts-swimlane.png │ │ │ ├── optimistic-mmorpg-mpc-diagram.png │ │ │ └── trusted-setup-actors.png │ └── opengraph.jpg │ ├── theme.config.tsx │ └── tsconfig.json └── tsconfig.base.json /.dockerignore: -------------------------------------------------------------------------------- 1 | Dockerfile 2 | .dockerignore 3 | node_modules 4 | npm-debug.log 5 | README.md 6 | .next 7 | .git -------------------------------------------------------------------------------- /.editorconfig: -------------------------------------------------------------------------------- 1 | # EditorConfig is awesome: https://EditorConfig.org 2 | # top-most EditorConfig file 3 | root = true 4 | 5 | # Unix-style newlines with a newline ending every file 6 | [*] 7 | end_of_line = lf 8 | insert_final_newline = true 9 | 10 | # Matches multiple files with brace expansion notation 11 | # Set default charset 12 | [*.{js,py,tsx,jsx,ts}] 13 | charset = utf-8 14 | indent_size = 2 15 | indent_style = space -------------------------------------------------------------------------------- /.env: -------------------------------------------------------------------------------- 1 | NEXT_TELEMETRY_DISABLED=1 2 | -------------------------------------------------------------------------------- /.github/workflows/build-docs.yml: -------------------------------------------------------------------------------- 1 | name: Build docker images 2 | 3 | on: 4 | workflow_dispatch: 5 | inputs: 6 | tag: 7 | description: 'The docker image tag' 8 | required: true 9 | push: 10 | branches: 11 | - master 12 | pull_request: 13 | 14 | env: 15 | GIT_LFS_SKIP_SMUDGE: 1 16 | 17 | jobs: 18 | docker: 19 | runs-on: ${{ matrix.os }} 20 | needs: [checks] 21 | strategy: 22 | fail-fast: false 23 | matrix: 24 | os: [ubuntu-20.04] 25 | make: 26 | - name: Build Specs image 27 | image: specs 28 | path: specs 29 | - name: Build Docs image 30 | image: docs 31 | path: docs 32 | - name: Build Docs image 33 | image: community 34 | path: community 35 | 36 | steps: 37 | - name: Checkout repo 38 | uses: actions/checkout@v3 39 | - name: Set up QEMU 40 | uses: docker/setup-qemu-action@v2 41 | - name: Set up Docker Buildx 42 | uses: docker/setup-buildx-action@v2 43 | with: 44 | version: v0.9.1 45 | - name: Login to private registry 46 | uses: docker/login-action@v1 47 | with: 48 | registry: ${{ secrets.REGISTRY_URL }} 49 | username: ${{ secrets.REGISTRY_USERNAME }} 50 | password: ${{ secrets.REGISTRY_PASSWORD }} 51 | - name: Docker meta 52 | id: meta 53 | uses: docker/metadata-action@v4 54 | with: 55 | images: ${{ secrets.REGISTRY_URL }}/namada-${{ matrix.make.image }}-docs 56 | tags: | 57 | type=schedule 58 | type=ref,event=branch 59 | type=ref,event=pr 60 | type=semver,pattern={{version}} 61 | type=semver,pattern={{major}}.{{minor}} 62 | type=semver,pattern={{major}} 63 | type=raw,value=latest 64 | - name: ${{ matrix.make.name }} 65 | uses: docker/build-push-action@v4 66 | with: 67 | context: . 68 | file: Dockerfile 69 | push: ${{ github.ref == 'refs/heads/master' }} 70 | tags: ${{ steps.meta.outputs.tags }} 71 | labels: ${{ steps.meta.outputs.labels }} 72 | build-args: | 73 | "TARGET=${{ matrix.make.path }}" 74 | 75 | checks: 76 | runs-on: ${{ matrix.os }} 77 | strategy: 78 | fail-fast: false 79 | matrix: 80 | os: [ubuntu-20.04] 81 | lychee_version: [lycheeverse/lychee@v0.13.0] 82 | make: 83 | - name: docs 84 | path: docs 85 | # - name: specs 86 | # path: specs 87 | - name: community 88 | path: community 89 | 90 | steps: 91 | - name: Checkout repo 92 | uses: actions/checkout@v3 93 | - name: Install tools 94 | run: | 95 | curl -k https://installer.heliax.click/${{ matrix.lychee_version }}! | bash 96 | - name: Check broken links for ${{ matrix.make.name }} 97 | run: lychee --offline packages/${{ matrix.make.path }}/pages/ -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .next 2 | node_modules 3 | out 4 | .DS_Store -------------------------------------------------------------------------------- /.vscode/settings.json: -------------------------------------------------------------------------------- 1 | { 2 | "[markdown]": { 3 | "editor.wordWrap": "on" 4 | } 5 | } -------------------------------------------------------------------------------- /Dockerfile: -------------------------------------------------------------------------------- 1 | ARG TARGET 2 | 3 | FROM node:18-alpine AS base 4 | 5 | ARG TARGET 6 | 7 | FROM base AS builder 8 | RUN apk add --no-cache libc6-compat 9 | 10 | WORKDIR /app 11 | 12 | COPY packages/${TARGET}/package.json packages/${TARGET}/ 13 | 14 | # Install dependencies 15 | COPY package-lock.json package.json ./ 16 | RUN npm install ci 17 | 18 | COPY . . 19 | 20 | ENV NEXT_TELEMETRY_DISABLED 1 21 | 22 | RUN npm run build:${TARGET} 23 | 24 | # Production image, copy all the files and run next 25 | FROM nginx:alpine 26 | 27 | ARG TARGET 28 | COPY nginx.conf /etc/nginx/conf.d/default.conf 29 | WORKDIR /usr/share/nginx/html 30 | RUN rm -rf ./* 31 | COPY --from=builder /app/packages/${TARGET}/out . 32 | 33 | EXPOSE 3000 34 | 35 | CMD ["nginx", "-g", "daemon off;"] -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Introduction 2 | 3 | This documentation uses [Nextra](https://nextra.site/) and [NextJS](https://nextjs.org/). 4 | 5 | ## Local Development 6 | 7 | 1. You need to install [NodeJS](https://nodejs.org/en) >= 16. 8 | - You may be able to install it using your package manager, e.g. `sudo apt install nodejs` or `brew install node`. 9 | 2. Run `npm i` to install the dependencies. 10 | 3. To run Docs, you can use the command `npm run dev:docs`. To run Specs, you can use the command `npm run dev:specs`. Community docs development will also be available by running `npm run dev:community`. The default development server URL is `http://localhost:3000` but if for some reason it's used by another application, the console will display on which port the server has been started. 11 | -------------------------------------------------------------------------------- /nginx.conf: -------------------------------------------------------------------------------- 1 | server { 2 | listen 3000; 3 | root /usr/share/nginx/html; 4 | location /_next/static { 5 | # Provides caching for static assets, to improve server performance 6 | add_header Cache-Control "max-age=31536000"; 7 | } 8 | location / { 9 | try_files $uri.html $uri $uri/ /index.html; 10 | add_header Cache-Control "no-cache"; 11 | } 12 | } -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "license": "GPL-3.0", 3 | "workspaces": [ 4 | "packages/docs", 5 | "packages/specs", 6 | "packages/community" 7 | ], 8 | "scripts": { 9 | "dev:docs": "npm run dev --workspace=packages/docs", 10 | "dev:specs": "npm run dev --workspace=packages/specs", 11 | "dev:community": "npm run dev --workspace=packages/community", 12 | "build:docs": "npm run build --workspace=packages/docs", 13 | "build:specs": "npm run build --workspace=packages/specs", 14 | "build:community": "npm run build --workspace=packages/community", 15 | "build": "npm run build --workspaces" 16 | }, 17 | "dependencies": { 18 | "ci": "^2.2.0" 19 | } 20 | } 21 | -------------------------------------------------------------------------------- /packages/community/components/Logo.jsx: -------------------------------------------------------------------------------- 1 | import { useEffect, useState } from "react"; 2 | import { useTheme } from "nextra-theme-docs"; 3 | 4 | export const Logo = () => { 5 | const { resolvedTheme } = useTheme(); 6 | const [isDark, setDark] = useState(false); 7 | 8 | useEffect(() => { 9 | setDark(resolvedTheme === "dark"); 10 | }, [resolvedTheme]); 11 | 12 | const fill = isDark ? "#ffff00" : "currentColor"; 13 | 14 | return ( 15 |
16 | 22 | 23 | 31 | 36 | 41 | 42 | 47 | 48 | 57 | 58 | COMMUNITY 59 | 60 | 61 | 62 |
63 | ); 64 | }; 65 | -------------------------------------------------------------------------------- /packages/community/components/PageHead.tsx: -------------------------------------------------------------------------------- 1 | export const PageHead = () => { 2 | return ( 3 | <> 4 | 5 | 9 | 10 | 11 | 12 | 13 | 14 | 20 | 26 | 27 | ); 28 | }; 29 | -------------------------------------------------------------------------------- /packages/community/global.css: -------------------------------------------------------------------------------- 1 | @import url("https://fonts.googleapis.com/css2?family=Space+Grotesk:wght@500&display=swap"); 2 | -------------------------------------------------------------------------------- /packages/community/index.js: -------------------------------------------------------------------------------- 1 | module.exports = "community"; 2 | -------------------------------------------------------------------------------- /packages/community/next-env.d.ts: -------------------------------------------------------------------------------- 1 | /// 2 | /// 3 | 4 | // NOTE: This file should not be edited 5 | // see https://nextjs.org/docs/basic-features/typescript for more information. 6 | -------------------------------------------------------------------------------- /packages/community/next.config.js: -------------------------------------------------------------------------------- 1 | const withNextra = require("nextra")({ 2 | theme: "nextra-theme-docs", 3 | themeConfig: "./theme.config.tsx", 4 | latex: true, 5 | defaultShowCopyCode: true, 6 | }); 7 | 8 | module.exports = { 9 | ...withNextra(), 10 | basePath: "/community/docs", 11 | images: { 12 | unoptimized: true, 13 | }, 14 | }; 15 | -------------------------------------------------------------------------------- /packages/community/package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "namada-community", 3 | "version": "0.0.1", 4 | "description": "Namada Community Docs", 5 | "license": "GPL-3.0", 6 | "scripts": { 7 | "dev": "next dev", 8 | "build": "next build && next export", 9 | "start": "next start" 10 | }, 11 | "dependencies": { 12 | "next": "^13.4.8", 13 | "nextra": "latest", 14 | "nextra-theme-docs": "latest", 15 | "react": "^18.2.0", 16 | "react-dom": "^18.2.0" 17 | }, 18 | "devDependencies": { 19 | "@types/node": "18.11.10", 20 | "typescript": "^4.9.3" 21 | } 22 | } 23 | -------------------------------------------------------------------------------- /packages/community/pages/_app.mdx: -------------------------------------------------------------------------------- 1 | import "../global.css"; 2 | 3 | export default function Specs({ Component, pageProps }) { 4 | return ; 5 | } 6 | -------------------------------------------------------------------------------- /packages/community/pages/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "index": "Introduction", 3 | "trusted-setup": "Trusted Setup", 4 | "validators": "Validators", 5 | "community-builder-handbook": "Community Builder Handbook", 6 | "cb-rpgf-round-1": "CB RPGF Round #1" 7 | } 8 | -------------------------------------------------------------------------------- /packages/community/pages/index.mdx: -------------------------------------------------------------------------------- 1 | # Namada Community DOCS 2 | 3 | ## What is the Namada Community? 4 | 5 | The Namada community is composed of ecosystems, communities, researchers, builders, creators, advocates, users of privacy, and just people – who want to see a future in which decentralized systems can serve as real alternatives to existing financial systems. To achieve this, privacy is paramount. 6 | 7 | We are brought together by the [Namada Vision](https://forum.namada.net/t/the-namada-mission/275). Together we make privacy as a public good a reality by building open-source tools, operating protocols, teaching people about privacy, using privacy, and funding privacy. 8 | 9 | Do you want to join us? 10 | -------------------------------------------------------------------------------- /packages/community/pages/trusted-setup.mdx: -------------------------------------------------------------------------------- 1 | # Trusted setup 2 | 3 | A key component of the Namada protocol is the MASP circuit, which enables the features of asset-agnostic shielded transfers and shielded set rewards. For the MASP to work, it needs two sets of parameters: the first set is phase I from Zcash’s Powers of Tau ceremony, conducted in 2018, and the second ones are the ones generated in Namada’s Trusted Setup ceremony, which was announced in November 2022 and coordinated by the Anoma Foundation with the help of devs at Heliax. 4 | 5 | The ceremony encouraged everyone to participate, but specifically the ones who wanted to use privacy on Namada – because participants in the ceremony only need to trust themselves to have effectively destroyed the toxic waste. The ceremony started on the 19th of November 2022 and concluded on the 21st of December 2022 with no less than 2,510 participants – making it the largest trusted setup at the time (more details in the recap). 6 | 7 | The Namada Community grew in size and diversity, everyone who participated contributed to the security of the privacy features on Namada. Participants in the Trusted Setup were requested to generate a seed phrase – and the next step will be the instructions for claiming the rewards for participating in the ceremony. 8 | 9 | **Resources:** 10 | 11 | - [Announcing the Namada Trusted Setup](https://namada.net/blog/announcing-the-namada-trusted-setup-ceremony) 12 | - Trusted Setup coordinator [code](https://github.com/anoma/namada-trusted-setup) 13 | - [Completion of the Namada Trusted Setup](https://namada.net/blog/completion-of-the-namada-trusted-setup) 14 | - Dashboard with [all contributions](https://namada.net/trusted-setup) and tool to verify contributions 15 | - [Zcash’s Powers of Tau](https://github.com/ZcashFoundation/powersoftau-attestations/) 16 | - [MASP parameters](https://github.com/anoma/namada-masp-params) as a Rust crate 17 | 18 | **Engage:** 19 | 20 | - Join the community on Discord 21 | - Join the weekly Private Library on [Discord](https://discord.gg/namada) 22 | - Join the monthly community calls 23 | -------------------------------------------------------------------------------- /packages/community/pages/validators.mdx: -------------------------------------------------------------------------------- 1 | # Validators 2 | 3 | The development of Namada started in 2022, back then it went by the codename of “M1”. After months of development, throughout summer and fall we launched a series of [private testnets](https://github.com/anoma/namada-testnets/tree/main/namada-close-quarters-testnet-1) with the help of a handful of early validators who believed in the vision of bringing asset agnostic privacy. The community at this stage was composed by the core developers at Heliax and [the few validators](https://namada.net/blog/announcing-namada-public-testnets) (7 team members from Heliax and [11 validators](https://github.com/anoma/namada-testnets/tree/main/namada-close-quarters-testnet-5)) who joined and coordinated through the Validator Hangout on Element. The last private testnets ran until December 2022, the protocol version was `v0.11`. 4 | 5 | In December 2022, the first [public testnet](https://namada.net/blog/announcing-namada-public-testnets) was launched with a few more validators joining forces ([29 in total](https://github.com/anoma/namada-testnets/tree/main/namada-public-testnet-1), with a few team-run nodes). Ever since, the core developers have published numerous protocol releases from `v0.12.0`, until the latest `v0.23.1` and more than 13 testnets launches/upgrades. The number of validators grew a lot, a total of [253 validators](https://github.com/anoma/namada-testnets/tree/main/namada-public-testnet-13) submitted their genesis keys for testnet 13. 6 | 7 | Every testnet followed the same decentralized launch process as practice for mainnet, where a protocol version and a genesis proposal is published, and it is entirely up to the validators whether the network goes live or not. 8 | 9 | **Resources:** 10 | 11 | - [Announcing Namada Public Testnets](https://namada.net/blog/announcing-namada-public-testnets) 12 | - The [Namada protocol](https://github.com/anoma/namada) and releases 13 | - Namada testnet history and validator .toml [files](https://github.com/anoma/namada-testnets/tree/main) 14 | - Validator [documentation](https://docs.namada.net/) 15 | 16 | **Want to become a validator?** 17 | 18 | - Become a validator in the public testnets 19 | - Join the validator community on [Discord](https://discord.gg/namada) 20 | - Join the biweekly validator calls 21 | -------------------------------------------------------------------------------- /packages/community/public/favicon-16x16.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/community/public/favicon-16x16.png -------------------------------------------------------------------------------- /packages/community/public/favicon-32x32.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/community/public/favicon-32x32.png -------------------------------------------------------------------------------- /packages/community/public/favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/community/public/favicon.ico -------------------------------------------------------------------------------- /packages/community/public/opengraph.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/community/public/opengraph.png -------------------------------------------------------------------------------- /packages/community/public/voting-weights.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/community/public/voting-weights.png -------------------------------------------------------------------------------- /packages/community/theme.config.tsx: -------------------------------------------------------------------------------- 1 | import React from "react"; 2 | import { Logo } from "./components/Logo"; 3 | import { DocsThemeConfig } from "nextra-theme-docs"; 4 | import { PageHead } from "./components/PageHead"; 5 | 6 | const description = `"Docs for Namada Community, a Proof-of-Stake L1 for interchain asset-agnostic privacy.`; 7 | 8 | const config: DocsThemeConfig = { 9 | primaryHue: 180, 10 | useNextSeoProps() { 11 | return { 12 | titleTemplate: "%s | Community | Namada", 13 | defaultDescription: description, 14 | canonical: "https://community.namada.net", 15 | description, 16 | }; 17 | }, 18 | head: , 19 | logo: , 20 | project: { 21 | link: "https://github.com/anoma/namada", 22 | }, 23 | chat: { 24 | link: "https://discord.gg/namada", 25 | }, 26 | sidebar: { 27 | defaultMenuCollapseLevel: 1, 28 | }, 29 | docsRepositoryBase: 30 | "https://github.com/anoma/namada-docs/blob/master/packages/specs", 31 | footer: { 32 | text: "Namada", 33 | }, 34 | }; 35 | 36 | export default config; 37 | -------------------------------------------------------------------------------- /packages/community/tsconfig.json: -------------------------------------------------------------------------------- 1 | { 2 | "extends": "../../tsconfig.base.json" 3 | } 4 | -------------------------------------------------------------------------------- /packages/docs/components/DocsAscii.tsx: -------------------------------------------------------------------------------- 1 | import { useState, useEffect } from 'react'; 2 | import { useTheme } from 'nextra-theme-docs'; 3 | 4 | export const DocsAscii = () => { 5 | const { resolvedTheme } = useTheme(); 6 | const [isDarkMode, setDark] = useState(false); 7 | 8 | useEffect(() => { 9 | setDark(resolvedTheme === "dark"); 10 | }, [resolvedTheme]); 11 | 12 | // Construct the image source paths based on theme mode 13 | const imageSrc = isDarkMode 14 | ? '/images/namada_docs_ascii_dark.png' 15 | : '/images/namada_docs_ascii_light.png'; 16 | 17 | return ( 18 |
19 | {/* Conditional rendering based on theme mode */} 20 | {isDarkMode 21 |
22 | ); 23 | }; 24 | -------------------------------------------------------------------------------- /packages/docs/components/Expandable.tsx: -------------------------------------------------------------------------------- 1 | import clsx from "clsx"; 2 | import { useRef, useState } from "react"; 3 | 4 | const Expandable = ({ children }) => { 5 | const containerRef = useRef(null); 6 | const [expanded, setExpanded] = useState(false); 7 | 8 | const scrollToElement = () => { 9 | const rect = containerRef.current.getBoundingClientRect(); 10 | const scrollTop = window.scrollY || document.documentElement.scrollTop; 11 | const elementTop = rect.top + scrollTop; 12 | const paddingTop = 100; 13 | 14 | window.scrollTo({ 15 | top: elementTop - paddingTop, 16 | behavior: "smooth", 17 | }); 18 | }; 19 | 20 | const toggleExpand = () => { 21 | if (expanded) scrollToElement(); 22 | setExpanded(!expanded); 23 | }; 24 | 25 | const styles = { 26 | collapsed: { 27 | height: "200px", 28 | WebkitMaskImage: `linear-gradient(rgba(0, 0, 0, 1) 65%, transparent 100%)`, 29 | maskImage: `linear-gradient(rgba(0, 0, 0, 1) 65%, transparent 100%)`, 30 | }, 31 | expanded: { 32 | height: "auto", 33 | }, 34 | }; 35 | 36 | return ( 37 |
38 |
42 | {children} 43 |
44 | 45 | 63 |
64 | ); 65 | }; 66 | 67 | export default Expandable; 68 | -------------------------------------------------------------------------------- /packages/docs/components/Logo.tsx: -------------------------------------------------------------------------------- 1 | import { useEffect, useState } from "react"; 2 | import { useTheme } from "nextra-theme-docs"; 3 | 4 | export const Logo = () => { 5 | const { resolvedTheme } = useTheme(); 6 | const [isDark, setDark] = useState(false); 7 | 8 | useEffect(() => { 9 | setDark(resolvedTheme === "dark"); 10 | }, [resolvedTheme]); 11 | 12 | const fill = isDark ? "#ffff00" : "currentColor"; 13 | return ( 14 |
15 | 22 | 23 | 24 | 32 | 37 | 42 | 43 | 44 | 49 | 50 | 59 | 60 | DOCS 61 | 62 | 63 | 64 |
65 | ); 66 | }; 67 | -------------------------------------------------------------------------------- /packages/docs/components/PageHead.tsx: -------------------------------------------------------------------------------- 1 | export const PageHead = () => { 2 | return ( 3 | <> 4 | 5 | 9 | 10 | 11 | 12 | 13 | 14 | 20 | 26 | 27 | ); 28 | }; 29 | -------------------------------------------------------------------------------- /packages/docs/components/ZoomImage.tsx: -------------------------------------------------------------------------------- 1 | type ZoomImageProps = { 2 | src: string; 3 | }; 4 | 5 | export const ZoomImage = ({ src }: ZoomImageProps) => { 6 | return null; 7 | }; 8 | -------------------------------------------------------------------------------- /packages/docs/global.css: -------------------------------------------------------------------------------- 1 | @import url("https://fonts.googleapis.com/css2?family=Space+Grotesk:wght@500&display=swap"); 2 | -------------------------------------------------------------------------------- /packages/docs/index.js: -------------------------------------------------------------------------------- 1 | module.exports = "docs"; 2 | -------------------------------------------------------------------------------- /packages/docs/next-env.d.ts: -------------------------------------------------------------------------------- 1 | /// 2 | /// 3 | 4 | // NOTE: This file should not be edited 5 | // see https://nextjs.org/docs/basic-features/typescript for more information. 6 | -------------------------------------------------------------------------------- /packages/docs/next.config.js: -------------------------------------------------------------------------------- 1 | const withNextra = require("nextra")({ 2 | theme: "nextra-theme-docs", 3 | themeConfig: "./theme.config.tsx", 4 | latex: true, 5 | markdown: { 6 | // options for markdown-it-anchor 7 | anchor: { permalink: false }, 8 | // options for markdown-it-toc 9 | toc: { includeLevel: [1, 2] }, 10 | extendMarkdown: (md) => { 11 | // use more markdown-it plugins! 12 | md.use(require("markdown-it-xxx")); 13 | }, 14 | }, 15 | }); 16 | 17 | module.exports = { 18 | ...withNextra(), 19 | images: { 20 | unoptimized: true, 21 | }, 22 | }; 23 | -------------------------------------------------------------------------------- /packages/docs/package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "namada-docs", 3 | "version": "0.0.1", 4 | "description": "Namada Specs", 5 | "license": "GPL-3.0", 6 | "scripts": { 7 | "dev": "next dev", 8 | "build": "next build && next export", 9 | "start": "next start" 10 | }, 11 | "dependencies": { 12 | "next": "^13.4.8", 13 | "nextra": "latest", 14 | "nextra-theme-docs": "latest", 15 | "react": "^18.2.0", 16 | "react-dom": "^18.2.0" 17 | }, 18 | "devDependencies": { 19 | "@types/node": "18.11.10", 20 | "typescript": "^4.9.3" 21 | } 22 | } 23 | -------------------------------------------------------------------------------- /packages/docs/pages/_app.mdx: -------------------------------------------------------------------------------- 1 | import "../global.css"; 2 | 3 | export default function Docs({ Component, pageProps }) { 4 | return ; 5 | } 6 | -------------------------------------------------------------------------------- /packages/docs/pages/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "index": "Namada", 3 | "introduction": "Getting Started", 4 | "users": "User Guide", 5 | "operators": "Operator Guide", 6 | "integrating-with-namada" : "Integration Guide", 7 | "networks": "Networks" 8 | } 9 | -------------------------------------------------------------------------------- /packages/docs/pages/index.mdx: -------------------------------------------------------------------------------- 1 | import { DocsAscii } from '../components/DocsAscii' 2 | 3 | 4 | 5 | ## About Namada 6 | 7 | [Namada](https://namada.net/) is a privacy-for-assets centric blockchain using zero-knowledge proof technology. 8 | Namada's cryptographical features give users asset-agnostic, interchain privacy, and is being built by the Anoma foundation. 9 | 10 | ### Key innovations: 11 | 12 | - Zcash-like transfers for any assets (fungible and non-fungible) 13 | - Rewarded usage of privacy as a public good 14 | - Interoperability with Ethereum via a custom bridge with trust-minimization 15 | 16 | ## Overview of features 17 | 18 | - [Proof-of-Stake](./operators/validators/proof-of-stake.mdx) with [governance](./users/governance.mdx) to secure and evolve Namada 19 | - Fast-finality BFT with 4-second blocks 20 | - Trust-minimized 2-way Ethereum bridge 21 | - IBC connections to chains that already speak IBC (all Cosmos chains) 22 | - [Multi-Asset Shielded Pool](./users/shielded-accounts/shielded-transfers.mdx) (MASP) 23 | - Convert Circuit ([shielded set rewards](./users/shielded-accounts/shielded-rewards.mdx)) 24 | - [Ledger](./users/wallet/hardware-wallet.mdx) application 25 | 26 | For high-level introductions, we recommend: 27 | 28 | - Article: [Introducing Namada: Interchain Asset-agnostic Privacy](https://blog.namada.net/introducing-namada-interchain-asset-agnostic-privacy/) 29 | - Article: [What is Namada?](https://blog.namada.net/what-is-namada/) 30 | - [Talks & Podcasts](https://namada.net/talks) 31 | 32 | To learn more about the protocol, we recommend the following in-depth resources: 33 | 34 | - Talk at ZK8 [Namada: asset-agnostic interchain privacy](https://youtu.be/5K6YxmZPFkE) 35 | - [Namada's specifications](https://specs.namada.net) 36 | - [Codebase](https://github.com/anoma/namada) 37 | -------------------------------------------------------------------------------- /packages/docs/pages/integrating-with-namada.mdx: -------------------------------------------------------------------------------- 1 | # Integrations 2 | 3 | This guide is for integrating with Namada. It is intended for developers who want to integrate with Namada in their own applications, and for engineers who want to extend Namada. 4 | 5 | ## License 6 | Namada operates under the [GPLv3 license](https://www.gnu.org/licenses/gpl-3.0.html) and is free to use and modify. Please see the [LICENSE](https://github.com/anoma/namada/blob/main/LICENSE) for more information. 7 | 8 | ## Table of Contents 9 | - [SDK](./integrating-with-namada/sdk.mdx) 10 | - [Indexer](./integrating-with-namada/indexer.mdx) -------------------------------------------------------------------------------- /packages/docs/pages/integrating-with-namada/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "sdk" : "Using the SDK" 3 | } 4 | -------------------------------------------------------------------------------- /packages/docs/pages/integrating-with-namada/indexer.mdx: -------------------------------------------------------------------------------- 1 | import Expandable from '../../components/Expandable'; 2 | import { Callout } from 'nextra-theme-docs' 3 | 4 | # Namada Indexer 5 | 6 | In collaboration with [Zondax](https://zondax.ch/), an indexer for the Namada blockchain has been born. 7 | 8 | The Namada indexer (a.k.a `namadexer`) constantly queries the Namada blockchain, and together with the [SDK](./sdk.mdx), is able to map blocks, transactions, along with other valuable information into a relational database (postgres). 9 | 10 | This is especially useful for performing analytics over the blockchain, including storing historical data in a way that could be easily queried. 11 | 12 | ## Setting up 13 | 14 | The namada indexer's source code can be found [here](https://github.com/zondax/namadexer) and is simple to set up. 15 | 16 | The `namadexer` works best together with [Docker](https://www.docker.com/products/docker-desktop) 17 | 18 | ```bash 19 | git clone https://github.com/Zondax/namadexer.git 20 | cd namadexer 21 | make compose 22 | ``` 23 | 24 | ## Running the server and db 25 | Once the DockerFile has run, it is straightforward to both set up the postgres database as well as the server that will query the database. 26 | 27 | Make sure that `postgres` [is installed](https://www.postgresql.org/download/) on the local machine. 28 | 29 | **Run postgres in docker** 30 | ```bash 31 | make postgres 32 | # or run (and change arguments, e.g port): 33 | # docker run --name postgres -e POSTGRES_PASSWORD=wow -e POSTGRES_DB=blockchain -p 5432:5432 -d postgres 34 | ``` 35 | Once the postgres server is up and running, it is time to set up the server that will query the postgres db. 36 | 37 | Execute the following command in order to set up the server 38 | ``` 39 | make run_server 40 | ``` 41 | 42 | If successful, the server should be running as a daemon on the localhost at port `30303`. 43 | 44 | ## Run the indexer 45 | 46 | First, ensure that the `Settings.toml` within `config/Settings.toml` is configured correctly. 47 | 48 | 49 | ```toml 50 | log_level = "info" 51 | network = "public-testnet-14" 52 | 53 | [database] 54 | host = "0.0.0.0:5435" 55 | user = "postgres" 56 | password = "wow" 57 | dbname = "blockchain" 58 | # Optional field to configure a timeout if database connection 59 | # fails. 60 | connection_timeout = 20 61 | 62 | 63 | [server] 64 | serve_at = "0.0.0.0" 65 | port = 30303 66 | 67 | [indexer] 68 | tendermint_addr = "0.0.0.0" 69 | port = 26657 70 | 71 | [jaeger] 72 | enable = false 73 | host = "localhost" 74 | port = 6831 75 | 76 | [prometheus] 77 | host = "0.0.0.0" 78 | port = 9000 79 | ``` 80 | 81 | 82 | 83 | 84 | **Interpreting the toml** 85 | 86 | It is important to change the following parameters: 87 | 88 | 1. `indexer.tendermint_addr` - This should be the address and corresponding port of a synced Namada full node 89 | 90 | 2. `database.host` - This should be the tcp address (with port) where the postgres database is running. 91 | 92 | 93 | Once the setup is complete, it is possible to start the indexer 94 | 95 | ```bash 96 | make run_indexer 97 | ``` 98 | 99 | ## Querying the database 100 | 101 | The pre-defined endpoints to query the database are described in the documentation [here](https://github.com/Zondax/namadexer/blob/main/docs/04-server.md). 102 | 103 | 104 | -------------------------------------------------------------------------------- /packages/docs/pages/integrating-with-namada/sdk.mdx: -------------------------------------------------------------------------------- 1 | import Expandable from '../../components/Expandable'; 2 | 3 | # The Namada SDK 4 | 5 | The Namada software development kit (SDK) can be found in the `namada` repo under the path [`namada/shared`](https://github.com/anoma/namada/tree/main/shared). The SDK is written in Rust and can be used to interact with the Namada blockchain, by constructing transactions, signing them, and submitting them to the network. 6 | 7 | ## Quick Start 8 | 9 | A good starting point to see the SDK in use is to check-out the [namada interface](https://github.com/anoma/namada-interface/tree/main/packages/shared/lib/src/sdk) repo. This repo contains a simple web application that uses the SDK to interact with the Namada blockchain. However, it is important to note the added complexity arising from the application integrating javascript using [wasm-bindgen](https://rustwasm.github.io/docs/wasm-bindgen/), which is not necessary. 10 | 11 | ## Installation 12 | 13 | The Namada SDK can be installed by creating a new Rust project and adding the following to the `Cargo.toml` file: 14 | 15 | 16 | 17 | 18 | ```toml 19 | [package] 20 | name = "namada-sdk-starter" 21 | version = "0.1.0" 22 | edition = "2021" 23 | 24 | # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html 25 | 26 | [dependencies] 27 | async-std = "1.11.0" 28 | async-trait = "0.1.51" 29 | borsh = "0.9.0" 30 | file-lock = "2.0.2" 31 | futures = "0.3.28" 32 | getrandom = { version = "0.2" } 33 | masp_primitives = { git = "https://github.com/anoma/masp.git", rev = "50acc5028fbcd52a05970fe7991c7850ab04358e" } 34 | masp_proofs = { git = "https://github.com/anoma/masp.git", rev = "50acc5028fbcd52a05970fe7991c7850ab04358e", features = ["download-params"]} 35 | # Make sure the rev is to the latest version of namada in the below repo 36 | namada_sdk = { git = "https://github.com/anoma/namada.git", rev = "v0.24.0", default-features = false, features = ["abciplus", "namada-sdk", "std"] } 37 | rand = {version = "0.8", default-features = false} 38 | rand_core = {version = "0.6", default-features = false} 39 | tendermint-config = {git="https://github.com/heliaxdev/tendermint-rs.git", rev="b7d1e5afc6f2ccb3fd1545c2174bab1cc48d7fa7"} 40 | tendermint-rpc = {git="https://github.com/heliaxdev/tendermint-rs.git", rev="b7d1e5afc6f2ccb3fd1545c2174bab1cc48d7fa7", features = ["http-client"]} 41 | thiserror = "1.0.38" 42 | tokio = {version = "1.8.2", default-features = false} 43 | toml = "0.5.8" 44 | zeroize = "1.5.5" 45 | 46 | [patch.crates-io] 47 | borsh = {git = "https://github.com/heliaxdev/borsh-rs.git", rev = "cd5223e5103c4f139e0c54cf8259b7ec5ec4073a"} 48 | borsh-derive = {git = "https://github.com/heliaxdev/borsh-rs.git", rev = "cd5223e5103c4f139e0c54cf8259b7ec5ec4073a"} 49 | borsh-derive-internal = {git = "https://github.com/heliaxdev/borsh-rs.git", rev = "cd5223e5103c4f139e0c54cf8259b7ec5ec4073a"} 50 | borsh-schema-derive-internal = {git = "https://github.com/heliaxdev/borsh-rs.git", rev = "cd5223e5103c4f139e0c54cf8259b7ec5ec4073a"} 51 | 52 | ``` 53 | 54 | 55 | 56 | 57 | Once the sdk is installed, you can use it to interact with the Namada blockchain. 58 | 59 | ## Table of contents 60 | 61 | - [Setting up a client](./sdk/setting-up-a-client.mdx) 62 | - [Setting up a wallet](./sdk/setting-up-a-wallet.mdx) 63 | - [Constructing transfers](./sdk/constructing-transfers.mdx) 64 | -------------------------------------------------------------------------------- /packages/docs/pages/integrating-with-namada/sdk/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "setting-up-a-client" : "Setting up a client", 3 | "setting-up-a-wallet" : "Setting up a wallet", 4 | "generating-accounts": "Generating accounts", 5 | "constructing-transfers" : "Constructing transfers", 6 | "interface-integration" : "Integrating with the interface" 7 | } -------------------------------------------------------------------------------- /packages/docs/pages/integrating-with-namada/sdk/constructing-transfers.mdx: -------------------------------------------------------------------------------- 1 | # Constructing transfers 2 | 3 | Now that we have the wallet and client set up, we can create the environment necessary for constructing transfers. 4 | This can be a bit tricky, but the below boilerplate code should do the trick: 5 | The following imports will be needed in order to generate transfers: 6 | 7 | ```rust 8 | use namada_sdk::args::InputAmount; 9 | ``` 10 | 11 | After the user has [generated an account](./generating-accounts.mdx) and created the appropriate struct, it is not too difficult to construct and submit transfer transactions. 12 | 13 | ```rust 14 | let mut namada = NamadaImpl::new(&http_client, &mut wallet, &mut shielded_ctx, &NullIo) 15 | .await 16 | .expect("unable to construct Namada object") 17 | .chain_id(ChainId::from_str("public-testnet-14.5d79b6958580").unwrap()); 18 | // Transfer the given amount of native tokens from the source account to the 19 | // destination account. 20 | async fn gen_transfer<'a>( 21 | namada: &impl Namada<'a>, 22 | source: &Account, 23 | destination: &Account, 24 | amount: InputAmount, 25 | ) -> std::result::Result { 26 | let mut transfer_tx_builder = namada 27 | .new_transfer( 28 | TransferSource::Address(Address::from(&source.public_key)), 29 | TransferTarget::Address(Address::from(&destination.public_key)), 30 | namada.native_token(), 31 | amount, 32 | ) 33 | .signing_keys(vec![source.private_key.clone()]); 34 | let (mut transfer_tx, signing_data, _epoch) = transfer_tx_builder 35 | .build(namada) 36 | .await 37 | .expect("unable to build transfer"); 38 | namada 39 | .sign(&mut transfer_tx, &transfer_tx_builder.tx, signing_data) 40 | .await 41 | .expect("unable to sign reveal pk tx"); 42 | namada.submit(transfer_tx, &transfer_tx_builder.tx).await 43 | } 44 | ``` 45 | 46 | Other transactions can be constructed in a similar fashion. 47 | 48 | ## Shielded transfers 49 | 50 | In order to make the transfer shielded, we need to the only difference is to use shielded addresses and keys instead of transparent ones. 51 | 52 | It is important to use the shielded extended `SpendingKey` as the source. 53 | 54 | ```rust 55 | 56 | use namada::types::masp::{ExtendedSpendingKey, PaymentAddress, TransferSource, TransferTarget}; 57 | 58 | // Make sure to replace 'secret-ex' with an actual Namada extended spending key 59 | let source = ExtendedSpendingKey::from_str("secret-ex").unwrap(); 60 | // Make sure to replace "payment-addr-ex" with an actual Namada payment address 61 | let destination = PaymentAddress::from_str("payment-addr-ex").unwrap(); 62 | let fee_payer = 63 | let mut transfer_tx_builder = namada 64 | .new_transfer( 65 | TransferSource::ExtendedSpendingKey(source), 66 | TransferTarget::Address(Address::from(&destination.public_key)), 67 | namada.native_token(), 68 | amount, 69 | ) 70 | // Make sure to replace "transparent-address-ex" with an actual Namada transparent address 71 | .signing_keys(vec![Address::from_str("transparent-address-ex").ok()]); 72 | ``` -------------------------------------------------------------------------------- /packages/docs/pages/integrating-with-namada/sdk/generating-accounts.mdx: -------------------------------------------------------------------------------- 1 | # Generating accounts 2 | 3 | ## Representing accounts 4 | Representing accounts using the Namada SDK is straightforward. An account on Namada is defined by its public key(s) and private key(s) (plural for multisignatures). The public key(s) is/are used to identify the account and the private key is used to sign transactions. In the below snippet, we represent the account using the public key and private key. 5 | 6 | ```rust 7 | use namada_sdk::core::types::key::common::{PublicKey, SecretKey}; 8 | struct SimpleAccount { 9 | public_key: PublicKey, 10 | private_key: SecretKey 11 | } 12 | ``` 13 | 14 | For a multisignature account, we can represent this through a vector of keys. 15 | 16 | ```rust 17 | use namada_sdk::core::types::key::common::{PublicKey, SecretKey}; 18 | struct MultisigAccount { 19 | public_keys: Vec, 20 | private_keys: Vec 21 | } 22 | ``` 23 | 24 | Multisignature accounts, because they are initialized by an on-chain transaction, will always have their public key revealed to the ledger. However, when keypairs are generated in an offline fashion, the user must submit a transaction in order to reveal their public key. Because of this, it is helpful to add the field `revealed` to the account struct. 25 | 26 | ```rust 27 | use namada_sdk::core::types::key::common::{PublicKey, SecretKey}; 28 | struct Account { 29 | public_key: PublicKey, 30 | private_key: SecretKey, 31 | revealed: bool 32 | } 33 | ``` 34 | 35 | ## Revealing the public key of an implicit account 36 | 37 | In order to reveal the public key of an implicit account, the user must submit a transaction to the ledger. 38 | 39 | ```rust 40 | use namada_sdk::io::NullIo; 41 | use namada_sdk::NamadaImpl; 42 | use namada_sdk::core::types::chain::ChainId; 43 | 44 | 45 | // Define the namada implementation (assuming we have a wallet, http_client, and shielded_ctx) 46 | let mut namada = NamadaImpl::new(&http_client, &mut wallet, &mut shielded_ctx, &NullIo) 47 | .await 48 | .expect("unable to construct Namada object") 49 | .chain_id(ChainId::from_str("public-testnet-14.5d79b6958580").unwrap()); 50 | 51 | // Generate an account (assuming sk is a SecretKey) 52 | let account = Account { 53 | public_key: sk.to_public(), 54 | private_key: sk, 55 | revealed: false, 56 | }; 57 | 58 | // Build the reveal pk transaction using the NamadaImpl object 59 | let reveal_tx_builder = namada 60 | .new_reveal_pk(account.public_key.clone()) 61 | .signing_keys(vec![account.private_key.clone()]); 62 | let (mut reveal_tx, signing_data, _) = reveal_tx_builder 63 | .build(namada) 64 | .await 65 | .expect("unable to build reveal pk tx"); 66 | // Sign the transaction 67 | namada 68 | .sign(&mut reveal_tx, &reveal_tx_builder.tx, signing_data) 69 | .await 70 | .expect("unable to sign reveal pk tx"); 71 | // Submit the signed tx to the ledger for execution 72 | namada.submit(reveal_tx.clone(), reveal_tx_builder) 73 | ``` 74 | 75 | Once the public key is revealed, the account can be used to sign transactions. 76 | -------------------------------------------------------------------------------- /packages/docs/pages/integrating-with-namada/sdk/interface-integration.mdx: -------------------------------------------------------------------------------- 1 | # Using the SDK with the Namada interface 2 | 3 | The [Namada interface](https://github.com/anoma/namada-interface) is a web interface developed by the Anoma Foundation. 4 | 5 | It allows you to easily create and manage your own decentralized identity, including integrating with the ledger application. 6 | 7 | The interface implementation uses a combination of TypeScript and Rust in order to interact with the SDK. 8 | 9 | ## Example 10 | 11 | ```typescript 12 | // Import Sdk & Query 13 | import { Query, Sdk } from "@namada/shared"; 14 | // Import wasm initialization function 15 | import { init as initShared } from "@namada/shared/src/init"; 16 | 17 | async function init() { 18 | await initShared(); 19 | 20 | const sdk = new Sdk(RPC_URL_OF_NAM_NODE); 21 | const query = new Query(RPC_URL_OF_NAM_NODE); 22 | 23 | // ... 24 | } 25 | 26 | init(); 27 | ``` 28 | 29 | ## Documentation 30 | 31 | {/* TODO: Make sure this is updated to the main repo, once ready and merged */} 32 | To learn more, please read the documentation maintained [here](https://github.com/anoma/namada-interface/blob/e9b76f54966ec48befe4a12a47808684e0d40eaf/specs/packages/sdk.md#how-can-you-import-and-use-the-sdk) -------------------------------------------------------------------------------- /packages/docs/pages/integrating-with-namada/sdk/setting-up-a-client.mdx: -------------------------------------------------------------------------------- 1 | # Setting up an SDK client 2 | 3 | Once the sdk has been imported into the project, it can be used to interact with the Namada blockchain. 4 | Let's assume we have a node running on ip and port `127.0.0.1:26657` and we want to send a transaction to the network. 5 | 6 | The SDK may be for various purposes, but in this example we will use it to send a transaction to the network. 7 | 8 | First, we will need to implement the `Client` so that we can communicate with a running node. 9 | 10 | ```rust 11 | use reqwest::{Client, Response as ClientResponse}; 12 | 13 | 14 | pub struct SdkClient { 15 | url: String, 16 | client: Client, 17 | } 18 | 19 | impl SdkClient { 20 | pub fn new(url: String) -> Self { 21 | Self { 22 | client: Client::new(), 23 | url, 24 | } 25 | } 26 | 27 | pub async fn post(&self, body: String) -> Result { 28 | self.client 29 | .post(format!("http://{}", &self.url)) 30 | .body(body) 31 | .send() 32 | .await 33 | } 34 | } 35 | ``` 36 | 37 | This allows us to use `Client` from `reqwest` (an external library) to send a transaction to the network. 38 | 39 | We will need to also define some functions that the client will use to interact with the network. 40 | 41 | ```rust 42 | #[async_trait::async_trait] 43 | impl ClientTrait for SdkClient { 44 | type Error = Error; 45 | 46 | async fn request( 47 | &self, 48 | path: String, 49 | data: Option>, 50 | height: Option, 51 | prove: bool, 52 | ) -> Result { 53 | let data = data.unwrap_or_default(); 54 | let height = height 55 | .map(|height| { 56 | tendermint::block::Height::try_from(height.0) 57 | .map_err(|_err| Error::InvalidHeight(height)) 58 | }) 59 | .transpose()?; 60 | let response = self 61 | .abci_query( 62 | Some(std::str::FromStr::from_str(&path).unwrap()), 63 | data, 64 | height, 65 | prove, 66 | ) 67 | .await?; 68 | 69 | match response.code { 70 | Code::Ok => Ok(EncodedResponseQuery { 71 | data: response.value, 72 | info: response.info, 73 | proof: response.proof, 74 | }), 75 | Code::Err(code) => Err(Error::Query(response.info, code)), 76 | } 77 | } 78 | 79 | async fn perform(&self, request: R) -> Result 80 | where 81 | R: tm_rpc::SimpleRequest, 82 | { 83 | let request_body = request.into_json(); 84 | let response = self.post(request_body).await; 85 | 86 | match response { 87 | Ok(response) => { 88 | let response_json = response.text().await.unwrap(); 89 | R::Response::from_string(response_json) 90 | } 91 | Err(e) => { 92 | let error_msg = e.to_string(); 93 | Err(tm_rpc::Error::server(error_msg)) 94 | } 95 | } 96 | } 97 | } 98 | ``` 99 | 100 | Now, we are ready to use this client to send transactions. -------------------------------------------------------------------------------- /packages/docs/pages/introduction.mdx: -------------------------------------------------------------------------------- 1 | # About this documentation 2 | 3 | Welcome to Namada's docs! This book is intended for any audience looking to: 4 | - [Use Namada](./users.mdx) 5 | - [Operate a full node or validator](./operators.mdx) 6 | - [Develop on Namada](./integrating-with-namada.mdx) 7 | 8 | ## Reporting bugs 9 | If you find any bugs along the journey, please report them in the [Namada repository](https://github.com/anoma/namada/issues). 10 | Feel free to also join the discord and ask questions in the [Namada channel](https://discord.gg/namada). 11 | 12 | ## How to read this book 13 | 14 | Here are some useful tips for reading this book: 15 | 16 | - Comments start with `#`: 17 | 18 | `# this is a comment. Make sure you read them!` 19 | 20 | - Sample outputs start with an arrow: 21 | 22 | `➜ this is an example command line output useful for comparing` 23 | 24 | - User-defined inputs are in angle brackets: 25 | 26 | `this is a command you should run ""` 27 | 28 | ## About this documentation 29 | 30 | This book is written using [Nextra](https://nextra.site/docs), the source can be found in the [Namada documentation repository](https://github.com/anoma/namada-docs). 31 | 32 | [Contributions](https://github.com/anoma/namada/blob/main/CONTRIBUTING.md) to the contents and the structure of this book should be made via pull requests. 33 | 34 | 35 | -------------------------------------------------------------------------------- /packages/docs/pages/introduction/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "quick-start": "Quick start", 3 | "install": "Installing Namada", 4 | "installing-cometbft": "Installing CometBFT", 5 | "privacy": "Privacy and Opsec", 6 | "security": "Security" 7 | } -------------------------------------------------------------------------------- /packages/docs/pages/introduction/install.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | # Install Namada 4 | 5 | 6 | At the moment, Namada only supports Linux and MacOS. 7 | 8 | 9 | ## Installing Namada 10 | Namada can be installed through the following methods: 11 | 12 | 1. [From source](./install/source.mdx) 13 | 2. [From binaries](./install/binaries.mdx) 14 | 3. [From a docker image](./install/docker.mdx) 15 | 16 | The hardware requirements for installing and running a Namada full node can be found [here](../operators/hardware.mdx). -------------------------------------------------------------------------------- /packages/docs/pages/introduction/install/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "source": "Source", 3 | "binaries": "Binaries", 4 | "docker": "Docker" 5 | } 6 | -------------------------------------------------------------------------------- /packages/docs/pages/introduction/install/binaries.mdx: -------------------------------------------------------------------------------- 1 | # Install From Binaries 2 | 3 | ## Pre-requisites 4 | There are certain pre-requisites that need to be installed before installing Namada via binaries. 5 | 6 | These are: 7 | - [CometBFT](./binaries/prerequisites.mdx#installing-cometbft) 8 | - [GLIBC](./binaries/prerequisites.mdx#installing-glibc) 9 | 10 | ## Downloading the binaries 11 | 12 | Now that you have all dependencies installed, you can download the latest binary release from our [releases page](https://github.com/anoma/namada/releases) by choosing the appropriate architecture. 13 | 14 | The below code will download all the binaries for the latest release for all supported operating systems. 15 | ```shell copy 16 | OPERATING_SYSTEM="Linux" # or "Darwin" for MacOS 17 | latest_release_url=$(curl -s "https://api.github.com/repos/anoma/namada/releases/latest" | grep "browser_download_url" | cut -d '"' -f 4 | grep "$OPERATING_SYSTEM") 18 | wget "$latest_release_url" 19 | ``` 20 | 21 | Older versions of the binaries are available from Github -- see the [releases page](https://github.com/anoma/namada/releases) 22 | 23 | Unzip the `tar` using the following command: 24 | ```shell copy 25 | #Assuming the user only has one namada tar file in the current directory 26 | tar -xzvf namada*.tar.gz 27 | ``` 28 | 29 | ## Placing the binaries onto `$PATH` 30 | For ubuntu and mac machines, the following command should work for placing namada into path. 31 | 32 | Once inside the directory containing the binaries: 33 | ```bash copy 34 | sudo cp ./namada* /usr/local/bin/ 35 | ``` 36 | 37 | -------------------------------------------------------------------------------- /packages/docs/pages/introduction/install/binaries/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "overview-of-binaries": "Using the binaries", 3 | "prerequisites": "Prerequisites" 4 | } 5 | -------------------------------------------------------------------------------- /packages/docs/pages/introduction/install/binaries/overview-of-binaries.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | # Using the binaries 4 | 5 | Once installed, you should have the following binaries: 6 | 7 | | Binary | Description | 8 | | --- | --- | 9 | | `namada` | The main binary that can be used to interact with all the components of Namada | 10 | | `namadan` | The ledger node | 11 | | `namadac` | The client | 12 | | `namadaw` | The wallet | 13 | | `namadar` | The ethereum bridge relayer | 14 | 15 | The main binary `namada` has sub-commands for all of the other binaries. Therefore, the following commands are equivalent: 16 | 17 | | `namada` command | `namada`x equivalent | 18 | | --- | --- | 19 | | `namada client` | `namadac` | 20 | | `namada node` | `namadan` | 21 | | `namada wallet` | `namadaw` | 22 | | `namada relayer` | `namadar` | 23 | 24 | 25 | To explore the command-line interface, the `--help` argument can be added at any sub-command level to find out any possible sub-commands and/or arguments. 26 | 27 | -------------------------------------------------------------------------------- /packages/docs/pages/introduction/install/binaries/prerequisites.mdx: -------------------------------------------------------------------------------- 1 | ## Installing CometBFT 2 | 3 | Follow [these instructions](../../installing-cometbft.mdx) in order to setup CometBFT. 4 | 5 | ## Installing GLIBC 6 | Finally, you should have GLIBC `v2.33` or higher. 7 | 8 | **MacOS**: the system-provided glibc should be recent enough. 9 | 10 | **Ubuntu 22.04**: glibc is installed by default and you don't have to do anything more. 11 | 12 | **Ubuntu 18.04 and Ubuntu 20.04**: glibc has `v2.27` and `v2.29` respectively, by default which is lower than the required version to run Namada. We recommend to directly [install from source](../source.mdx) or upgrade to Ubuntu 22.04, instead of updating glibc to the required version, since the latter way can be a messy and tedious task. In case updating glibc would interest you, this [website](http://www.linuxfromscratch.org/lfs/view/9.0-systemd/chapter05/glibc.html) gives you the steps to build the package from source. 13 | -------------------------------------------------------------------------------- /packages/docs/pages/introduction/install/docker.mdx: -------------------------------------------------------------------------------- 1 | # From Docker 2 | 3 | ## Pre-requisites 4 | 5 | In order to run any docker images, you need to have docker installed. You can find instructions on how to install docker for your machine [here](https://docs.docker.com/get-docker/). 6 | 7 | ## Downloading the docker image 8 | The Namada docker image can be found [here](https://github.com/anoma/namada/pkgs/container/namada). 9 | 10 | Under the `Tags` tab, you can find the latest version of the docker image. Click on the link for the correct version of Namada that you are trying to install. For example, if you are trying to install Namada v0.16.0, you would click on the link for `v0.16.0`. 11 | 12 | You can find the tag of the downloaded docker image by running `docker images`. The tag will be the first column of the output. 13 | 14 | 15 | ## Running the docker image 16 | 17 | Once you have downloaded the docker image, it will be useful to export some environment variables: 18 | 19 | ```bash copy 20 | export CHAIN_ID= 21 | ``` 22 | 23 | The following docker run command will run the ledger node: 24 | 25 | ```bash copy 26 | docker run -P -i -t $DOCKER_IMAGE 27 | ``` 28 | 29 | Where `` is any command you would run after `namada` in the terminal. For example, if you wanted to run `namada client utils join-network --chain-id $CHAIN_ID`, you would run: 30 | 31 | ```bash copy 32 | docker run -P -i -t $DOCKER_IMAGE client utils join-network --chain-id $CHAIN_ID 33 | ``` 34 | 35 | Then in order to run any other ledger commands, one can run: 36 | 37 | ```bash copy 38 | docker /bin/bash -c "/bin/bash","-c", "" 39 | ``` 40 | 41 | ## Alternative method (building the docker image yourself) 42 | 43 | Alternatively, you can build the docker image yourself! 44 | 45 | Begin by exporting some environment variables: 46 | 47 | ```bash copy 48 | export CHAIN_ID= 49 | export BRANCH= 50 | ``` 51 | 52 | For example if you wanted to build the docker image for Namada v0.16.0 and chain-id `public-testnet-69.0.b20a1337aa1`, you would run: 53 | 54 | ```bash copy 55 | export CHAIN_ID=public-testnet-69.0.b20a1337aa1 56 | export BRANCH=v0.28.2 #The latest branch of Namada 57 | ``` 58 | 59 | Then you can build the docker image by running: 60 | 61 | ```bash copy 62 | git clone https://github.com/anoma/namada-sdk-starter.git 63 | cd namada-sdk-starter/docker/namada-with-chain/ 64 | docker build --build-arg BRANCH=$BRANCH --build-arg CHAIN_ID=$CHAIN_ID -t namada_testnet_image . 65 | ``` 66 | 67 | Which will save the image to your local docker images. You can find the tag of the downloaded docker image by running `docker images`. The tag will be the first column of the output. 68 | 69 | Save this docker image as an environment variable 70 | ```bash copy 71 | export DOCKER_IMAGE= 72 | ``` 73 | 74 | Then you can run the docker image by running: 75 | 76 | ```bash copy 77 | docker run -P -i -t $DOCKER_IMAGE 78 | ``` -------------------------------------------------------------------------------- /packages/docs/pages/introduction/install/source.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | # Install from source 4 | 5 | 6 | Please note that, although installing from source is the recommended route for installing namada, it can prove to be difficult, and is not recommended for beginners. For a first time installation, the installation process can take up to an hour. Building binaries from source can also take a long time, depending on the machine. 7 | 8 | 9 | ## Pre-requisites 10 | 11 | Ensure the correct [pre-requisites](./source/pre-requisites.mdx) have been downloaded and installed. 12 | 13 | ## Installing Namada 14 | Once all the required dependencies have been installed, the next step is to clone the source code from the [Namada repository](https://github.com/anoma/namada) and build it with: 15 | 16 | ```shell copy 17 | git clone https://github.com/anoma/namada.git 18 | cd namada 19 | make install 20 | ``` 21 | 22 | 23 | During internal and private testnets, checkout the latest testnet branch using `git checkout $NAMADA_TESTNET_BRANCH`. 24 | Where `$NAMADA_TESTNET_BRANCH` is the name of the testnet branch, which will be specified in the [testnet documentation](../testnets/environment-setup.mdx). 25 | 26 | 27 | ## Adding binaries to `$PATH` 28 | The binaries should be added to `$PATH` from the `make install` command. 29 | However, if this for some reason did not work, a solution may be to copy the binaries 30 | from `namada/target/release` to `$HOME/.local/bin/` for example: 31 | 32 | ```shell copy 33 | cp namada/target/release/namada* $HOME/.local/bin/ 34 | ``` 35 | 36 | ## Using the binaries 37 | See the page on [using namada binaries](./binaries/overview-of-binaries.mdx) for more information. 38 | 39 | ## Troubleshooting 40 | Please see the troubleshooting page for [building from source](./source/troubleshooting.mdx) for more information. -------------------------------------------------------------------------------- /packages/docs/pages/introduction/install/source/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "pre-requisites" : "Pre-requisites", 3 | "troubleshooting": "Troubleshooting" 4 | } -------------------------------------------------------------------------------- /packages/docs/pages/introduction/install/source/pre-requisites.mdx: -------------------------------------------------------------------------------- 1 | # Pre-requisites 2 | If you'd like to install Namada from source you will have to install some dependencies first: 3 | 4 | 1. [Rust](https://www.rust-lang.org/tools/install) 5 | 2. [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) 6 | 3. [Clang](https://clang.llvm.org/get_started.html) 7 | 4. [OpenSSL](https://www.openssl.org/source/) 8 | 5. [LLVM](https://releases.llvm.org/download.html) 9 | 10 | ## Rust 11 | At the end of the installation, make sure that Cargo's bin directory `$HOME/.cargo/bin` is available on your PATH environment variable. You can either restart your shell or run `source $HOME/.cargo/env` to continue. 12 | 13 | If you already have Rust installed, make sure you're using the latest version by running: 14 | 15 | ```shell copy 16 | rustup update 17 | ``` 18 | 19 | ## Remaining dependencies 20 | Then, install the remaining dependencies. 21 | 22 | {/* TODO: Turn these into code boxes with toggles for OS */} 23 | 24 | **Ubuntu:** running the following command should install everything needed: 25 | 26 | ```shell copy 27 | sudo apt-get install -y make git-core libssl-dev pkg-config libclang-12-dev build-essential protobuf-compiler libudev-dev 28 | ``` 29 | 30 | **Mac:** installing the Xcode command line tools should provide you with almost everything you need: 31 | 32 | ```shell copy 33 | xcode-select --install 34 | ``` 35 | 36 | `protoc` is also required. On Mac, you can install it with `Homebrew`: 37 | 38 | ```shell copy 39 | brew install protobuf 40 | ``` 41 | 42 | When running 43 | ```shell copy 44 | protoc --version 45 | ``` 46 | It should output at least: 47 | ```shell copy 48 | libprotoc 3.12.0 49 | ``` 50 | 51 | Please refer to [protoc-installation doc](https://grpc.io/docs/protoc-installation/) for other installation options. 52 | -------------------------------------------------------------------------------- /packages/docs/pages/introduction/install/source/troubleshooting.mdx: -------------------------------------------------------------------------------- 1 | # Troubleshooting installation from source 2 | 3 | ### Not enough RAM 4 | [Building binaries locally](../source.mdx) is a computationally heavy task and will put your computer to the test. The compilation usually requires at least 16 GB of RAM and depending on the optimisation of your machine, could require slightly more (for some machines slightly less). For this reason, compilation can sometimes fail. 5 | 6 | The error 7 | ``` 8 | src/apps/namada lib could not compile due to previous errors. Exited with exit code: 9 | ``` 10 | is a common error that can sometimes mean your computer ran out of memory when compiling. To resolve this, I have found closing all other applications and recompiling once or twice will do the trick. Otherwise more RAM will be needed. 11 | 12 | ### Compiling for the first time 13 | Compilation errors due to missing library installations when building the binaries for the first time can be a common problem. 14 | 15 | 16 | #### Linker "CC" not found 17 | If one runs into the error 18 | 19 | ``` 20 | Entering directory '/root/namada/wasm/wasm_source' 21 | RUSTFLAGS='-C link-arg=-s' cargo build --release --target wasm32-unknown-unknown --target-dir 'target' --features tx_bond && \ 22 | cp "./target/wasm32-unknown-unknown/release/namada_wasm.wasm" ../tx_bond.wasm 23 | Compiling proc-macro2 v1.0.46 24 | Compiling quote v1.0.21 25 | error: linker `cc` not found 26 | | 27 | = note: No such file or directory (os error 2) 28 | 29 | error: could not compile `quote` due to previous error 30 | warning: build failed, waiting for other jobs to finish... 31 | error: could not compile `proc-macro2` due to previous error 32 | ``` 33 | 34 | It may be resolved by running 35 | 36 | ```bash copy 37 | sudo apt install build-essential 38 | ``` 39 | 40 | Another solution can sometimes be installing `libcland-dev`. This can be achieved through: 41 | 42 | ```bash copy 43 | sudo apt-get update -y 44 | sudo apt-get install -y libclang-dev 45 | ``` 46 | 47 | 48 | #### WASM32-unknown-unknown 49 | Another issue the compiler may run into is that it cannot find the `wasm32-unknown-unknown` target. 50 | 51 | ``` 52 | error[E0463]: can't find crate for `core` 53 | | 54 | = note: the `wasm32-unknown-unknown` target may not be installed 55 | = help: consider downloading the target with `rustup target add wasm32-unknown-unknown` 56 | 57 | error[E0463]: can't find crate for `compiler_builtins` 58 | 59 | For more information about this error, try `rustc --explain E0463`. 60 | error: could not compile `cfg-if` due to 2 previous errors 61 | ``` 62 | 63 | This issue can be resolved by running 64 | 65 | ```bash copy 66 | rustup target add wasm32-unknown-unknown 67 | ``` 68 | (Yes the name of the target is `wasm32-unknown-unknown`. This is not the compiler unable to tell which version/release it is). 69 | 70 | #### OpenSSL 71 | 72 | If you run into the error 73 | 74 | ``` 75 | Could not find directory of OpenSSL installation, and this `-sys` crate cannot 76 | proceed without this knowledge. If OpenSSL is installed and this crate had 77 | trouble finding it, you can set the `OPENSSL_DIR` environment variable for the 78 | compilation process. 79 | 80 | Make sure you also have the development packages of openssl installed. 81 | For example, `libssl-dev` on Ubuntu or `openssl-devel` on Fedora. 82 | 83 | If you're in a situation where you think the directory *should* be found 84 | automatically, please open a bug at https://github.com/sfackler/rust-openssl 85 | and include information about your system as well as this message. 86 | ``` 87 | 88 | Then the solution is spelled out for you. You need to install the development packages of OpenSSL. For Ubuntu, this is `libssl-dev`. For Fedora, this is `openssl-devel`. For other distributions, please refer to the [OpenSSL website](https://www.openssl.org/). 89 | 90 | For Ubuntu, this can be achieved through 91 | 92 | ```bash copy 93 | sudo apt-get install libssl-dev 94 | ``` -------------------------------------------------------------------------------- /packages/docs/pages/introduction/installing-cometbft.mdx: -------------------------------------------------------------------------------- 1 | # Installing CometBFT 2 | 3 | ## Downloading the latest release 4 | Namada is compatible with CometBFT tag `v0.37.2` 5 | 6 | You can download the latest release from [this repository](https://github.com/cometbft/cometbft/releases/). 7 | - The latest release is `v0.37.2` which can be installed [here](https://github.com/cometbft/cometbft/releases/tag/v0.37.2). 8 | 9 | ## Adding the binaries to $PATH 10 | If you have `go` installed and downloaded, you may want to add it to your `$GOPATH/bin` directory. This can be done by running the following command in the root directory of the repository 11 | 12 | ```bash copy 13 | cp $GOPATH/bin/ 14 | ``` 15 | 16 | Otherwise, we recommend you simply copy it to your `/usr/local/bin` which may require `sudo` permissions. 17 | 18 | `sudo cp /usr/local/bin/` 19 | 20 | And enter your password when prompted. 21 | 22 | In order to check that the installation was successful, you can run the following command 23 | 24 | ```bash copy 25 | cometbft version 26 | ``` 27 | 28 | Which should output something like: 29 | 30 | ```bash copy 31 | 0.37.2 32 | ``` -------------------------------------------------------------------------------- /packages/docs/pages/introduction/privacy.mdx: -------------------------------------------------------------------------------- 1 | # Privacy 2 | 3 | Namada gives the privacy landscape a different shape, by providing the largest possible unified privacy set in the multichain, and complementing other chains by seeding/retrofitting privacy shielded actions. 4 | 5 | * Namada creates a single asset-agnostic shielded pool for any token fungible and non-fungible token 6 | * Namada can also seed privacy to users who want to use an asset originating from one base chain on another chain, without losing privacy 7 | * Namada retrofits privacy to assets that were created and already used in transparent chains 8 | 9 | Users should be aware that they can still expose personal information when transferring funds into and out of Namada via the Ethereum bridge or IBC. For example, a user bridging WETH from Ethereum may be able to obfuscate their on-chain identities to *some* on-chain observers by interacting with Smart contract based privacy protocols or centralized exchanges. However, a user transferring a non-fungible token or a low liquidity token that relies on price discovery on-chain, will leak more information by the nature of their asset holdings. This is also true of tokens transferred into and out of Namada via IBC. Once inside the shielded set, a user can perform *shielded actions* such as triggering a cross chain swap. 10 | 11 | Shielded actions are not limited to application chains that are IBC compatible, it works with any chain that is connected to Namada, e.g. Ethereum, and the actions can be generalized to interact with any dApp, such as trading NFTs or staking ETH. For the time being, the only shielded action available is cross chain transfers, but more will be added in the future. 12 | 13 | ## Best practices for leaking sensitive data include 14 | 15 | * Bridge a highly liquid generic token into the MASP and then once in the MASP performing a shielded action to acquire the relevant tokens 16 | * Use a different public address to bridge funds into Namada than used for other exposed transactions 17 | * Use a TOR browser - Tor protects personal privacy by concealing a user's location and usage from anyone performing network surveillance or traffic analysis 18 | * Use a VPN - A VPN can mask your IP address, encrypt your internet connection and make your browsing activity more anonymous. -------------------------------------------------------------------------------- /packages/docs/pages/introduction/quick-start.mdx: -------------------------------------------------------------------------------- 1 | # Quickstart 2 | 3 | ## About this guide 4 | 5 | This guide is for those interested in getting Namada up and running as quickly as possible. It will guide you through installing Namada, joining a testnet network, running a node, and grabbing some tokens. 6 | 7 | ## Installing Namada 8 | 9 | See [the installation guide](./install.mdx) for details on installing the Namada binaries. Commands in this guide will assume you have the Namada binaries (`namada`, `namadan`, `namadaw`, `namadac`) on your `$PATH`. 10 | 11 | If the binaries are stored somewhere, but are not on your path (perhaps you downloaded the binaries), you can add the binaries to your $PATH with: 12 | 13 | ```shell copy 14 | export PATH=$PATH: 15 | ``` 16 | 17 | If you build from source, and run `make install`, the binaries will be installed to your `$PATH` by default. 18 | 19 | ## Joining a network 20 | 21 | See [the networks page](../networks.mdx) for details on how to join a network. The rest of this guide will assume you have joined a network using the `namadac utils join-network --chain-id ` command. 22 | 23 | ## Run a ledger node 24 | 25 | We recommend this step with [tmux](https://www.hamvocke.com/blog/a-quick-and-easy-guide-to-tmux/), which allows the node to keep running without needing the terminal to be open indefinitely. If not, skip to the subsequent step. 26 | 27 | ```shell copy 28 | tmux 29 | 30 | # inside the tmux/or not 31 | namadan ledger run 32 | 33 | # can detach the tmux (Ctrl-B then D) 34 | ``` 35 | 36 | For a more verbose output, one can run 37 | 38 | ```shell copy 39 | NAMADA_LOG=info CMT_LOG_LEVEL=p2p:none,pex:error NAMADA_CMT_STDOUT=true namada ledger 40 | ``` 41 | 42 | This should sync your node to the ledger and will take a while (depending on your machine's hardware as well as the time between genesis and the start of sync). Subsequent commands (generating an account, etc.) are unlikely to work until your node is fully synced. Enquire the current block height with other participants to make sure you are synced in order to proceed. 43 | 44 | ## Generate an account and grab some tokens 45 | 46 | First you will need an implicit account in order to receive tokens. You can generate one with: 47 | 48 | ```shell copy 49 | namadaw gen --alias 50 | ``` 51 | 52 | For the remainder of this introduction, let's assume your go-to alias is `stanley`. 53 | 54 | This will generate a new account and store it in the default keychain. You can see the account with: 55 | 56 | ```shell copy 57 | namadaw list --addr 58 | ``` 59 | 60 | {/* #TODO: ADD some output */} 61 | 62 | ## Grabbing the tokens (testnet only) 63 | 64 | Testnet tokens can be sourced from the [faucet](https://faucet.heliax.click). 65 | 66 | 67 | ## From here 68 | 69 | From here, you can do a variety of cool things. Perhaps try [shielding your NAM](../users/shielded-accounts/shielded-transfers.mdx), bonding your tokens to a validator for [delegating purposes](../users/delegators.mdx), or [becoming a validator](../operators/validators.mdx). 70 | -------------------------------------------------------------------------------- /packages/docs/pages/introduction/security.mdx: -------------------------------------------------------------------------------- 1 | # Security and bug reporting 2 | 3 | If you discover a security vulnerability or a potential security vulnerability in this project, please let us know as soon as possible by sending an email to [security@heliax.dev](mailto:security@heliax.dev). 4 | 5 | ## Bug bounties 6 | 7 | The current bug bounties for Namada are displayed below. The bounties are paid out in NAM. 8 | 9 | | Vulnerability | Bounty | 10 | | --- | --- | 11 | | Coming | S00N | -------------------------------------------------------------------------------- /packages/docs/pages/networks.mdx: -------------------------------------------------------------------------------- 1 | # Namada Networks 2 | 3 | This page is for Namada networks. 4 | 5 | There are two network types: 6 | 7 | * [Mainnets](./networks/mainnets.mdx) - the main networks 8 | * [Testnets](./networks/testnets.mdx) - the test networks 9 | 10 | The mainnet chain-ids are prefixed with `main` and the testnet chain-ids are prefixed with `test`. 11 | -------------------------------------------------------------------------------- /packages/docs/pages/networks/mainnets.mdx: -------------------------------------------------------------------------------- 1 | # Mainnets 2 | This page will be updated and filled wen mainnet is launched. 3 | 4 | -------------------------------------------------------------------------------- /packages/docs/pages/networks/testnets.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | # Namada Testnets 4 | 5 | For more context read: 6 | 7 | [Announcing Namada Public Testnets](https://blog.namada.net/announcing-namada-public-testnets/) 8 | 9 | ## Shielded expedition 10 | 11 | < Callout type = "info" emoji = "👷" > 12 | For the shielded expedition, it is important to remember to add the `--memo` flag to every transaction. The memo should be filled with the `tpknam` submitted at the shielded-expedition registration period. 13 | For example `namadac transfer --source me --target you --amount 10 --token naan --signing-keys my-key --memo tpknamq1337mypubkey1964qqqqqq` 14 | < /Callout> 15 | 16 | The `balances.toml` file is located at `https://github.com/anoma/namada-shielded-expedition`. 17 | 18 | - Namada Shielded expedition 2: 19 | - From date: 6th of February 2024 18:00 UTC 20 | - Namada protocol version: `v0.31.6` 21 | - Cometbft version: `0.37.2` 22 | - CHAIN_ID: `shielded-expedition.88f17d1d14` 23 | 24 | 25 | The history of all testnets can be found [here](./testnets/testnet-history.mdx). 26 | 27 | ## Namada protocol versions 28 | 29 | A testnet might deploy different versions of the Namada protocol. To see in-detail what each protocol version includes, refer to the [GitHub changelog](https://github.com/anoma/namada/tree/main/.changelog), which specifies what changes have been made in between versions. 30 | 31 | ## Report a bug 32 | 33 | If you find a bug, please submit an issue with the `bug` [issue template](https://github.com/anoma/namada/issues/new/choose). 34 | 35 | ## How to join a Namada testnet 36 | 37 | 1. [Environment setup](./testnets/environment-setup.mdx) 38 | 2. [Pre-genesis instructions](./testnets/pre-genesis.mdx) 39 | 3. [Pre-genesis validator setup](../operators/validators/validator-setup.mdx) 40 | 4. [Pre-genesis validator apply](./testnets/genesis-validator-apply.mdx) 41 | 5. [Running your genesis validator](../operators/validators/validator-setup.mdx#start-validating) 42 | 6. [Running a full node](../operators/ledger/running-a-full-node.mdx) 43 | 7. [Becoming a validator post-genesis](./testnets/post-genesis-validator.mdx) 44 | 45 | ## Testnet flowchart 46 | ![testnet_flowchart](/images/testnet_flowchart.png) 47 | 48 | The Namada public testnet is permissionless, anyone can join without the authorisation of a centralized party. Expect frequent upgrades (every two weeks). 49 | 50 | ## Block explorer 51 | 52 | The block explorer is currently in development. The latest version can be found at [namada.world](https://namada.world/) 53 | 54 | ## Community 55 | 56 | For questions or feedback, please use [GitHub](https://github.com/anoma/namada/issues) or [Discord](https://discord.gg/namada). Don't forget to [follow Namada](https://twitter.com/namada) on Twitter for fun memes and testnet relevant updates. 57 | -------------------------------------------------------------------------------- /packages/docs/pages/networks/testnets/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "environment-setup": "Environment setup", 3 | "migrating-testnets": "Migrating testnets", 4 | "pre-genesis": "Pre-genesis validator setup", 5 | "genesis-validator-apply": "Applying as a genesis validator", 6 | "joining-the-testnet": "Joining the latest Testnet", 7 | "post-genesis-validator": "Becoming a validator after genesis", 8 | "testnet-history": "History of testnets", 9 | "pow": "Using the testnet faucet", 10 | "faq": "FAQ", 11 | "campfire": "Campfire Testnet" 12 | } 13 | -------------------------------------------------------------------------------- /packages/docs/pages/networks/testnets/campfire.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | # The Namada Campfire Testnet ⛺🔥 4 | 5 | 6 | The Namada Campfire ⛺🔥 testnet is run in parallel to the "validator" testnet. This is a community-run testnet, currently being maintained and orchestrated by the [Luminara collective](https://luminara.icu), a small group of Namada supporters. Campfire usually runs the latest release (or pre-release), which may differ from the validator testnet. You can see the version and more at https://testnet.luminara.icu 7 | 8 | 9 | ## Joining 10 | 11 | 12 | The most up-to-date docs on joining Campfire ⛺🔥 can be found [here](https://knowabl.notion.site/Campfire-testnet-5e4c1df53ab64b818a55bfcf36ccc550). 13 | 14 | 15 | ### Pre-requisites 16 | 17 | 18 | Currently, Campfire ⛺🔥 docs only detail support for Ubuntu machines. 19 | 20 | 21 | The user will need to have installed the [Stack-Orchestrator](https://github.com/vknowable/stack-orchestrator), which is a general tool for quickly and flexibly launching and managing a software stack in a containerized environment. The docs are found in the [README](https://github.com/vknowable/stack-orchestrator/#readme) of the repo, and the tool can be installed by running the following command: 22 | 23 | ```bash copy 24 | git clone https://github.com/vknowable/stack-orchestrator.git 25 | cd stack-orchestrator 26 | scripts/namada-quick-install.sh 27 | exit 28 | ``` 29 | 30 | Once this is completed, it is recommended to install Namada through the following Docker image (and the version in this command may need to be [updated accordingly](https://testnet.luminara.icu): 31 | 32 | ```bash copy 33 | export NAMADA_TAG=v0.23.1 34 | docker pull spork666/namada:$NAMADA_TAG 35 | docker image tag spork666/namada:$NAMADA_TAG cerc/namada:local 36 | mkdir -p ~/.local/share/namada 37 | ``` 38 | 39 | ### Running the node 40 | 41 | Once this is completed, the user can run the following command to start the node: 42 | 43 | ```bash copy 44 | curl -o ~/luminara.env https://testnet.luminara.icu/luminara.env 45 | laconic-so --stack public-namada deploy --env-file ~/luminara.env up 46 | echo "export CONTAINER=$(docker ps -q)" | sudo tee -a /etc/profile 47 | CONTAINER=$(docker ps -q) 48 | ``` 49 | 50 | The relevant and more detailed docs are found [here](https://knowabl.notion.site/From-scratch-to-syncing-in-10-minutes-c0a56b34cdec447fbe2a5cd8f559f0bb). 51 | 52 | ## Interacting with the testnet 53 | 54 | The [Luminara collective](https://luminara.icu) has also composed a [Namada CLI cheat sheet](https://www.notion.so/Namada-CLI-cheat-sheet-b54b220610bd4e7e91548e32d7ac3c8a) that is available and useful for any Namada user. 55 | -------------------------------------------------------------------------------- /packages/docs/pages/networks/testnets/environment-setup.mdx: -------------------------------------------------------------------------------- 1 | import { Steps } from 'nextra-theme-docs' 2 | import { Callout } from 'nextra-theme-docs' 3 | 4 | # Environment setup 5 | 6 | < Callout type = "info" > 7 | If you don't want to build Namada from source you can [install Namada from binaries](../../introduction/install/binaries.mdx). 8 | Note that building from source can be a difficult process and is not recommended for beginners. 9 | < /Callout> 10 | 11 | Export the following variables: 12 | 13 | ```bash copy 14 | export NAMADA_TAG=v0.31.6 15 | ``` 16 | 17 | 18 | ## Installing Namada 19 | < Steps > 20 | ### Install all pre-requisites 21 | - [Rust](https://www.rust-lang.org/tools/install) 22 | - [CometBFT](../../introduction/installing-cometbft.mdx) 23 | - [Protobuf](../../introduction/install/source/pre-requisites.mdx) 24 | 25 | ### Clone namada repository and checkout the correct versions 26 | 27 | ```shell copy 28 | git clone https://github.com/anoma/namada && cd namada && git checkout $NAMADA_TAG 29 | ``` 30 | ### Build binaries 31 | ```bash copy 32 | make install 33 | ``` 34 | - There may be some additional requirements you may have to install (linux): 35 | ```bash copy 36 | sudo apt-get update -y 37 | sudo apt-get install build-essential make pkg-config libssl-dev libclang-dev -y 38 | curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh 39 | ``` 40 | < /Steps> 41 | ## Installing CometBFT 42 | < Steps > 43 | ### See the installing CometBFT section [here](../../introduction/installing-cometbft.mdx) for instructions on how to install CometBFT. 44 | ### Copy both the namada and CometBFT binaries to somewhere on $PATH (or use the relative paths). This step may or may not be necessary. 45 | 46 | - namada binaries can be found in `/target/release` 47 | - CometBFT is likely in `$HOME/Downloads/cometbft` 48 | < /Steps> 49 | ## Check ports 50 | < Steps > 51 | ### Open ports on your machine: 52 | - 26656 53 | - 26657 54 | ### To check if ports are open you can setup a simple server and curl the port from another host 55 | 56 | - Inside the namada folder, run 57 | ``` bash 58 | { printf 'HTTP/1.0 200 OK\r\nContent-Length: %d\r\n\r\n' "$(wc -c < namada)"; cat namada; } | nc -l $PORT 59 | ``` 60 | 61 | - From another host run one of the two commands: 62 | - `nmap $IP -p$PORT` 63 | - `curl $IP:$PORT >/dev/null` 64 | 65 | ### Verifying your installation 66 | - Make sure you are using the correct CometBFT version 67 | - `cometbft version` should output `0.37.2` 68 | - Make sure you are using the correct Namada version 69 | - `namada --version` should output `Namada v0.31.6` 70 | 71 | < /Steps> 72 | -------------------------------------------------------------------------------- /packages/docs/pages/networks/testnets/faq.mdx: -------------------------------------------------------------------------------- 1 | # Namada FAQ 2 | 3 | ### **Q: How do I join as a validator post-genesis?** 4 | 5 | **A:** Joining as a validator post genesis can be done following [these instructions](../../operators/validators/validator-setup.mdx). 6 | 7 | ### **Q: How do I use the Faucet?** 8 | 9 | **A:** The faucet can be accessed [here](https://faucet.heliax.click) 10 | 11 | ### **Q: Where can I see the available tokens on the Faucet?** 12 | 13 | **A:** The following list of tokens are available to withdraw from the faucet: 14 | 15 | `NAM, DOT, ETH, BTC` 16 | 17 | There are a few more, but we leave it to you as a challenge to find out which these are 🤔 18 | HINT: `namadac balance` 19 | 20 | ### **Q: How do I use the Ethereum Bridge?** 21 | 22 | **A:** The Ethereum Bridge is not yet implemented as of 0.23.0 Keep an eye on the [Changelog](https://github.com/anoma/namada/tree/main/.changelog) 👀 to see when it will be officially released. 23 | 24 | ### **Q: How can I make an IBC transfer?** 25 | 26 | **A:** As of `v0.23.1` you can now follow the docs [here!](../../users/ibc.mdx) 27 | 28 | ### **Q: What requirements do I need to be a User/Validator?** 29 | 30 | **A:** See [hardware requirements](../../operators/hardware.mdx). 31 | 32 | In order to build binaries from source, at least 16GB RAM will be required. 33 | 34 | ### **Q: Where can I find the binaries to run Namada if I do not want to build from source?** 35 | 36 | **A:** See [Installing Namada from binaries](../../introduction/install/binaries.mdx) 37 | -------------------------------------------------------------------------------- /packages/docs/pages/networks/testnets/genesis-validator-apply.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | # Applying to be a genesis validator 4 | 5 | Before a testnet launches, you can apply to be a genesis validator. 6 | 7 | ### Set up 8 | 9 | Follow [this guide](../../operators/validators/validator-setup.mdx#pre-genesis) on how to generate "pre-genesis" validator files. 10 | 11 | 12 | For the shielded expedition, the `balances.toml` file has been published at the [namada-shieled-expedition repository](https://github.com/anoma/namada-shielded-expedition). 13 | Amounts bonded in the bonding transactions must be less than or equal to the amounts specified in the `balances.toml` file. 14 | It is recommended to leave at least 1000 `NAAN` unbonded for transaction fees. 15 | 16 | 17 | After this, you will have a signed `transactions.toml` file, the contents of which will look something like the following: 18 | 19 | ```toml 20 | [[established_account]] 21 | vp = "vp_user" 22 | threshold = 1 23 | public_keys = ["tpknam1qrf7k5r2kvuppxnp0ruapkkd5szmyxzjxg7t64salgz5wrf6d327wmdh8xj"] 24 | 25 | [[validator_account]] 26 | address = "tnam1q9yprrkkhy0kfngwg59rxx9q2f8kj5ufhctn4n6u" 27 | vp = "vp_user" 28 | commission_rate = "0.01" 29 | max_commission_rate_change = "0.01" 30 | net_address = "1.2.3.4:1000" 31 | 32 | [validator_account.consensus_key] 33 | pk = "tpknam1qz2t8q4xt0vtm4x8kclr4lxhp0sea3956jzltdc2kqx4428a3queja2jx7p" 34 | authorization = "signam1qp2a25j2x2u5ggawvd6fa4z8h7m0tw3ndtulzfwzxtfe6487arazthq2s28v5lmekn6dlp9qukehxwvanzyhfcgqpu7y6cut5l928qsxr3pp7k" 35 | 36 | [validator_account.protocol_key] 37 | pk = "tpknam1qzwl3qsqtthmdwa2xn8pgymlsl3r8mdx53qgpm7xwwxgmn4hg0hjccnd27q" 38 | authorization = "signam1qzp03svcajhr7f68ayy3kq8xq4l78j7qdnxfc2v0g3s0qt69gkxhm0kx866hg77wty9hj004jfn94pavkmfqxqhyypjs0padv99vrjsqeqgg9q" 39 | 40 | [validator_account.tendermint_node_key] 41 | pk = "tpknam1qqwxpdvqyqlke25cfg46knx3slmzl84ap6v3kunu5r4efu3va3n7zf7nduz" 42 | authorization = "signam1qpwzap7pczw3dlxjjxauhls9rya4fpxu4mmtrplkx9yfur5t3cf4wmwkvexnd4jyaeme3l9tfuxt7aapzzmjjsejsz8zz5upccykafgyu3dzqm" 43 | 44 | [validator_account.eth_hot_key] 45 | pk = "tpknam1qypdeegcgv32w6ynrqsaml546rn9jr8ua9pv54t0dpdyuf2069eyflghxz99u" 46 | authorization = "signam1qx5ve2mcu2s8pajr4w6tat9z3v3p4g75zy9vug0w7epwdzapg7k8u3jxrsg5kax4xk7p3maxv49va98hsz6ntdfs2fx3whk70raepyg3qyn0nufq" 47 | 48 | [validator_account.eth_cold_key] 49 | pk = "tpknam1qyp0659xh8e8la0gx39f40epmamgug5l2ddgpplfe2zgpm8xlk7yzhcpnfx2e" 50 | authorization = "signam1q806c02930rdnac5jtxtnmdr6jwhfwteu4eqchu0xe5jgaqsv0znztam6u3tyatme6fh72les7d502wpajqa0v8l5kc8cpef4nv8py5lqyv80ct3" 51 | 52 | [validator_account.metadata] 53 | email = "test@test.com" 54 | 55 | [validator_account.signatures] 56 | tpknam1qrf7k5r2kvuppxnp0ruapkkd5szmyxzjxg7t64salgz5wrf6d327wmdh8xj = "signam1qptu8kxn9apr7e7h438d60gsaqyupvgcur9rcxva4ft3vzh67y4qv2v2rm7ugg469kpe6qx7cr206n8tk0daqw9h03k72m6ffqwf56swvg0cjs" 57 | 58 | [[bond]] 59 | source = "tnam1q9yprrkkhy0kfngwg59rxx9q2f8kj5ufhctn4n6u" 60 | validator = "tnam1q9yprrkkhy0kfngwg59rxx9q2f8kj5ufhctn4n6u" 61 | amount = "100" 62 | 63 | [bond.signatures] 64 | tpknam1qrf7k5r2kvuppxnp0ruapkkd5szmyxzjxg7t64salgz5wrf6d327wmdh8xj = "signam1qqgn525t548eg7nrwhrlke0n6r8d3zqw79tdkeyva79r6snc26ew6fq2fkvunljw7l6hq5ed6e8dqyaq9afexwd88gnprlusjds77qgq57ej0a" 65 | ``` 66 | 67 | This file contains only public information and is safe to share publicly. 68 | 69 | 70 | ### Submitting the config 71 | 72 | 73 | For the shielded expedition, use the repository `https://github.com/anoma/namada-shielded-expedition` instead of `https://github.com/anoma/namda-testnets`. 74 | 75 | 76 | If you want to be a genesis validator for the testnet, please make a pull request to `https://github.com/anoma/namada-testnets` (`https://github.com/anoma/namada-shielded-expedition` for the Shielded expedition) adding your **signed** `transactions.toml` file to the relevant directory (e.g. `namada-public-testnet-2` for the second public testnet), renaming it to `""".toml`. 77 | E.g. if you chose your alias to be "bertha", submit the file with the name `bertha.toml`. You can see what an example PR looks like [here](https://github.com/anoma/namada-testnets/pull/2616). 78 | 79 | ### Wait for the `CHAIN_ID` 80 | Wait until the corresponding `CHAIN_ID` has been distributed. -------------------------------------------------------------------------------- /packages/docs/pages/networks/testnets/joining-the-testnet.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | # Joining the latest testnet 4 | 5 | Depending on whether you are a genesis validator, you can join the latest testnet either as a genesis validator or as a full node. 6 | 7 | ## Joining as a genesis validator 8 | 9 | In order to join the network as a genesis validator, you will need to have been selected in the genesis ceremony. If you have not been selected, you can still join as a full node. 10 | 11 | 12 | For the shielded expedition, only the top 114 pilots have been selected as genesis validators. If you were not selected, you can still bond to one of the genesis validators or become a post-genesis validator. 13 | 14 | 15 | If you have been selected. You must run the following command: 16 | 17 | ```bash 18 | CHAIN_ID="" 19 | VALIDATOR_ALIAS="" 20 | NAMADA_NETWORK_CONFIGS_SERVER="https://github.com/anoma/namada-shielded-expedition/releases/download/shielded-expedition.88f17d1d14" namadac utils join-network --chain-id $CHAIN_ID --genesis-validator $VALIDATOR_ALIAS 21 | ``` 22 | 23 | 24 | Note that if you use the above command, your pre-genesis wallet must be in the default base directory (`$BASE_DIR`). If the wallet is not in the default base directory, you must use the flag `--pre-genesis-path` instead. The value for this will be `$BASE_DIR/pre-genesis/$VALIDATOR_ALIAS`. 25 | 26 | E.g if your base directory is `.namada` and your validator alias is `my-validator`, then run the command 27 | 28 | ```bash 29 | CHAIN_ID="" 30 | VALIDATOR_ALIAS="my-validator" 31 | BASE_DIR=".namada" 32 | NAMADA_NETWORK_CONFIGS_SERVER="https://github.com/anoma/namada-shielded-expedition/releases/download/shielded-expedition.88f17d1d14" namadac utils join-network --chain-id $CHAIN_ID --pre-genesis-path $BASE_DIR/pre-genesis/$VALIDATOR_ALIAS 33 | ``` 34 | 35 | 36 | Running the node of a pre-genesis validator is identical to that of a mainnet validator. 37 | 38 | For this reason, please refer to [these docs](../../operators/validators/validator-setup.mdx#start-validating) for running the node. 39 | 40 | ## Submitting bonding transactions as a non-genesis validator 41 | If your public key has been allocated `NAM` (`NAAN` for the shielded expedition), you can bond to a genesis validator as a pre-genesis transaction. 42 | Please follw the steps [here](../../operators/networks/genesis-flow/participants.mdx#bond-to-a-pre-genesis-validator-account) in order to submit these transactions. 43 | 44 | Remember to sign these transactions as well. 45 | 46 | ## Joining as a full node 47 | If you are not a genesis validator, please follow the steps for [joining as a full node](../../operators/ledger/running-a-full-node.mdx). 48 | 49 | It is then possible to test being a validator by [becoming a post-genesis validator](./post-genesis-validator.mdx). 50 | 51 | 52 | -------------------------------------------------------------------------------- /packages/docs/pages/networks/testnets/migrating-testnets.mdx: -------------------------------------------------------------------------------- 1 | import { Callout, Steps } from 'nextra-theme-docs' 2 | 3 | # Steps for migrating testnets 4 | 5 | 6 | With the introduction of `v0.28.0` there is no way to migrate keys over. Please follow the instructions from scratch. 7 | -------------------------------------------------------------------------------- /packages/docs/pages/networks/testnets/post-genesis-validator.mdx: -------------------------------------------------------------------------------- 1 | # Become a validator post genesis 2 | 3 | After genesis, you can still join the network as a user and become a validator through self-bonding. 4 | 5 | After [joining the network as a full node](../../operators/ledger/running-a-full-node.mdx), you must [create a validator account](../../operators/validators/validator-setup.mdx). 6 | 7 | After this has been completed, you will need to increase your validator's `bonded-stake`, which can be done by self-bonding tokens sourced from the faucet. 8 | 9 | 10 | ## Bonding 11 | 12 | Follow [this guide](../../operators/validators/staking.mdx#self-bonding) on how to self-bond a validator's tokens. 13 | 14 | ## Check bonded-stake 15 | In order to vote on blocks, a validator must have enough `bonded-stake` to be included in the validators "consensus-set". A validator is in the consensus set if and only if it has enough `bonded-stake` to be in the top 128 validators by `bonded-stake`. 16 | 17 | To query the bonded-stake for all the validators in the current epoch, run the following command: 18 | ```bash copy 19 | namada client bonded-stake 20 | ``` -------------------------------------------------------------------------------- /packages/docs/pages/networks/testnets/pow.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | # The PoW Solution on Namada 4 | 5 | 6 | The link to the faucet is [https://faucet.heliax.click](https://faucet.heliax.click) 7 | 8 | 9 | As of `v0.23.1`, the Namada faucet has been moved to be an API call to a server. In order to request tokens, a proof of work challenge must be completed, in order to prevent spamming of the faucet. 10 | 11 | 12 | Note that this is not included in Mainnet as it is circumstantial to testnet. 13 | 14 | 15 | Since [fees are paid by implicit accounts](../../users/fees.mdx), it is recommended to source NAM to one of these accounts as the first step. Afterwards, using the `--gas-payer` flag, you can specify the address of the implicit account to pay for the transaction. 16 | 17 | -------------------------------------------------------------------------------- /packages/docs/pages/networks/testnets/pre-genesis.mdx: -------------------------------------------------------------------------------- 1 | # Pre-genesis validator instructions 2 | 3 | Pre-genesis is defined as "before" the first (a.k.a genesis) block. 4 | At genesis, there will be a set of validators with a pre-defined amount of tokens (described in the genesis file). 5 | 6 | For testnets, it is possible to apply to become a pre-genesis validator. 7 | In order to do so, please follow [these steps](./genesis-validator-apply.mdx). 8 | 9 | If the testnet is already running and you have not been selected as a pre-genesis validator, please follow the steps for [joining as a full node](../../operators/ledger/running-a-full-node.mdx). If you still wish to validate, you can follow the steps to [become a post-genesis-validator](./post-genesis-validator.mdx). 10 | -------------------------------------------------------------------------------- /packages/docs/pages/operators.mdx: -------------------------------------------------------------------------------- 1 | # Operators Guide 2 | 3 | This guide is intended for operators of Namada full nodes. This includes both full nodes as well as validator nodes. 4 | The guide assumes that you have already installed the node and are familiar with the basics of running a node. 5 | 6 | ## Table of Contents 7 | 8 | - [Running a full node](./operators/ledger.mdx) 9 | - [Running a validator node](./operators/validators.mdx) 10 | - [Setting up a local network](./operators/networks/local-network.mdx) -------------------------------------------------------------------------------- /packages/docs/pages/operators/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "hardware": "Hardware requirements", 3 | "ledger": "Running a full node", 4 | "remote-signing": "Remote signing", 5 | "validators": "Validators", 6 | "networks": "Starting a network", 7 | "ibc": "IBC Relayers", 8 | "troubleshooting": "Troubleshooting" 9 | } -------------------------------------------------------------------------------- /packages/docs/pages/operators/eth-bridge.mdx: -------------------------------------------------------------------------------- 1 | # Namada Ethereum Bridge 2 | 3 | The ethereum bridge on Namada is a trustless (in the sense that the only trust assumptions are that validators on Namada are collectively honest) bridge between Namada and Ethereum. 4 | 5 | The bridge is a combination of smart contracts on Ethereum as well as ledger protocol code that enables its functionality. The bridge is designed to be generic, and can be used to bridge any chain that has a BFT consensus mechanism. 6 | 7 | 8 | ## Design 9 | 10 | The full design specs can be found [here](https://specs.namada.net/modules/ethereum-bridge). 11 | 12 | A short outline of the design is outlined below. 13 | 14 | ## The ethereum side 15 | 16 | Value transferred to the Namada is escrowed in a vault abstraction, which 17 | enables other contracts to be upgraded without moving value around. When ERC20 18 | tokens are transferred back to Ethereum, value is released from escrow into the 19 | destination accounts. 20 | 21 | ## The Namada side 22 | 23 | When a transfer is initiated from Ethereum to Namada, the transfer is validated by the validators. Once this validation is complete, the transferred funds are minted on the Namada side and sent to the destination account. When tokens are sent back to Ethereum, they are burnt on the Namada end. 24 | 25 | This documentation is intended for relayers and validators on Namada and is structured as follows: 26 | 27 | - [Relaying transactions](./eth-bridge/relaying.mdx) -------------------------------------------------------------------------------- /packages/docs/pages/operators/eth-bridge/relaying.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | # Relaying Ethereum Transactions 4 | 5 | Relayer commands are found in the `namadar` binary, which at the moment can only be installed from source. 6 | 7 | ## Relaying validator set updates 8 | 9 | In order for any transactions to be relayed to the Ethereum smart contract, the validator sets need to be up to date on the Ethereum side. This is updated by a relayer which can be set up in the following manner: 10 | 11 | ```bash copy 12 | namadar validator-set relay --daemon --confirmations 1 --retry-sleep 0 --success-sleep 0 --safe-mode 13 | ``` 14 | 15 | The `--safe-mode` flag is optional, but recommended. It will stop the relayer from being shut down by `^C` and will instead wait for the current batch of transactions to be relayed before shutting down. 16 | 17 | More optional flags are available, which can be found by running `namadar validator-set relay --help`. Notably, `--eth-gas`and `--eth-gas-price` will allow you to set the maximum gas-limit and gas-price, respectively, that the relayer will use when relaying transactions to the Ethereum smart contract. 18 | 19 | ## Relaying transactions 20 | 21 | Transactions are relayed in batches. The relayer will wait until it has a batch of transactions to relay before sending them to the Ethereum smart contract. This is done to reduce the number of transactions that need to be sent to the Ethereum smart contract, and thus reduce the gas costs. 22 | 23 | The relayer can get a "recommended-batch" of signed transactions to relay by running: 24 | 25 | ```bash 26 | namadar ethereum-bridge-pool recommend-batch 27 | ``` 28 | 29 | If this is favourable for the relayer, it can construct the proof and relay it to the Ethereum smart contract by running: 30 | 31 | ```bash 32 | namadar ethereum-bridge-pool relay-proof --hash-list $HASH_LIST 33 | ``` 34 | 35 | 36 | As this involves an Ethereum transaction, the `--eth-gas` and `--eth-gas-price` flags are also available here. 37 | 38 | 39 | Alternatively, the relayer can run the command: 40 | 41 | ```bash 42 | namadar ethereum-bridge-pool construct-proof --hash-list $HASH_LIST 43 | ``` 44 | 45 | To only construct the proof without relaying it. The proof could then be relayed manually by the relayer. 46 | 47 | 48 | 49 | -------------------------------------------------------------------------------- /packages/docs/pages/operators/hardware.mdx: -------------------------------------------------------------------------------- 1 | # Hardware Requirements 2 | 3 | This section covers the recommended hardware requirements for engaging with Namada for validators, full nodes and light nodes. 4 | 5 | ## Resource Requirements 6 | 7 | | Node Type | RAM | SSD | Number of Cores | 8 | | ---------- | -------- | ---------- | --------------- | 9 | | Validator | 16GB | 1TB* | 4 | 10 | | Full Node | 8GB | 1TB | 2 | 11 | | Light Node | TBD | TBD | TBD | 12 | 13 | **Note that storage size will be dependent on level of pruning.* 14 | 15 | 16 | -------------------------------------------------------------------------------- /packages/docs/pages/operators/ledger.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | # The Namada Ledger 4 | 5 | In order to make any interactions with the Namada blockchain through the Namada *client* `namadac`, the ledger must be running. 6 | 7 | To start a local Namada ledger node, one can run: 8 | 9 | ```shell copy 10 | namada ledger 11 | ``` 12 | 13 | 14 | **Note**: You must have [joined a network](../networks.mdx) before you start the ledger. It throws an error if no network has been configured. 15 | 16 | The node will attempt to connect to the persistent validator nodes and other peers in the network, and synchronize to the latest block. 17 | 18 | By default, the ledger will store its configuration and state in your [base directory](./ledger/base-directory.mdx). 19 | You can use the `--base-dir` CLI global argument or `BASE_DIR` environment variable to change it. 20 | 21 | Assuming you do not have a custom base_dir, you can export the BASE_DIR environment variable as follows: 22 | 23 | ```shell copy 24 | export BASE_DIR=$(namadac utils default-base-dir) 25 | ``` 26 | 27 | 28 | When the ledger is run for the first time, the MASP-parameters will be downloaded. This is essential for producing the zero knowledge proofs required to make shielded transactions. 29 | 30 | ### The ledger wasm files 31 | The ledger will also download the genesis block, which contains the initial state of the blockchain. 32 | The ledger also needs access to the built WASM files that are used in the genesis block. 33 | These files are included in release and shouldn't be modified, otherwise your node will fail with a consensus error on the genesis block. 34 | By default, these are expected to be in the `wasm` directory inside the chain directory that's in the base directory, i.e `$BASE_DIR/$CHAIN_ID/wasm`. 35 | The wasm directory can also be set with the `--wasm-dir` CLI global argument, `NAMADA_WASM_DIR` [environment variable](./ledger/env-vars.mdx) or the configuration file. 36 | 37 | ### Ledger configuration 38 | The ledger configuration is stored in `$BASE_DIR/$CHAIN_ID/config.toml` (with 39 | default `--base-dir`). It is created when you join the network. You can modify 40 | that file to change the configuration of your node. All values can also be set 41 | via [environment variables](./ledger/env-vars.mdx). 42 | 43 | 44 | -------------------------------------------------------------------------------- /packages/docs/pages/operators/ledger/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "env-vars": "Environment variables", 3 | "running-a-full-node": "Setting up the full node", 4 | "logging-config": "Logging configurations", 5 | "base-directory": "Base directory" 6 | } -------------------------------------------------------------------------------- /packages/docs/pages/operators/ledger/base-directory.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | # Base Directory 4 | 5 | The base directory on Namada is the directory where all chain-specific data is stored. It is a directory that is created immediately once the network is joined (with `namadac utils join-network`, for example). 6 | 7 | As of the latest version of Namada, the base directory is located in the following locations: 8 | 9 | 10 | Technically, the correct directory will be the one assigned to `$XDG_DATA_HOME`, 11 | but if you haven't set that variable, it will default to one of the below. 12 | 13 | 14 | ## The quick way 15 | 16 | You can find the base directory by running the following command: 17 | 18 | ```bash copy 19 | namadac utils default-base-dir 20 | ``` 21 | 22 | Which should correspond to one of the following directories: 23 | 24 | #### Linux 25 | 26 | ```bash copy 27 | $HOME/.local/share/namada 28 | ``` 29 | 30 | #### MacOS 31 | 32 | ```bash copy 33 | $HOME/Library/Application\ Support/Namada 34 | ``` 35 | 36 | ## What to expect 37 | Within these folders, you should see the following files and folders: 38 | 39 | ```bash copy 40 | global-config.toml 41 | / 42 | .toml 43 | pre-genesis # If you are a pre-genesis validator 44 | ``` 45 | -------------------------------------------------------------------------------- /packages/docs/pages/operators/ledger/logging-config.mdx: -------------------------------------------------------------------------------- 1 | # Configuring Logging on Namada 2 | 3 | The logging of the ledger can be configured by setting the following environment variables. 4 | Default values are in **bold**. 5 | 6 | | Variable | Values | Description | 7 | | :------------------: | :----------------------------------------: | :---------------------: | 8 | | `NAMADA_LOG` | **`info`**, `debug`, `warn`, `error` | Logging verbosity | 9 | | `NAMADA_LOG_COLOR` | **`true`**, `false` | Switch colors on / off | 10 | | `NAMADA_LOG_DIR` | | If set, the logs will be written to files in the specified directory. The log files will be named `namada.log` and `namada.err.log` and compressed using `gzip`. | 11 | | `NAMADA_LOG_FMT` | **`full`**, `json`, `pretty` | Logging format | 12 | | `NAMADA_LOG_ROLLING` | **`never`**, `minutely`, `hourly`, `daily` | Rolling logs frequency | 13 | | `NAMADA_CMT_STDOUT` | `true`, **`false`** | Print all the CometBFT logs to stdout. (This information may be valuable to validators.) | 14 | | `CMT_LOG_LEVEL` | **`info`**, `debug`, `warn`, `error` | CometBFT logs verbosity | 15 | -------------------------------------------------------------------------------- /packages/docs/pages/operators/ledger/running-a-full-node.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | # Full Node Setup 4 | Before starting a full node, the unique identifier of the `chain-id` will be needed, which will be released as soon as the genesis file is ready. 5 | 6 | ### Join the network 7 | Once the `chain-id` has been distributed, it is possible to join the network with the `CHAIN_ID`: 8 | ```bash copy 9 | export CHAIN_ID="namada-mainnet" ## (replace with the actual chain-id) 10 | NAMADA_NETWORK_CONFIGS_SERVER="https://github.com/anoma/namada-shielded-expedition/releases/download/shielded-expedition.88f17d1d14" namada client utils join-network --chain-id $CHAIN_ID 11 | ``` 12 | 13 | ### Start your node and sync 14 | ```bash copy 15 | CMT_LOG_LEVEL=p2p:none,pex:error namada node ledger run 16 | ``` 17 | Optional: If you want more logs, you can instead run 18 | ```bash copy 19 | NAMADA_LOG=info CMT_LOG_LEVEL=p2p:none,pex:error NAMADA_CMT_STDOUT=true namada node ledger run 20 | ``` 21 | And if you want to save your logs to a file, you can instead run: 22 | ```bash copy 23 | TIMESTAMP=$(date +%s) 24 | NAMADA_LOG=info CMT_LOG_LEVEL=p2p:none,pex:error NAMADA_CMT_STDOUT=true namada node ledger run &> logs-${TIMESTAMP}.txt 25 | tail -f -n 20 logs-${TIMESTAMP}.txt ## (in another shell) 26 | ``` 27 | 28 | ### Running namada as a systemd service 29 | 30 | The below script is a community contribution by Encipher88, and currently only works on Ubuntu machines. 31 | It has served useful for many validators. 32 | 33 | The below assumes you have installed namada from source, with `make install`. It at least assumes the respective binaries are in `/usr/local/bin/`. 34 | 35 | ```bash copy 36 | which namada ## (should return /usr/local/bin/namada) 37 | ``` 38 | 39 | The below makes a service file for systemd, which will run namada as a service. This is useful for running a node in the background, and also for auto-restarting the node if it crashes. 40 | ```bash copy 41 | sudo tee /etc/systemd/system/namadad.service > /dev/null < 20 | 21 | ### Collecting pre-genesis public keys 22 | 23 | The ceremony begins by the network coordinator collecting the public keys of the pre-genesis network participants. The network coordinator must ensure that the total number of pre-genesis public keys collected is equal to the total number of pre-genesis network participants. 24 | 25 | Conventionally, the network coordinator hosts a git repository that allows the pre-genesis network participants to submit their public keys. The network coordinator must ensure that the git repository is publicly accessible and that the pre-genesis network participants are able to submit their public keys in a secure manner. 26 | 27 | ### Allocating pre-genesis NAM balances 28 | 29 | Once the participants have [submitted their keys and addresses](./participants.mdx#submitting-keys-and-addresses) the network coordinator must allocate balances to these addresses/public keys. The coordinator will often have prior identity information associated with desired balances, which they will then associate with the public keys and addresses in order to set the correct balances in `balances.toml`. The coordinator must also ensure that the total pre-genesis NAM balances allocated to the pre-genesis network participants is equal to the total NAM supply. 30 | 31 | After this is completed, the network coordinator will publish the `balances.toml` file that contains the pre-genesis NAM balances allocated to the pre-genesis network participants. The `balances.toml` file should be published in the same location as the pre-genesis public keys were submitted. 32 | 33 | 34 | ### Collecting pre-genesis transactions 35 | 36 | Once the participants have [submitted their keys and addresses](./participants.mdx#submitting-keys-and-addresses) the network coordinator must collect the signed pre-genesis transactions from the pre-genesis network participants. The network coordinator must ensure that the total number of pre-genesis transaction files collected is equal to the total number of pre-genesis network participants. 37 | 38 | The network coordinator then aggregates these transaction files into one file and saves it as the `transactions.toml` file to be used in the generation of the genesis block. 39 | 40 | The `transactions.toml` file is validated by the network coordinator to ensure that each transaction has been correctly signed by each pre-genesis network participant. The network coordinator must ensure that the `transactions.toml` file is valid before proceeding to the next step. 41 | 42 | ### Generating the genesis block 43 | 44 | Once the network coordinator has collected the pre-genesis public keys, allocated pre-genesis NAM balances, and collected pre-genesis transactions, the network coordinator is ready to generate the genesis block. 45 | 46 | 47 | -------------------------------------------------------------------------------- /packages/docs/pages/operators/networks/local-network.mdx: -------------------------------------------------------------------------------- 1 | import Expandable from "../../../components/Expandable"; 2 | 3 | # Spinning up a local network 4 | 5 | ## Prerequisites 6 | 7 | Namada must be installed [from source](../../introduction/install/source.mdx) in order to run a local network. 8 | 9 | There is a script that has been written specifically for this purpose, which can be found under `MakeFile` in the root directory. 10 | 11 | ### Installing script dependencies 12 | 13 | The script has some dependencies that must be installed in order to run it successfully: 14 | 15 | 1. python3 must be installed. 16 | 2. toml Python pip library https://pypi.org/project/toml/ must be installed. 17 | 18 | The script will require a set of genesis configuration files, which are TOML files that specify the parameters of the network. All of these files can be found in the `namada/genesis/localnet` directory. 19 | 20 | ### Building wasm 21 | 22 | The script will also require all `wasm` files for transactions to be built. This can be done by running the following command (whilst in the namada directory): 23 | 24 | ```shell 25 | make build-wasm-scripts 26 | ``` 27 | 28 | ## Running the script 29 | 30 | The script is called `gen_localnet.py` and can be run with the following command: 31 | 32 | ```shell 33 | # Ensure you are in the root of the namada repository directory 34 | python3 ./scripts/gen_localnet.py 35 | ``` 36 | 37 | The script also takes a number of positional arguments that can be supplied. These are: 38 | 39 | ```text 40 | -h, --help show this help message and exit 41 | --localnet-dir LOCALNET_DIR 42 | The localnet directory containing the genesis templates. 43 | -m MODE, --mode MODE The mode to run the localnet in. Can be release or debug, defaults to debug. 44 | --epoch-length EPOCH_LENGTH 45 | The epoch length in seconds, defaults to parameters.toml value. 46 | --max-validator-slots MAX_VALIDATOR_SLOTS 47 | The maximum number of validators, defaults to parameters.toml value. 48 | --params PARAMS A string representation of a dictionary of parameters to update in the parameters.toml. Must be of the same format. 49 | ``` 50 | 51 | For example, a MacOS user would run something along the lines of: 52 | 53 | ```bash 54 | # Assuming pwd == root of namada repository 55 | python3 ./scripts/gen_localnet.py \ 56 | --localnet-dir genesis/localnet \ 57 | --mode release # Assuming the binaries were built using `make build-release` \ 58 | --parameters '{"parameters": {"max_expected_time_per_block": 10}, "pos_params": {"pipeline_len": 5}}' 59 | # In order to change max_expected_time_per_block to 10 seconds from the default 30, and the pipeline length to 5 epochs from the default 2. 60 | --num-nodes 2 # OPTIONAL: To run the localnet with 2 nodes 61 | --num-vals 2 # OPTIONAL: To run the localnet with 2 validators 62 | ``` 63 | 64 | ### Modifying the genesis configuration file 65 | 66 | The genesis configuration can be modified in two ways. One is to change the contents of the toml file directly. The other is to use the `parameters` argument when running the script. The `parameters` argument takes a string representation of a dictionary of parameters to update in the parameters.toml. The format of the string must be the same as the format of the dictionary in the toml file. 67 | 68 | ## Running the ledger 69 | 70 | After the script has been run, all of the necessary folders will have been set up to run the chain. 71 | The ledger can be run through the familiar command: 72 | 73 | ```shell 74 | ./target/release/namada ledger # Assuming the binaries were built using `make build-release` 75 | ``` 76 | 77 | ## Cleaning up 78 | 79 | After the local network has fulfilled its purpose, it can be cleaned up by running the following commands found in the cleanup function of the script: 80 | 81 | ```shell copy 82 | killall namadan 83 | # delete the base_dir/chain_id directory 84 | ``` 85 | -------------------------------------------------------------------------------- /packages/docs/pages/operators/troubleshooting.mdx: -------------------------------------------------------------------------------- 1 | 2 | # Operator Troubleshooting 3 | 4 | ### Missed pre-genesis 5 | 6 | If you missed setting up as a validator pre-genesis, this means you must set up to become one post-genesis. It is not possible to add pre-genesis validators once the chain has been launched (as by definition). Instead, any full-node can become a validator through self-bonding NAM tokens. 7 | 8 | ### CometBFT 9 | 10 | When facing CometBFT issues as a validator, the most common cause of the issue is that we are running the wrong version of CometBFT. Keep an eye on the testnet docs [here](../networks/testnets.mdx) 11 | 12 | >Note that the common debug statement `Error reconnecting to peers` does not mean that your node is not working properly. Instead, it means there *exists at least one* validator on the network not working properly. To check whether this is a problem on your end, note the block height and see if it corresponds to the blockheight at [https://namada.world](https://namada.world) 13 | 14 | 15 | 16 | -------------------------------------------------------------------------------- /packages/docs/pages/operators/validators.mdx: -------------------------------------------------------------------------------- 1 | # Validators on Namada 2 | 3 | Namada is a proof-of-stake blockchain, which means that the validators are the ones who are responsible for both voting on state-transitions and proposing new blocks. 4 | 5 | ### What is a genesis validator? How does it differ from a post-genesis Validator? 6 | 7 | A (pre-)genesis validator is a validator who is proposed to be a validator in the genesis block of the blockchain. If the genesis file is accepted by the network, then the (pre-)genesis validators are able to conduct validating activities on the blockchain, with the stake specified in the genesis file. These validators are setup with the correct consensus keys, which must match those specified in the genesis file. 8 | 9 | A post-genesis validator, on the other hand, is a validating account which was created sometime after the genesis block. These accounts are initiated by the `init-validator` command. 10 | 11 | ### How do I become a validator? 12 | 13 | #### Pre-requisites 14 | Validators require stake in the form of NAM in order to participate in the consensus process. The amount of stake required is specified in the genesis file. In order to become a validator, you must have at least the minimum amount of stake required. 15 | 16 | In addition, the validator node must meet the [minimum hardware requirements](./hardware.mdx). 17 | 18 | #### Steps 19 | 20 | See these steps for [setting up a genesis validator](./validators/validator-setup.mdx). 21 | 22 | See these steps for [setting up a post-genesis validator](./validators/validator-setup.mdx). -------------------------------------------------------------------------------- /packages/docs/pages/operators/validators/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "validator-setup": "Validator setup", 3 | "staking": "Staking", 4 | "proof-of-stake": "Proof of stake", 5 | "jailing": "Jailing" 6 | } -------------------------------------------------------------------------------- /packages/docs/pages/operators/validators/jailing.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | # Jailed validators 4 | 5 | Validators can be *jailed* for several reasons, such as double signing a block, signing an invalid block, or excessive downtime. Each of these reasons will have different ramifications for the validator. 6 | 7 | When a validator is jailed, it is removed from the validator sets and cannot participate in consensus. The validator node can still run and process the new blocks. A jailed validator can also still receive bonds. 8 | 9 | When the protocol determines that a validator will be jailed, the jailing and validator set removal will occur at the beginning of the next new epoch. 10 | 11 | You can check if a validator is jailed by querying its state with the following command: 12 | 13 | ```bash copy 14 | namadac validator-state --validator 15 | ``` 16 | 17 | ## Unjailing a validator 18 | 19 | Once jailed, validators remain jailed indefinitely. They can only be unjailed by an `unjail-validator` transaction using the validator's signing keys. This can be done with the following command: 20 | 21 | ```bash copy 22 | namadac unjail-validator --validator 23 | ``` 24 | 25 | 26 | Because the validator alias sometimes clashes with the alias for the implicit account and or established account in the wallet, it is recommended to use the validator address instead of the alias. 27 | In order to find the validator address, you can use the following command: 28 | ```bash copy 29 | namadaw list --addr | grep 30 | ``` 31 | then make sure it is the corresponding `tnam` address. 32 | 33 | 34 | If the transaction is successful, then the validator will be reinstated into one of the validator sets at the pipeline length relative to the current epoch (typically 2 epochs in the future). 35 | 36 | There may be certain restrictions on unjailing your validator depending on the original reason for jailing. These will be described below. 37 | 38 | ## Jailing for protocol misbehavior 39 | 40 | Protocol misbehaviors include the aforementioned double signing of a block and signing of an invalid block. 41 | 42 | In these cases, the validator will also be slashed - it and its delegates will lose stake and voting power. 43 | 44 | When a slash is detected and enqueued by the protocol, it is scheduled to be processed `unbonding_len + cubic_slashing_window_len + 1` epochs after the infraction epoch. This is to allow for sufficient time to detect all possible correlated infractions to be considered for cubic slashing. 45 | 46 | The validator will also be considered to be *frozen* until it no longer has any unprocessed, enqueued slashes. While *frozen*, unbonding from the validator is prohibited, and unjailing is forbidden. 47 | 48 | A validator's slash history, with previously processed slashes and enqueued slashes for future processing, can be queried with the following command: 49 | 50 | ```bash copy 51 | namadac slashes --validator 52 | ``` 53 | 54 | Additionally, all slashes in the network can be queried without the `--validator` flag. 55 | 56 | ## Jailing for downtime (liveness) 57 | 58 | While a validator is in the consensus set, its uptime and voting history are tracked to ensure sufficient liveness. Two proof-of-stake parameters are used to determine if a validator will be jailed for liveness: 59 | 60 | - `liveness_window_check` 61 | - `liveness_threshold` 62 | 63 | Namada liveness requires that a consensus validator vote on at least a `liveness_threshold` fraction of the last `liveness_window_check` blocks. If at any point this fraction dips below the `liveness_threshold`, then the validator will be jailed. 64 | 65 | The values of these parameters can be queried with the command: 66 | 67 | ```bash copy 68 | namadac query-protocol-parameters 69 | ``` 70 | 71 | Since jailing for downtime occurs without the presence of slashes (they are not *frozen*), the jailed validator can unjail themselves as soon as they become jailed. -------------------------------------------------------------------------------- /packages/docs/pages/operators/validators/proof-of-stake.mdx: -------------------------------------------------------------------------------- 1 | # Cubic Proof-of-Stake system 2 | 3 | The Namada Proof of Stake (PoS) system uses the NAM token as the staking token. It features delegation to any number of validators and customizable validator validity predicates. 4 | 5 | ## PoS Validity Predicate 6 | 7 | The PoS system is implemented as an account with the [PoS Validity Predicate](https://github.com/anoma/namada/blob/main/shared/src/ledger/pos/vp.rs) that governs the rules of the system. You can find its address in your wallet: 8 | 9 | ```shell copy 10 | namada wallet find --alias PoS 11 | ``` 12 | 13 | ## Epochs 14 | 15 | The system relies on the concept of epochs. An epoch is a range of consecutive blocks identified by consecutive natural numbers. Each epoch lasts a minimum duration and includes a minimum number of blocks since the beginning of the last epoch. These are defined by protocol parameters. 16 | 17 | To query the current epoch, the following command can be run: 18 | 19 | ```shell copy 20 | namadac query-protocol-parameters 21 | ``` 22 | 23 | In order to query the current epoch, the following command can be run: 24 | 25 | ```shell copy 26 | namada client epoch 27 | ``` 28 | 29 | ## Slashing 30 | 31 | Validators on Namada are slashed for misbehavior. Automatic slashing conditions are defined by the CometBFT, but validators can also report misbehavior by other validators. If a validator is deemed to have misbehaved, they are slashed by a certain amount of their stake. The amount of stake slashed, as well as the time required for the slash to take effect (pipeline) is defined by protocol parameters. 32 | 33 | ## Jailing 34 | 35 | Validators on Namada are jailed for either misbehavior or for being offline for too long. If a number of blocks pass (also defined in the protocol parameters under `liveness_window_check`) in which none have been signed by the validator in question, the validator is jailed. 36 | 37 | When a validator is jailed, they are unable to participate in the consensus protocol. A validator is jailed for at least the pipeline amount of epochs, but must be unjailed manually by the validator. This is done by submitting an `unjail-validator` command. 38 | 39 | ```bash 40 | VALIDATOR_ALIAS="" 41 | SIGNING_KEYS="" 42 | namada client unjail-validator --validator $VALIDATOR_ALIAS --signing-keys $SIGNING_KEYS 43 | ``` 44 | 45 | If successful, the validator will be unjailed after the pipeline amount of epochs, and is able to participate in the consensus protocol again. 46 | -------------------------------------------------------------------------------- /packages/docs/pages/users.mdx: -------------------------------------------------------------------------------- 1 | # User Guide 2 | 3 | This guide is tailored towards users who are interested in using Namada to its maximum potential. This guide will include both the most basic operations that a user can execute, as well as the more advanced features that a user can access. 4 | 5 | ## Table of contents 6 | 7 | - [Transparent Accounts](./users/transparent-accounts.mdx) 8 | - [The MASP](./users/shielded-accounts.mdx) 9 | - [Fees on Namada](./users/fees.mdx) 10 | - [Delegating on Namada](./users/delegators.mdx) 11 | - [Governance and Public Goods Funding](./users/governance.mdx) 12 | - [Using the Namada wallet](./users/wallet.mdx) 13 | 14 | -------------------------------------------------------------------------------- /packages/docs/pages/users/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "wallet": "Using the Namada wallet", 3 | "transparent-accounts": "Transparent accounts", 4 | "shielded-accounts": "The MASP", 5 | "fees": "Fees on Namada", 6 | "delegators": "Bonding and Proof-of-stake", 7 | "governance": "Governance and Public Goods Funding", 8 | "public-goods-stewards": "PGF", 9 | "ibc": "IBC transfers" 10 | } -------------------------------------------------------------------------------- /packages/docs/pages/users/governance.mdx: -------------------------------------------------------------------------------- 1 | # Governance 2 | 3 | The Namada governance mechanism gives users the possibility to upgrade the protocol dynamically. 4 | 5 | There are two different mechanism to create a proposal: 6 | 7 | - [On-chain proposals](./governance/on-chain-governance.mdx): Proposal is voted on and tallied on-chain. This can optionally include proposal code to be executed if the proposal is accepted. 8 | - [Off-chain proposals](./governance/off-chain-governance.mdx) 9 | -------------------------------------------------------------------------------- /packages/docs/pages/users/governance/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "on-chain-governance": "On-chain proposals", 3 | "off-chain-governance": "Off-chain proposals" 4 | } 5 | -------------------------------------------------------------------------------- /packages/docs/pages/users/governance/off-chain-governance.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | # Off-chain proposals 4 | 5 | If for any reason issuing an on-chain proposal is not adequate to your needs, you still have the option to create an off-chain proposal. An off-chain proposal is intended for proposals that do not require any on-chain code execution. The proposal would be distributed on some third-party channel (e.g., a forum) and the voting would be done off-chain. The result of the voting would be computed off-chain and then submitted to the ledger. 6 | 7 | ## Create proposal 8 | 9 | ### The proposal file 10 | 11 | For offline proposals, the structure of the `proposal.json` file is as follows: 12 | 13 | ```json 14 | "content": { 15 | "title": "", 16 | "authors": "<email>", 17 | "discussions-to": "<forum-link>", 18 | "created": "<Timestamp in format YYYY-MM-DDTHH:MM:SSZ>", 19 | "license": "<Licences>", 20 | "abstract": "<Abstract>", 21 | "motivation": "<Motivation>", 22 | "details": "<Details>", 23 | "requires": "<preceding-proposal-id-that-must-pass>", 24 | }, 25 | "author": "<author-address>", 26 | "tally_epoch": 1337, 27 | ``` 28 | 29 | <Callout type="info"> 30 | The `tally_epoch` is the block height at which the tally was computed. This is any integer before the current epoch. Since the tallying should occur before it is submitted. 31 | </Callout> 32 | 33 | ```shell copy 34 | namada client init-proposal \ 35 | --data-path proposal.json \ 36 | --signing-keys your-signing-keys-for-author \ 37 | --offline 38 | ``` 39 | 40 | This command will create a `proposal` file same directory where the command was launched. 41 | 42 | <Callout type="info"> 43 | If you would like the proposal to be created in a different directory, you can use the `--output-folder-path` flag to specify the directory. The directory must already exist, however. 44 | It is also essential that you provide the `--signing-keys` argument to sign the proposal. As of `v0.31.2`, the `--signing-keys` is optional but it is not possible to sign the proposal after it has been created. 45 | </Callout> 46 | 47 | ## Vote on proposal 48 | 49 | To vote on an offline proposal use the following command: 50 | 51 | ```shell copy 52 | namada client vote-proposal --data-path proposal \ 53 | --vote yay \ 54 | --signing-keys your-signing-keys-for-voter \ 55 | --address your-established-account \ 56 | --offline 57 | ``` 58 | 59 | ## Tally off-chain proposal 60 | 61 | To compute the tally for an offline proposal we need to collect 62 | 63 | - `proposal` file (must have this name) 64 | - all the `proposal-vote-${address}` files 65 | 66 | All those files will have to be in a folder (lets call it `offline-proposal`). 67 | 68 | Now you can use the following command: 69 | 70 | ```shell copy 71 | namada client query-proposal-result \ 72 | --offline \ 73 | --data-path `offline-proposal` 74 | ``` 75 | 76 | which will tell you the proposal result. 77 | 78 | ## Submit off-chain proposal 79 | <Callout type="info"> 80 | The community may decide to post data of their off-chain voting to another censorship resistant blockchain to preserve the decision reached by social consensus. 81 | </Callout> -------------------------------------------------------------------------------- /packages/docs/pages/users/public-goods-stewards.mdx: -------------------------------------------------------------------------------- 1 | # Public Goods Stewards Documentation 2 | The funding of public goods on Namada is conducted through an entity called the "public goods stewards". Each public goods steward is a [multisignature account](./transparent-accounts/multisignature.mdx). 3 | 4 | Each steward is elected by governance through separate governance proposals. 5 | 6 | See the specs about the public goods funding [here](https://specs.namada.net/modules/governance/public-goods-funding.html) for more details. 7 | 8 | This documentation will cover: 9 | 10 | 1. [How to become a public goods steward](./public-goods-stewards/electing.mdx). 11 | 2. [How to submit a public goods funding proposal](./public-goods-stewards/proposing.mdx) 12 | 3. [How to vote on steward elections](./public-goods-stewards/voting.mdx#voting-for-stewards) as well as [public goods funding proposals](./public-goods-stewards/voting.mdx#voting-for-pgf-proposals). -------------------------------------------------------------------------------- /packages/docs/pages/users/public-goods-stewards/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "electing": "Becoming a Steward", 3 | "voting": "Voting for Stewards and PGF proposals", 4 | "proposing": "PGF proposals" 5 | } 6 | -------------------------------------------------------------------------------- /packages/docs/pages/users/public-goods-stewards/proposing.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | # Proposing funding 4 | 5 | ## Formatting the `proposal.json` 6 | 7 | Below is an example of a `PGFProposal` that a governance participant could submit. 8 | ```json 9 | { 10 | "proposal": { 11 | "id": 1, 12 | "content": { 13 | "title": "Stewie for Steward 2024", 14 | "authors": "stewie@heliax.dev", 15 | "discussions-to": "forum.namada.net/t/stewies-manifesto/1", 16 | "created": "2024-01-01T00:00:01Z", 17 | "license": "MIT", 18 | "abstract": "Stewie is running for steward, with a focus on technical research. The technical research I will be focused on will definitely not be for weapons of mass destruction. There is some possibility however that I may be focusing somewhat on open source software for weapons of mass destruction.", 19 | "motivation": "Nobody knows technical research better than me. Trust me. I know it. I have the best technical research. I will be the best steward. Last night, Namada called me and said, Stewie, thank you. I will make public goods funding great again", 20 | "details": "As a genius baby, I possess an unmatched level of intelligence and a visionary mindset. I will utilize these qualities to solve the most complex problems, and direct public goods funding towards weapons of mass destruction ... i mean open source software for weapons of mass destruction" 21 | }, 22 | "author": "stewie", 23 | "voting_start_epoch": 3, 24 | "voting_end_epoch": 6, 25 | "grace_epoch": 12 26 | }, 27 | "data": { 28 | "continuous": [ 29 | { 30 | "target": { 31 | "amount": 420, 32 | "address": "<address-of-recipient>" 33 | }, 34 | "action": "add" 35 | } 36 | ], 37 | "retro": [ 38 | { 39 | "target": { 40 | "amount": 1337, 41 | "address": "<address-of-recipient>" 42 | } 43 | } 44 | ] 45 | } 46 | } 47 | ``` 48 | where `<address-of-recipient>` should be changed to the address of the recipient of the funds. 49 | 50 | Save this file as `PGF_proposal.json` to some memorable path on your machine. 51 | 52 | ## Submitting the proposal 53 | 54 | In order to submit the proposal, the governance participant can use the following command: 55 | 56 | ```shell copy 57 | namada client init-proposal \ 58 | --pgf-proposal \ 59 | --data-path PGF_proposal.json 60 | ``` 61 | 62 | The proposal will then be given a `proposal-id` which can be used to query the proposal. 63 | 64 | ## Querying the proposal 65 | 66 | The command for querying the proposal is as follows: 67 | 68 | ```shell copy 69 | namada client query-proposal \ 70 | --proposal-id <the-proposal-id> 71 | ``` 72 | -------------------------------------------------------------------------------- /packages/docs/pages/users/public-goods-stewards/voting.mdx: -------------------------------------------------------------------------------- 1 | # Voting for stewards and PGF proposals 2 | 3 | ## Voting for stewards 4 | 5 | Any user is allowed (and encouraged) to vote for potential PGF stewards. Once the steward has submitted their proposal to the ledger, the community can vote on it. The voting process is the same as for any other proposal, but the proposal type is `StewardProposal`. 6 | 7 | The CLI command for voting for a steward is: 8 | 9 | ```shell copy 10 | namada client vote-proposal \ 11 | --proposal-id <proposal-id-of-steward-proposal> \ 12 | --vote yay \ 13 | --signing-keys <your-alias> 14 | ``` 15 | 16 | In order to vote against the proposal, replace `yay` with `nay`. 17 | 18 | ## Voting for PGF proposals 19 | 20 | Similarly, the command for voting for PGF proposals is: 21 | 22 | ```shell copy 23 | namada client vote-proposal \ 24 | --proposal-id <proposal-id-of-steward-proposal> \ 25 | --vote yay \ 26 | --signing-keys <your-alias> 27 | ``` -------------------------------------------------------------------------------- /packages/docs/pages/users/shielded-accounts.mdx: -------------------------------------------------------------------------------- 1 | # The MASP 2 | 3 | The multi-asset shielded pool (MASP) is a zero knowledge circuit that allows users to make transfers in a way that does not reveal the sender, receiver, or amount. Each transfer is a zero knowledge proof itself, and is often referred to as a "note". From the users perspective, the construction of these zero knowledge proofs occur behind the scenes. 4 | 5 | The MASP is inspired by the work produced by the Electric Coin Company (ECC) who developed Zcash, and builds on the Sapling Circuit by implementing multi-asset functionality. In addition to the MASP, Namada has also implemented a zero knowledge circuit for rewarding privacy set contributions in a shielded manner. This circuit is called the Convert Circuit (CC for short). 6 | 7 | More technical details of these circuits can be found in the [specs](https://specs.namada.net) as well as [this blog post](https://namada.net/blog/understanding-the-masp-and-cc-circuits). 8 | 9 | -------------------------------------------------------------------------------- /packages/docs/pages/users/shielded-accounts/shielded-rewards.mdx: -------------------------------------------------------------------------------- 1 | # Shielded Rewards 2 | 3 | Shielded rewards are distributed to all users in the shielded set. Users are rewared `NAM` tokens for each epoch their incentivised assets are in the shielded set. Informally, the amount of `NAM` rewarded for a specific asset is proportional to the amount of that asset in the shielded pool. Each asset has a "reward rate" specified by governance, which sets the constant of proportionality for that asset. 4 | 5 | The interested reader should consult [the specs](https://specs.namada.net/modules/proof-of-stake) for a more precise explanation of how the reward is calculated. -------------------------------------------------------------------------------- /packages/docs/pages/users/transparent-accounts/send-and-receive-nam-tokens.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | # Send and Receive NAM tokens 4 | 5 | In Namada, tokens are implemented as accounts with the [Token Validity Predicate](https://github.com/anoma/namada/blob/9b67281e359ebff5467cad57c866fbcf91eb80c8/shared/src/ledger/native_vp/multitoken.rs#L30). 6 | The validity predicate (VP) checks, in particular, that the total supply (of the token) is preserved in any transaction that uses this token. Your wallet will be pre-loaded with some token addresses that are initialized in the genesis block. 7 | 8 | ### Initialize an established account 9 | 10 | If you already have a key in your wallet, you can skip this step. Otherwise, [generate a new keypair](../transparent-accounts.mdx#generate-a-keypair) now. 11 | 12 | Then, send a transaction to initialize your new established account and save its address with the alias `establishment`. The `keysha` public key will be written into the account's storage for authorizing future transactions. We also sign this transaction with `keysha`. 13 | 14 | <Callout type="info" emoji="🤡"> 15 | Note the use of the placeholder `keysha` for the key parameter. This is a completely configurable parameter, and should just refer to the alias of the key signing the transaction (that has a positive nam balance). 16 | </Callout> 17 | 18 | ```shell copy 19 | namada client init-account \ 20 | --alias establishment \ 21 | --public-keys keysha \ 22 | --signing-keys keysha \ 23 | --threshold 1 24 | ``` 25 | 26 | Once this transaction has been applied, the client will automatically see the new address created by the transaction and add it to your wallet with the chosen alias `establishment`. 27 | 28 | This command uses the prebuilt [User Validity Predicate](https://github.com/anoma/namada/blob/main/wasm/wasm_source/src/vp_user.rs). 29 | 30 | ### Send a Payment 31 | 32 | To submit a regular token transfer from your account to the `validator-1` address: 33 | 34 | ```shell copy 35 | namada client transfer \ 36 | --source establishment \ 37 | --target validator-1 \ 38 | --token NAM \ 39 | --amount 10 \ 40 | --signing-keys keysha 41 | ``` 42 | 43 | This command will attempt to find and use the key of the source address to sign the transaction. 44 | 45 | ### See your balance 46 | 47 | To query token balances for a specific token and/or owner: 48 | 49 | ```shell copy 50 | namada client balance --token NAM --owner my-new-acc 51 | ``` 52 | 53 | <Callout type="info"> 54 | For any client command that submits a transaction (`init-account`, `transfer`, `tx`, `update` and [PoS transactions](../../operators/validators/proof-of-stake.mdx)), 55 | you can use the `--dry-run-wrapper` flag to simulate the transaction being applied in the block and see what would be the result. 56 | </Callout> 57 | 58 | ### See every known addresses' balance 59 | 60 | You can see the token's addresses known by the client when you query all tokens balances: 61 | 62 | ```shell copy 63 | namada client balance 64 | ``` 65 | -------------------------------------------------------------------------------- /packages/docs/pages/users/wallet.mdx: -------------------------------------------------------------------------------- 1 | # Namada Wallet Guide 2 | 3 | This document describes the different wallet concepts and options that are available to users of Namada who want to be able to [send, receive and interact](./transparent-accounts/send-and-receive-nam-tokens.mdx) with NAM tokens on the Namada blockchain. 4 | 5 | ## A brief introduction to the Namada wallet 6 | The purpose of the Namada wallet is to provide a user-interface to store and manage both keys and addresses. 7 | [Technically speaking](https://vitalik.ca/general/2017/01/14/exploring_ecp.html), keys are just (potentially) very large integers that have some meaning on an elliptic curve. 8 | The wallet simply "remembers" these very large numbers on your behalf. Keys are the fundamental building blocks for accounts on Namada. 9 | Keys come in the form of *pairs* (of secret and public key), and can be used to derive the **account address** (first 40 chars of the SHA256 hash of the public key). 10 | 11 | To read more about addresses see [An introduction to Namada addresses](./transparent-accounts.mdx). 12 | 13 | ## The wallet options on Namada 14 | 15 | Check out the different options to generate a wallet: 16 | 17 | - [File System Wallet](./wallet/file-system-wallet.mdx) 18 | - [Web Wallet](./wallet/web-wallet.mdx) 19 | - [Hardware Wallet](./wallet/hardware-wallet.mdx) 20 | -------------------------------------------------------------------------------- /packages/docs/pages/users/wallet/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "file-system-wallet": "File system wallet", 3 | "web-wallet": "Web wallet", 4 | "hardware-wallet": "Hardware wallet" 5 | } 6 | -------------------------------------------------------------------------------- /packages/docs/pages/users/wallet/file-system-wallet.mdx: -------------------------------------------------------------------------------- 1 | ## File System Wallet 2 | 3 | By default, the Namada Wallet is stored under `.namada/{chain_id}/wallet.toml` where keys are stored encrypted. You can change the default base directory path with `--base-dir` and you can allow the storage of unencrypted keypairs with the flag `--unsafe-dont-encrypt`. 4 | 5 | If the wallet doesn't already exist, it will be created for you as soon as you run a command that tries to access the wallet. A newly created wallet will be pre-loaded with some internal addresses like `pos`, `pos_slash_pool`, `masp` and more. 6 | 7 | Currently, the Namada client can load the password via: 8 | 9 | - **Stdin:** the client will prompt for a password. 10 | - **Env variable:** by exporting a ENV variable called `NAMADA_WALLET_PASSWORD` with a value of the actual password. 11 | - **File:** by exporting an ENV variable called `NAMADA_WALLET_PASSWORD_FILE` with a value containing the path to a file containing the password. -------------------------------------------------------------------------------- /packages/docs/pages/users/wallet/hardware-wallet.mdx: -------------------------------------------------------------------------------- 1 | ## Hardware Wallet 2 | 3 | Namada's web wallet extension is compatible with the [Ledger](https://www.ledger.com/) hardware. This guide will walk you through the process of setting up your Ledger device to work with Namada. 4 | 5 | ### Prerequisites 6 | A ledger device with the latest firmware installed. You can find instructions on how to update your firmware [here](https://support.ledger.com/hc/en-us/articles/360002731113-Update-device-firmware). 7 | 8 | Install the javascript npm package [here](https://www.npmjs.com/package/@zondax/ledger-namada). 9 | 10 | In order to use the ledger with the web wallet, you will need to install the [Namada Web Wallet](./web-wallet.mdx#install). 11 | 12 | ### Connecting your Ledger 13 | 1. Open the Namada web extension. 14 | 2. Under settings, click on the `Connect Ledger` button. 15 | 3. Set an alias for the account that ledger will control the keys for. 16 | 4. You can choose to connect to the ledger via `USB` (recommended) or `HID` (Human Interface Devices). 17 | 5. The ledger will ask you to confirm the connection. Confirm this connection on your ledger device. 18 | 6. Once completed, the extension will show the address of the account that the ledger is controlling the keys for. 19 | 7. You can now close the information window and use the ledger to sign transactions. 20 | 21 | ### Sending transactions with the ledger 22 | See the [web wallet](./web-wallet.mdx#sending-transactions) guide for instructions on how to send transactions with the web wallet. 23 | -------------------------------------------------------------------------------- /packages/docs/pages/users/wallet/web-wallet.mdx: -------------------------------------------------------------------------------- 1 | # Web Wallet 2 | 3 | ## Install 4 | When Namada is in [`mainnet`](../../networks/mainnets.mdx), the web wallet will be available in most browser extension web stores. For now, the user can install it from source by following the instructions below. 5 | 6 | ### Installing from source (for development and experiment purposes) 7 | 8 | #### Connect to a testnet or run a local node 9 | 1. Follow the instructions for the [testnets](../../networks/testnets.mdx) to connect to a testnet or [set up a local node](../../operators/networks/local-network.mdx). 10 | 2. Figure out where the base directory is stored and save its location as a variable such as `export BASE_DIR=<path/to/base/dir>`. 11 | You can follow [these docs](../../networks/testnets/migrating-testnets.mdx) to save this variable. Go ahead and save the chain id as a variable as well. You can find the chain id by running `cat $BASE_DIR/global-config.toml`. Save this chain-id to the variable `export CHAIN_ID=<CHAIN_ID>`. 12 | 3. You will need to edit the CometBFT config in order to allow the web wallet to connect to your node. 13 | The CometBFT config will be located in `$BASE_DIR/$CHAIN_ID/cometbft/config/config.toml`. You will need to change the `cors_allowed_origins` field to `["*"]`. You can do this by running 14 | ```shell copy 15 | sed -i 's/cors_allowed_origins = \[\]/cors_allowed_origins = ["*"]/' \ 16 | $BASE_DIR/$CHAIN_ID/cometbft/config/config.toml 17 | ``` 18 | 19 | #### Setting up the extension 20 | 1. Clone the [namada-interface repository](https://github.com/anoma/namada-interface). 21 | 2. Follow the installation instructions in `README.md`. 22 | 3. `cd` into the `namada-interface/apps/extension` directory and run `yarn start:chrome`. This will build the extension and place it in the `namada-interface/apps/extension/build` directory. It also starts the dev server which will watch for changes. 23 | 4. `cd` into the `namada-interface/apps/namada-interface` directory and run `yarn dev:local` in order to launch a local instance of the web wallet. 24 | 4. Add the extension to the browser. For example, in Chrome, you can go to `chrome://extensions/` and click `Load unpacked` and select the `namada-interface/apps/extension/build/chrome/` folder. 25 | 26 | ## Receiving tokens 27 | You can show the address of any account by pressing the `Receive` button in the initial view under the "Total Balances" tab. You can copy the address by clicking the copy icon next to the address. 28 | This will also display a QR code that can be scanned by a mobile wallet. 29 | 30 | ## Sending Transactions 31 | 32 | In order to send transactions, you can press the `Send` button in the initial view under the "Total Balances" tab. This will open a modal that will allow you to send tokens to any account, from any account in your wallet that has a positive balance. 33 | -------------------------------------------------------------------------------- /packages/docs/public/favicon-16x16.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/docs/public/favicon-16x16.png -------------------------------------------------------------------------------- /packages/docs/public/favicon-32x32.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/docs/public/favicon-32x32.png -------------------------------------------------------------------------------- /packages/docs/public/favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/docs/public/favicon.ico -------------------------------------------------------------------------------- /packages/docs/public/images/Download_Tendermint_Binaries.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/docs/public/images/Download_Tendermint_Binaries.png -------------------------------------------------------------------------------- /packages/docs/public/images/NamadaBannerImage.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/docs/public/images/NamadaBannerImage.png -------------------------------------------------------------------------------- /packages/docs/public/images/Namada_Full_RGB_Yellow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/docs/public/images/Namada_Full_RGB_Yellow.png -------------------------------------------------------------------------------- /packages/docs/public/images/namada-logo.svg: -------------------------------------------------------------------------------- 1 | <?xml version="1.0" encoding="UTF-8"?><svg id="Layer_1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 750.95 208.95"><rect x="689.45" y="0" width="61.5" height="208.95"/><rect x="609.52" y="0" width="61.5" height="208.95"/><rect x="529.03" y="0" width="61.5" height="208.95"/><g><polygon points="476.85 208.89 409.81 208.89 409.81 70.14 332.35 70.14 332.35 208.89 265.32 208.89 265.32 0 476.85 0 476.85 208.89"/><circle cx="371.08" cy="111.51" r="28.77"/></g><polygon points="211.53 208.89 144.5 208.89 144.5 70.14 67.04 70.14 67.04 208.89 0 208.89 0 0 211.53 0 211.53 208.89"/></svg> -------------------------------------------------------------------------------- /packages/docs/public/images/namada_docs_ascii_dark.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/docs/public/images/namada_docs_ascii_dark.png -------------------------------------------------------------------------------- /packages/docs/public/images/namada_docs_ascii_light.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/docs/public/images/namada_docs_ascii_light.png -------------------------------------------------------------------------------- /packages/docs/public/images/scripts/testnet_flowchart.dot: -------------------------------------------------------------------------------- 1 | digraph Flowchart { 2 | rankdir=UD; 3 | node [shape=box]; 4 | A [label="Do you want to join a testnet"]; 5 | B [label="Nothing to do!"]; 6 | C [label="See Environment Setup"]; 7 | D [label="Do you want to join the testnet as a genesis validator?"]; 8 | E [label="See Applying as a Genesis Validator"]; 9 | F [label="Wait for the CHAIN_ID to be announced"]; 10 | G [label="Are you a genesis validator?"]; 11 | H [label="Do you want to reset the ledger state?"]; 12 | I [label="See running a full node"]; 13 | J [label="See migrating testnets"]; 14 | K [label="See running a genesis validator"]; 15 | A -> B [label="NO"]; 16 | A -> C [label="YES"]; 17 | C -> D; 18 | D -> E [label="YES"]; 19 | D -> F [label="NO"]; 20 | E -> F; 21 | F -> G [label="CHAIN_ID ANNOUNCED!"]; 22 | G -> H [label="YES"]; 23 | G -> I [label="NO"]; 24 | H -> J [label="YES"]; 25 | H -> K [label="NO"]; 26 | J -> K; 27 | } -------------------------------------------------------------------------------- /packages/docs/public/images/scripts/testnet_flowchart.sh: -------------------------------------------------------------------------------- 1 | # This script allows you to create a flowchart for the testnet instructions, assuming you have 2 | # graphviz installed. It will create a file called testnet_flowchart.png in the current directory. 3 | 4 | dot -Tpng -Gdpi=300 -Gsize="12,8" -o ../testnet_flowchart.png ./testnet_flowchart.dot -------------------------------------------------------------------------------- /packages/docs/public/images/testnet_flowchart.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/docs/public/images/testnet_flowchart.png -------------------------------------------------------------------------------- /packages/docs/public/opengraph.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/docs/public/opengraph.jpg -------------------------------------------------------------------------------- /packages/docs/theme.config.tsx: -------------------------------------------------------------------------------- 1 | import React from "react"; 2 | import { Logo } from "./components/Logo"; 3 | import { DocsThemeConfig } from "nextra-theme-docs"; 4 | import { PageHead } from "./components/PageHead"; 5 | 6 | const description = `Documentation for Namada, a Proof-of-Stake L1 for interchain asset-agnostic privacy.`; 7 | 8 | const config: DocsThemeConfig = { 9 | primaryHue: 180, 10 | useNextSeoProps() { 11 | return { 12 | titleTemplate: "Namada Documentation - %s", 13 | description, 14 | defaultDescription: description, 15 | canonical: "https://docs.namada.net", 16 | }; 17 | }, 18 | sidebar: { 19 | defaultMenuCollapseLevel: 1, 20 | }, 21 | head: <PageHead />, 22 | logo: <Logo />, 23 | project: { 24 | link: "https://github.com/anoma/namada", 25 | }, 26 | chat: { 27 | link: "https://discord.gg/namada", 28 | }, 29 | docsRepositoryBase: 30 | "https://github.com/anoma/namada-docs/blob/master/packages/docs", 31 | footer: { 32 | text: "Namada", 33 | }, 34 | navigation: { 35 | prev: true, 36 | next: true 37 | } 38 | }; 39 | 40 | export default config; 41 | -------------------------------------------------------------------------------- /packages/docs/tsconfig.json: -------------------------------------------------------------------------------- 1 | { 2 | "extends": "../../tsconfig.base.json", 3 | "include": ["../../**/*.tsx"] 4 | } 5 | -------------------------------------------------------------------------------- /packages/specs/components/Logo.jsx: -------------------------------------------------------------------------------- 1 | import { useEffect, useState } from "react"; 2 | import { useTheme } from "nextra-theme-docs"; 3 | 4 | export const Logo = () => { 5 | const { resolvedTheme } = useTheme(); 6 | const [isDark, setDark] = useState(false); 7 | 8 | useEffect(() => { 9 | setDark(resolvedTheme === "dark"); 10 | }, [resolvedTheme]); 11 | 12 | const fill = isDark ? "#ffff00" : "currentColor"; 13 | 14 | return ( 15 | <div> 16 | <svg 17 | className="nx-w-full nx-py-4" 18 | style={{ maxWidth: "128px" }} 19 | xmlns="http://www.w3.org/2000/svg" 20 | viewBox="0 0 443.3 153.4" 21 | > 22 | <g id="g148" transform="translate(-87 -48.3)"> 23 | <rect 24 | fill={fill} 25 | id="rect136" 26 | width="28.7" 27 | height="28.7" 28 | x="164.7" 29 | y="125" 30 | /> 31 | <path 32 | fill={fill} 33 | id="path138" 34 | d="M136 96.3a28.7 28.7 0 0 1 28.7 28.7H136z" 35 | /> 36 | <polygon 37 | fill={fill} 38 | id="polygon140" 39 | points="152.6 153.7 136 125 119.4 153.7" 40 | /> 41 | <circle fill={fill} id="circle142" cx="193.5" cy="110.7" r="14.3" /> 42 | <path 43 | fill={fill} 44 | id="path146" 45 | d="M163.6 201.7c-20.5 0-39.7-8-54.2-22.5A76.2 76.2 0 0 1 86.9 125a76 76 0 0 1 22.5-54.2 76.2 76.2 0 0 1 54.2-22.5c20.5 0 39.8 8 54.3 22.5a76.2 76.2 0 0 1 22.4 54.2 76.2 76.2 0 0 1-76.7 76.7zm0-144A66.8 66.8 0 0 0 96.4 125a66.8 66.8 0 0 0 67.2 67.2 66.8 66.8 0 0 0 67.2-67.2 66.8 66.8 0 0 0-67.2-67.2Z" 46 | /> 47 | </g> 48 | <text 49 | id="text152" 50 | x="191" 51 | y="105.4" 52 | fill={fill} 53 | fontFamily='SpaceGrotesk-Medium,"Space Grotesk"' 54 | fontSize="77.8" 55 | fontWeight="500" 56 | > 57 | <tspan id="tspan150" x="191" y="105.4"> 58 | SPECS 59 | </tspan> 60 | </text> 61 | </svg> 62 | </div> 63 | ); 64 | }; 65 | -------------------------------------------------------------------------------- /packages/specs/components/PageHead.tsx: -------------------------------------------------------------------------------- 1 | export const PageHead = () => { 2 | return ( 3 | <> 4 | <meta name="viewport" content="width=device-width, initial-scale=1" /> 5 | <meta 6 | property="og:image" 7 | content="https://specs.namada.net/opengraph.jpg" 8 | /> 9 | <meta name="twitter:card" content="summary_large_image" /> 10 | <meta name="twitter:site" content="@namada" /> 11 | <meta name="twitter:creator" content="@namada" /> 12 | <meta property="og:url" content="https://specs.namada.net" /> 13 | <link rel="icon" type="image/x-icon" href="/favicon.ico" /> 14 | <link 15 | rel="icon" 16 | type="image/png" 17 | sizes="32x32" 18 | href="/favicon-32x32.png" 19 | /> 20 | <link 21 | rel="icon" 22 | type="image/png" 23 | sizes="16x16" 24 | href="/favicon-16x16.png" 25 | /> 26 | </> 27 | ); 28 | }; 29 | -------------------------------------------------------------------------------- /packages/specs/components/SpecsAscii.jsx: -------------------------------------------------------------------------------- 1 | import { useState, useEffect } from 'react'; 2 | import { useTheme } from 'nextra-theme-docs'; 3 | 4 | export const SpecsAscii = () => { 5 | const { resolvedTheme } = useTheme(); 6 | const [isDarkMode, setDark] = useState(resolvedTheme === "dark"); 7 | 8 | useEffect(() => { 9 | setDark(resolvedTheme === "dark"); 10 | }, [resolvedTheme]); 11 | 12 | // Construct the image source paths based on theme mode 13 | const imageSrc = isDarkMode 14 | ? '/images/namada_specs_ascii_dark.png' 15 | : '/images/namada_specs_ascii_light.png'; 16 | 17 | return ( 18 | <div> 19 | {/* Conditional rendering based on theme mode */} 20 | <img src={imageSrc} alt={isDarkMode ? 'Dark Mode' : 'Light Mode'} width={2000} height={200} /> 21 | </div> 22 | ); 23 | }; 24 | -------------------------------------------------------------------------------- /packages/specs/global.css: -------------------------------------------------------------------------------- 1 | @import url("https://fonts.googleapis.com/css2?family=Space+Grotesk:wght@500&display=swap"); 2 | -------------------------------------------------------------------------------- /packages/specs/index.js: -------------------------------------------------------------------------------- 1 | module.exports = "specs"; 2 | -------------------------------------------------------------------------------- /packages/specs/next-env.d.ts: -------------------------------------------------------------------------------- 1 | /// <reference types="next" /> 2 | /// <reference types="next/image-types/global" /> 3 | 4 | // NOTE: This file should not be edited 5 | // see https://nextjs.org/docs/basic-features/typescript for more information. 6 | -------------------------------------------------------------------------------- /packages/specs/next.config.js: -------------------------------------------------------------------------------- 1 | const withNextra = require("nextra")({ 2 | theme: "nextra-theme-docs", 3 | themeConfig: "./theme.config.tsx", 4 | latex: true, 5 | defaultShowCopyCode: true, 6 | }); 7 | 8 | module.exports = { 9 | ...withNextra(), 10 | images: { 11 | unoptimized: true, 12 | }, 13 | }; 14 | -------------------------------------------------------------------------------- /packages/specs/package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "namada-specs", 3 | "version": "0.0.1", 4 | "description": "Namada Docs", 5 | "license": "GPL-3.0", 6 | "scripts": { 7 | "dev": "next dev", 8 | "build": "next build && next export", 9 | "start": "next start" 10 | }, 11 | "dependencies": { 12 | "next": "^13.4.8", 13 | "nextra": "latest", 14 | "nextra-theme-docs": "latest", 15 | "react": "^18.2.0", 16 | "react-dom": "^18.2.0" 17 | }, 18 | "devDependencies": { 19 | "@types/node": "18.11.10", 20 | "typescript": "^4.9.3" 21 | } 22 | } 23 | -------------------------------------------------------------------------------- /packages/specs/pages/_app.mdx: -------------------------------------------------------------------------------- 1 | import "../global.css"; 2 | 3 | export default function Specs({ Component, pageProps }) { 4 | return <Component {...pageProps} />; 5 | } 6 | -------------------------------------------------------------------------------- /packages/specs/pages/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "index": "Introduction", 3 | "base-ledger": "Base ledger", 4 | "modules": "Modules", 5 | "further-reading": "Further reading" 6 | } 7 | -------------------------------------------------------------------------------- /packages/specs/pages/base-ledger.mdx: -------------------------------------------------------------------------------- 1 | # Base ledger 2 | 3 | The base ledger of Namada includes: 4 | - a [consensus mechanism](./base-ledger/consensus.mdx), which provides an algorithmic way for validators to communicate votes and collectively agree on a single, consistent state in a Byzantine-fault-tolerant manner; 5 | - a validity-predicate-based [execution model](./base-ledger/execution.mdx) where a "valid state" is defined as that which satisfies a set of boolean conditions; 6 | - a [replay protection system](./base-ledger/replay-protection.mdx) which prevents transactions from being executed multiple times; 7 | - a [block space allocator](./base-ledger/block-space-allocator.mdx) which packs transactions into blocks; and 8 | - a [fee system](./base-ledger/fee-system.mdx) which provides for efficient, DoS-resistant allocation of computational and storage resources within blocks -------------------------------------------------------------------------------- /packages/specs/pages/base-ledger/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "consensus": "Consensus", 3 | "execution": "Execution model", 4 | "replay-protection": "Replay protection", 5 | "block-space-allocator": "Block space allocator", 6 | "fee-system": "Fee system" 7 | } 8 | -------------------------------------------------------------------------------- /packages/specs/pages/base-ledger/consensus.mdx: -------------------------------------------------------------------------------- 1 | # Consensus 2 | 3 | Namada uses [CometBFT](https://github.com/cometbft/cometbft/) (nee Tendermint Go) through the [cometbft-rs](https://github.com/heliaxdev/tendermint-rs) (nee tendermint-rs) bindings in order to provide peer-to-peer transaction gossip, Byzantine fault tolerant (BFT) consensus, and state machine replication for Namada's custom state machine. CometBFT implements the Tendermint consensus algorithm, which you can read more about [here](https://arxiv.org/abs/1807.04938). 4 | 5 | ## The benefits of using CometBFT 6 | 7 | CometBFT, coupled with a cryptoeconomic voting power allocation mechanism called "proof of stake", is designed so that that non-colluding validators acting in their (economic) self interest will follow the consensus algorithm in a predictable manner. 8 | 9 | Using the CometBFT consensus algorithm comes with a number of benefits including: 10 | 11 | - Fast finality 12 | - CometBFT achieves fast and deterministic finality, meaning that once a block is committed to the blockchain, it is irreversible. This is crucial for applications which rely on settled transactions that cannot be rolled back, and enables efficient, low-latency interoperability. 13 | - Inter-blockchain communication system (IBC) 14 | - Interoperability with all other IBC-supporting chains, such as [Osmosis](https://osmosis.zone), the [Cosmos Hub](https://cosmos.network), and [Noble](https://nobleassets.xyz/). 15 | - Battle tested 16 | - The entire Cosmos ecosystem has been using CometBFT (nee Tendermint) for years. 17 | - Customisable 18 | - Allows the configuration of various parameters, including the ability to implement a custom proof of stake algorithm (as Namada does). -------------------------------------------------------------------------------- /packages/specs/pages/base-ledger/replay-protection/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "optimizations": "Possible optimizations" 3 | } -------------------------------------------------------------------------------- /packages/specs/pages/further-reading.mdx: -------------------------------------------------------------------------------- 1 | ## Further reading 2 | 3 | Thanks for reading! You can find further information about the project below: 4 | 5 | - [Namada website](https://namada.net) 6 | - [Namada source code](https://github.com/anoma/namada) 7 | - [Namada community links](https://namada.net/community/docs) 8 | - [Namada blog](https://blog.namada.net) 9 | - [Namada docs](https://docs.namada.net/) 10 | - [Namada Twitter](https://twitter.com/namada) -------------------------------------------------------------------------------- /packages/specs/pages/index.mdx: -------------------------------------------------------------------------------- 1 | import { SpecsAscii } from '../components/SpecsAscii' 2 | 3 | # Namada 4 | 5 | <br /> 6 | <SpecsAscii/> 7 | 8 | ## What is Namada? 9 | 10 | Namada is a sovereign proof-of-stake layer-one blockchain, using the [CometBFT](https://cometbft.com/) (nee Tendermint) BFT consensus algorithm. Namada enables multi-asset private transfers for any native or non-native asset using a [multi-asset shielded pool](https://research.metastate.dev/multi-asset_shielded_pool/) derived from the [Sapling circuit](https://z.cash/upgrade/sapling/). 11 | 12 | Namada features full IBC protocol support, a natively integrated [Ethereum bridge](./modules/ethereum-bridge.mdx), a modern [proof-of-stake system](./modules/proof-of-stake.mdx) with cubic slashing, a [stake-weighted governance signalling mechanism](./modules/governance.mdx), and a dual continuous/retroactive [public goods funding system](./modules/governance/public-goods-funding.mdx). 13 | 14 | Users of the MASP are [rewarded](./modules/masp/shielded-pool-incentives.mdx) for their contributions to the privacy set in the form of native protocol tokens (NAM). 15 | 16 | Namada also supports shielded actions, which allow users to hold their assets privately on Namada most of the time while occasionally unshielding specific assets in order to interact with existing applications on transparent chains. 17 | 18 | You can find an introduction to Namada from a product perspective [here](https://blog.namada.net/introducing-namada-interchain-asset-agnostic-privacy/). 19 | 20 | ### What is Anoma? 21 | 22 | Anoma is an intent-centric, privacy-preserving architecture for decentralized counterparty discovery, solving, and settlement. You can find the Anoma specs [here](https://specs.anoma.net). 23 | 24 | ### How does Namada relate to Anoma? 25 | 26 | Anoma is a full-stack architecture designed with a long term perspective, while Namada is a specific chain and featureset designed to provide practical privacy now. 27 | 28 | ### Why Namada? 29 | 30 | Privacy should be default and inherent in the systems we use for transacting, yet safe and user-friendly multi-asset privacy doesn't yet exist in the blockchain ecosystem. 31 | Up until now, users have had the choice of either a sovereign chain that reissues assets (e.g. [Zcash](https://z.cash/)) 32 | or a privacy preserving solution built on an existing smart contract chain. Both have large trade-offs: in the former case, users don't have assets that they actually want to transact with, and in the latter case, the restrictions of existing platforms mean that users leak non-trivial metadata, and the protocols may be expensive and clunky to use. 33 | 34 | Namada supports any fungible or non-fungible asset on an IBC-compatible blockchain 35 | as well as fungible or non-fungible assets sent over a custom Ethereum bridge (such as ERC20 tokens and ERC721 tokens, respectively). Once assets are on Namada, shielded transfers are cheap and all assets contribute to the same anonymity set. 36 | 37 | Users of Namada earn rewards, retain privacy of assets, and contribute to shared privacy. 38 | 39 | ### Layout of this specification 40 | 41 | These documents describe the behavior of the Namada protocol. This description is organized into five sub-sections: 42 | 43 | 1. [Base Ledger](./base-ledger.mdx): This section describes the core ledger functionality of the Namada protocol. This includes the consensus, execution model, fee system, and environment in which modules operate. 44 | 2. [Modules](./modules.mdx): This section describes the modules that make up the Namada protocol. Each module is a distinct part of the protocol grouping a related set of features that can be understood in isolation from other modules. 45 | 46 | This book is written using [NextraJS](https://nextra.site/). The source can be found in the [Namada Docs repository](https://github.com/anoma/namada-docs/tree/master/packages/specs). 47 | 48 | Contributions to the contents and the structure of this book should be made via [pull requests](https://github.com/anoma/namada-docs/pulls). -------------------------------------------------------------------------------- /packages/specs/pages/modules.mdx: -------------------------------------------------------------------------------- 1 | # Modules 2 | 3 | Namada's features are grouped into _modules_. Each module defines: 4 | - a validity predicate, which controls a storage sub-space in the ledger state; 5 | - a set of data structures and a storage layout, which are used in this storage sub-space; 6 | - a set of transactions, which allow users to take actions that change state in this storage sub-space; and, optionally 7 | - handlers to be run on various block lifecycle events (e.g. during ABCI's `FinalizeBlock` or at the end of each epoch), which can be used to implement periodic, automated state changes (e.g. minting new tokens at the end of an epoch and distributing them to delegators) 8 | 9 | Namada includes the following modules: 10 | 11 | - [Multitoken](./modules/multitoken.mdx) 12 | - [Multisignature](./modules/multisignature.mdx) 13 | - [Proof-of-stake](./modules/proof-of-stake.mdx) 14 | - [Multi-asset-shielded-pool (MASP)](./modules/masp.mdx) 15 | - [Governance](./modules/governance.mdx) 16 | - [IBC](./modules/ibc.mdx) 17 | - [Ethereum bridge](./modules/ethereum-bridge.mdx) -------------------------------------------------------------------------------- /packages/specs/pages/modules/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "multitoken": "Multitoken", 3 | "multisignature": "Multisignature", 4 | "proof-of-stake": "Proof-of-stake", 5 | "masp": "Multi-asset-shielded-pool (MASP)", 6 | "governance": "Governance", 7 | "ethereum-bridge": "Ethereum Bridge", 8 | "ibc": "IBC" 9 | } -------------------------------------------------------------------------------- /packages/specs/pages/modules/ethereum-bridge/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "security": "Security", 3 | "bootstrapping": "Bootstrapping", 4 | "ethereum_events_attestation": "Ethereum events attestation", 5 | "transfers_to_namada": "Transfers to Namada", 6 | "transfers_to_ethereum": "Transfers to Ethereum", 7 | "proofs": "Proofs", 8 | "ethereum_smart_contracts": "Ethereum Smart Contracts" 9 | } 10 | -------------------------------------------------------------------------------- /packages/specs/pages/modules/ethereum-bridge/security.mdx: -------------------------------------------------------------------------------- 1 | # Security 2 | 3 | On Namada, the validators are full nodes of Ethereum and their stake is also 4 | accounting for security of the bridge. If they carry out a forking attack 5 | on Namada to steal locked tokens of Ethereum their stake will be slashed on Namada. 6 | On the Ethereum side, there exists a limit to the amount of assets that can be 7 | locked to limit the damage a forking attack on Namada can do. To make an attack 8 | more cumbersome there also exists a limit on how fast wrapped Ethereum assets can 9 | be redeemed from Namada. This does not add more security, but rather makes the 10 | attack more inconvenient, and allows governance time to react. 11 | -------------------------------------------------------------------------------- /packages/specs/pages/modules/ethereum-bridge/transfers_to_namada.mdx: -------------------------------------------------------------------------------- 1 | # Transferring assets from Ethereum to Namada 2 | 3 | In order to facilitate transferring assets from Ethereum to Namada, there 4 | will be two internal accounts with associated native validity predicates: 5 | 6 | - `#EthBridge` - Controls the `/eth_msgs/` [storage](./ethereum_events_attestation.mdx#storage) 7 | and ledger of balances of minted wrapped Ethereum assets (ERC20 tokens) structured in a 8 | ["multitoken"](../multitoken.mdx#multitoken) hierarchy. 9 | Also contains in escrow Namada tokens which have been sent to Ethereum, 10 | pertaining to pending wNAM transfers. 11 | - `#EthBridgePool` - Holds gas fees to be paid to relayers of transfers to Ethereum, 12 | as well assets (other than wNAM) in escrow, pertaining to pending transfers to 13 | Ethereum. 14 | 15 | ## Wrapped ERC20 16 | 17 | If an ERC20 token is transferred to Namada, once the associated 18 | `TransferToNamada` Ethereum event is included into Namada, validators mint 19 | the appropriate amount to the corresponding multitoken balance key for 20 | the receiver, or release the escrowed native Namada token. 21 | 22 | ```rust 23 | pub struct EthAddress(pub [u8; 20]); 24 | 25 | /// An event transferring some kind of value from Ethereum to Namada 26 | pub struct TransferToNamada { 27 | /// Quantity of ether in the transfer 28 | pub amount: Amount, 29 | /// Address on Ethereum of the asset 30 | pub asset: EthereumAsset, 31 | /// The Namada address receiving wrapped assets on Namada 32 | pub receiver: Address, 33 | } 34 | ``` 35 | 36 | ### Example 37 | 38 | For 10 DAI i.e. ERC20([0x6b175474e89094c44da98b954eedeac495271d0f](https://etherscan.io/token/0x6b175474e89094c44da98b954eedeac495271d0f)) to `atest1v4ehgw36xue5xvf5xvuyzvpjx5un2v3k8qeyvd3cxdqns32p89rrxd6xx9zngvpegccnzs699rdnnt` 39 | ``` 40 | #EthBridge 41 | /ERC20 42 | /0x6b175474e89094c44da98b954eedeac495271d0f 43 | /balance 44 | /atest1v4ehgw36xue5xvf5xvuyzvpjx5un2v3k8qeyvd3cxdqns32p89rrxd6xx9zngvpegccnzs699rdnnt 45 | += 10 46 | ``` 47 | 48 | ## Namada tokens 49 | 50 | Any wrapped Namada tokens being redeemed from Ethereum must have an 51 | equivalent amount of the native token held in escrow by `#EthBridge`. 52 | Once the associated`TransferToNamada` Ethereum event is included into 53 | Namada, validators should simply make a transfer from `#EthBridge` to 54 | the `receiver` for the appropriate amount and asset. 55 | 56 | ## Replay protection 57 | 58 | Transfer to Namada events are processed in order of their nonce, which 59 | is assumed to be a monotonically growing sequence number. While not 60 | strictly necessary, since these operations only increment the balance 61 | of some token owner in storage, and addition is governed by the 62 | commutative property, it is still important to process these events in 63 | order, such that Namada can discard older events, and not replay balance 64 | updates. 65 | -------------------------------------------------------------------------------- /packages/specs/pages/modules/governance.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | # Governance 4 | 5 | ## Definitions 6 | 7 | Before describing Namada governance, it is useful to define the concepts of NAM, validators, delegators, and delegates. 8 | 9 | *Cryptoeconomic terminology* 10 | 11 | > Namada's economic model is based around a single native token, **NAM**, which is controlled by the protocol. 12 | 13 | *Consensus terminology* 14 | 15 | > A Namada **validator** is an account with a public consensus key, which may participate in producing blocks and governance activities. A validator may not also be a **delegator** (although, of course, a user can control both validator and delegator keys). 16 | 17 | #### Delegation in terms of ***consensus***: 18 | 19 | Non-validator addresses on Namada are able to bond their tokens. When doing so, they specify a validator which is now responsible for voting on blocks on the bonder's behalf. 20 | The validator's voting-power is proportional to the sum of its self-bonded tokens and all the bonded tokens from other addresses to their own address. 21 | 22 | #### Delegation in terms of ***governance***: 23 | 24 | With the above definitions in mind, we define the following terms: 25 | 26 | > A Namada ***delegator*** is an account that delegates some tokens to a _delegate_ for governance voting purposes. 27 | 28 | Any address is either a delegator or a delegate, but not both. 29 | 30 | > A Namada ***delegate*** is an account that has been given the right to vote on the behalf of a delegator. 31 | 32 | A delegate may not also be a delegator. 33 | 34 | When an address bonds tokens, the address is able to specify a *delegate*. 35 | The respective validator of that address becomes the default *delegate* (explained below) of that address. 36 | Similarly, a delegate's `voting-power` (now in terms of voting on governance proposals, not blocks) is proportional to the sum of its self-bonded tokens and all the bonded tokens from other addresses to their own address. 37 | 38 | > **Note**: Initially, Namada only supports validators as delegates. In the future, the ability for separate delegates may be added. 39 | 40 | ## Motivation 41 | 42 | Namada introduces a governance mechanism to propose and apply protocol changes without the need for a hard fork, and to signal stakeholder approval for potential hard forks. 43 | Any user able to deposit the correct amount of `NAM` is able to propose some changes in a proposal for which delegators and validators cast their `yay` or `nay` votes. 44 | It is also possible to attach some payloads to proposals, in specific cases, to embed additional information. 45 | 46 | Governance on Namada supports both `signaling` and `voting` mechanisms. 47 | The signaling mechanism is used for changes which require a hard fork, while the voting mechanism is used for changes which merely alter state. In cases where the chain is not able to produce blocks anymore, Namada relies on [off-chain signaling](#off-chain-protocol) to agree on a common move. 48 | 49 | Further information about delegators, validators, and NAM can be found in the [proof-of-stake section](./proof-of-stake.mdx). 50 | 51 | ## Outline 52 | 53 | There are two ways to propose a change to the Namada protocol: 54 | 55 | 1. [**On-chain**](#on-chain-governance) - A proposal is submitted to the Namada blockchain, and the Namada blockchain handles the voting process. 56 | 2. [**Off-chain**](#off-chain-governance) - A proposal is submitted to a focal point outside of the Namada blockchain, and the voting process occurs off-chain. 57 | 58 | ## Spam resistance 59 | 60 | Namada governance implements a spam resistance mechanism to prevent the network from being spammed with proposals. 61 | This mechanism is based on the fact that a proposal must be submitted with a deposit of `NAM` tokens. 62 | This deposit is returned to the proposer if the proposal is accepted, and burned otherwise. 63 | This is only possible if the proposal is submitted on-chain, as off-chain proposals are not able to submit a deposit. -------------------------------------------------------------------------------- /packages/specs/pages/modules/governance/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "on-chain" : "On chain governance", 3 | "off-chain" : "Off chain governance", 4 | "proposal" : "Proposals", 5 | "storage" : "Storage", 6 | "public-goods-funding" : "Public goods funding" 7 | } -------------------------------------------------------------------------------- /packages/specs/pages/modules/governance/off-chain.mdx: -------------------------------------------------------------------------------- 1 | # Off-chain protocol 2 | 3 | At the end of the day, social consensus is what matters. 4 | The on-chain governance process exists to assist in reaching social consensus in a structured, well-defined way. 5 | However, it is clearly not the only way for people to coordinate and reach consensus. 6 | Instead, social consensus may be reached off-chain through any community-selected mechanism. 7 | These commands exist simply as a tool to facilitate the process of reaching social consensus off-chain, according to the ruleset predefined by the protocol. 8 | It is expected that the community will use the offline proposal mechanism primarily for when the chain is halted. 9 | 10 | ## Creating an offline proposal 11 | 12 | Offline proposals are represented as JSON objects with the following structure: 13 | 14 | ``` 15 | { 16 | content: Base64<Vec<u8>>, 17 | author: Address, 18 | tallyEpoch: Epoch, 19 | signature: Base64<Vec<u8>> 20 | } 21 | ``` 22 | 23 | The signature is produced over the hash of the concatenation of: `content`, `author`, and `tallyEpoch`. 24 | Proposal types are not supported off-chain. 25 | 26 | ### Proposal fields 27 | 28 | - `content`: The proposal content (encoded). This is the actual proposal that will be voted on. 29 | - `author`: The address of the proposal author. 30 | - `tallyEpoch`: The epoch in which the proposal will be tallied. This epoch must already exist when tallying occurs. If the chain is halted, this means choosing an epoch in the past (e.g. the most recent epoch). 31 | - `signature`: The signature of the proposal author over the hash of the concatenation of: `content`, `author`, and `tallyEpoch` 32 | 33 | ## Voting offline 34 | 35 | Offline votes are represented as JSON objects with the following structure: 36 | 37 | ``` 38 | { 39 | proposalHash: Base64<Vec<u8>>, 40 | voter: Address, 41 | signature: Base64<Self.proposalHash>, 42 | vote: Enum(yay|nay|abstain) 43 | } 44 | ``` 45 | 46 | The proposalHash is produced over the concatenation of: `content`, `author`, `votingStart`, `votingEnd`, `voter` and `vote`. 47 | The signature is produced over the hash of the concatenation of: `proposalHash`, `voter` and `vote`. 48 | 49 | ## Tallying votes offline 50 | 51 | Offline votes are tallied under the same mechanism as [on chain vote tallying](./on-chain.mdx#tally), but instead of reading the data from storage it will require a list of serialized json votes. 52 | The voting power for each delegate/delegator is calculated based on their respective bonded-stake from the latest block in that epoch (in principle it could be any block in the epoch, since voting-power does not change within an epoch). -------------------------------------------------------------------------------- /packages/specs/pages/modules/governance/proposal.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | # Namada Proposals 4 | 5 | ## Proposal JSON 6 | For online proposals, the fields of the proposal JSON are as follows: 7 | 8 | ```json 9 | { 10 | "proposal": { 11 | "id": 1, // The proposal id 12 | "content": content, // (see below), 13 | "author": "author", // The author's address 14 | "voting_start_epoch": 420, // The epoch at which voting starts 15 | "voting_end_epoch": 426, // The epoch at which voting ends 16 | "grace_epoch": 432, // The epoch at which the proposal will be executed (if it passes) 17 | }, 18 | "data": data // The optional proposal data, depends on the type of proposal 19 | } 20 | ``` 21 | 22 | - The `content` value should follow a standard format. 23 | We leverage a similar format to what is described in the [BIP2](https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#bip-format-and-structure) document: 24 | 25 | ```json 26 | { 27 | "title": "<text>", 28 | "authors": "<authors' email addresses> ", 29 | "discussions-to": "<email address / link>", 30 | "created": "<date created on, in ISO 8601 (yyyy-mm-dd) format>", 31 | "license": "<abbreviation for approved license(s)>", 32 | "abstract": "<text>", 33 | "motivation": "<text>", 34 | "details": "<Proposal Number> - optional field", 35 | "requires": "<proposal id of any proposals that need to occur before this proposal can be implemented> -optional field", 36 | } 37 | ``` 38 | 39 | <Callout type="info" emoji=""> 40 | The proposal number is different from the proposal id. The id is a counter that does not include offline proposals. The proposal number is a counter that includes offline proposals. 41 | The proposal id is a unique identifier that is assigned to each proposal when it is submitted. The proposal id is used to reference a proposal in the Namada blockchain. 42 | </Callout> 43 | 44 | The `Author` address field will be used to credit the locked funds if the proposal is approved. 45 | The `ProposalType` imply different combinations of: 46 | - the optional wasm code attached to the proposal 47 | - which actors should be allowed to vote (delegators and validators or validators only) 48 | - the threshold to be used in the tally process 49 | - the optional payload (memo) attached to the vote 50 | 51 | ## Supported proposal types 52 | 53 | At the moment, Namada supports 3 types of governance proposals: 54 | 55 | ```rust 56 | pub enum ProposalType { 57 | /// Carries the optional proposal code path 58 | Default(Option<String>), 59 | StewardProposal, 60 | PGFProposal, 61 | } 62 | ``` 63 | 64 | `Default` represents a generic proposal with the following properties: 65 | 66 | - Can carry a WASM code to be executed in case the proposal passes 67 | - Allows both validators and delegators to vote 68 | - Requires $\frac{2}{3}$ of the total voting power to succeed 69 | - Doesn't expect any memo attached to the votes 70 | 71 | `StewardProposal` is a proposal to change the StewardSet for _Public Goods Funding_: 72 | - Doesn't carry any WASM code 73 | - Allows both validators and delegators to vote 74 | - Requires $\frac{1}{3}$ of the total voting power to vote 75 | - Requires $\frac{1}{2}$ of the non-abstain (either yea or nay) votes to be `Yay` 76 | 77 | `PGFProposal` is a proposal to *conduct* _Public Goods Funding_: 78 | - Doesn't carry any WASM code 79 | - Allows both validators and delegators to vote 80 | - Has different properties depending on whether or not the submitter is a steward 81 | If the proposer is not a steward: 82 | - Requires $\frac{1}{3}$ of the total voting power to vote 83 | - Requires $\frac{1}{2}$ of the non-abstain votes to be `Yay` 84 | If the proposer is a steward, passes unless: 85 | - $\frac{1}{3}$ of the total voting power votes on the proposal, **AND** out of the votes, at least $\frac{1}{2}$ of the non-abstain votes are `Nay` 86 | - Causes the steward to lose steward status if $\frac{2}{3}$ of the total voting power votes on the proposal **AND** out of the votes, at least $\frac{2}{3}$ of the non-abstain votes are `Nay` -------------------------------------------------------------------------------- /packages/specs/pages/modules/governance/public-goods-funding/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "public-goods-stewards" : "Public Goods Stewards", 3 | "becoming-a-steward" : "Becoming a steward", 4 | "electing" : "Electing the stewards", 5 | "funding" : "Mechanism for funding", 6 | "incentives" : "Steward incentives", 7 | "storage" : "Storage" 8 | } -------------------------------------------------------------------------------- /packages/specs/pages/modules/governance/public-goods-funding/electing.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | # Electing the stewards 4 | 5 | ## Voting for the stewards 6 | 7 | After the `StewardProposal` has been submitted, the steward address can be voted on by governance participants. All voting must occur between `votingStartEpoch` and `votingEndEpoch`. 8 | 9 | 10 | The vote for a steward-set change will be constructed as follows: 11 | 12 | 13 | Each participant submits a vote through governance: 14 | ```rust 15 | struct OnChainVote { 16 | id: u64, 17 | voter: Address, 18 | yay: proposalVote, 19 | } 20 | ``` 21 | 22 | Where the proposalVote is simply an enum dictating whether the voter voted `Yay` or `Nay` to the proposed candidate change. 23 | The `id` will correspond to the `id` of the `StewardProposal` that is being voted on. 24 | 25 | 26 | #### Dealing with ties 27 | In the rare occurrence of a tie, the `StewardProposal` is rejected, i.e. the current steward-set remains the same. 28 | 29 | 30 | ## Electing stewards 31 | 32 | Once the decision has been made on whether to elect (or remove) the intended steward/s, the established address/es corresponding to the multisig/s is/are added to (removed from) the `PGF` internal address. 33 | 34 | ### Example 35 | 36 | The below example hopefully demonstrates the mechanism more clearly. 37 | 38 | <Callout type="info" emoji="🧑‍🏫"> 39 | The governance set consists of Alice, Bob, Charlie, Dave, and Elsa. Each member has 20% voting power. 40 | 41 | The current PGF stewards are Dave and Elsa. 42 | 43 | - At epoch 42, Bob and Charlie decide to put themselves forward as a joint PGF Steward. They construct a multisig with address `0xBobCharlieMultisig`. 44 | - At epoch 42, Bob proposes his and Charlie's candidacy through a `StewardProposal`: 45 | 46 | ```rust 47 | struct StewardProposal{ 48 | id: 2 49 | content: Vec<32,54,01,24,13,37>, // (Just the byte representation of the content (description) of the proposal) 50 | author: 0xBobCharlieMultisig, 51 | r#type: StewardProposal, 52 | votingStartEpoch: Epoch(45), 53 | votingEndEpoch: Epoch(54), 54 | graceEpoch: Epoch(57), 55 | } 56 | ``` 57 | 58 | This proposal proposes the candidate 0xBobCharlieMultisig as a Steward. 59 | 60 | - At epoch 49, Alice submits the vote: 61 | 62 | ```rust 63 | struct OnChainVote { 64 | id: 2, 65 | voter: 0xalice, 66 | yay: proposalVote, 67 | } 68 | ``` 69 | Where the proposalVote is simply the enum `Yay` with an empty memo field. 70 | 71 | - At epoch 49, Bob and Elsa submit an identical transaction. 72 | 73 | - At epoch 50, Dave votes `Nay` on the proposal. 74 | 75 | - At epoch 54, the voting period ends and the votes are tallied. Since 80% > 66% of the voting power voted on this proposal (everyone except Charlie, who forgot to vote on her own proposal), the initial condition is passed and the Proposal is active. Further, because out of the total votes, most were `Yay`, (75% > 50% threshold), the new Steward consisting of Bob and Charlie will be added to the Steward set. 76 | 77 | - At epoch 57, Bob and Charlie have the effective power to propose Public Goods Funding transactions (that may or may not be vetoed). 78 | </Callout> 79 | -------------------------------------------------------------------------------- /packages/specs/pages/modules/governance/public-goods-funding/incentives.mdx: -------------------------------------------------------------------------------- 1 | # PGF stewards incentives 2 | 3 | Being a PGF steward is (should be) hard work. Stewards must invest their time in crafting proposals, being in touch with the opinions of the Namada community, and taking the risks associated with being voted out. 4 | In order to incentivise this effort, Namada allocates a set amount of NAM inflation that is directed towards the stewards. 5 | 6 | By default, this inflation is directed (directly) to each PGF steward account. The steward can then decide what to do with any collected funds. 7 | The Steward account can also unilaterally (within the rules of a multisig transaction) set up a stream of income to a separate set of accounts (e.g. a set of personal accounts between the signers behind the steward account). 8 | The inflation is then credited directly to these set of accounts. 9 | 10 | The parameter of inflation income is set by governance and is included in genesis by default. 11 | That allocation is allocated to each steward (more stewards = more total funding). 12 | -------------------------------------------------------------------------------- /packages/specs/pages/modules/governance/public-goods-funding/public-goods-stewards.mdx: -------------------------------------------------------------------------------- 1 | # The public goods stewards 2 | 3 | The funding of public goods on Namada is conducted through a structure we call "public goods stewards". 4 | 5 | Each steward is elected by governance through separate governance proposals. Each steward is responsible 6 | for covering a specific area of public goods, which they describe during their election. Stewards can then "propose" 7 | funding of various public goods, which passes by default. However, Governance retains the power to veto any proposal, 8 | which would result in the Steward being removed from the set of stewards. 9 | 10 | ## What is a Steward (technically)? 11 | All valid PGF stewards are established multisignature account addresses. These must be created by the parties 12 | (which may very well be just one person, but could be more) that wish to represent the steward entity. For example, if 13 | David Alice and Bob wish to represent the combined steward DAB, they may do so as a common entity. But likewise, Alice 14 | can create her own 1-out-of-1 multisig that to just represent herself. -------------------------------------------------------------------------------- /packages/specs/pages/modules/governance/public-goods-funding/storage.mdx: -------------------------------------------------------------------------------- 1 | # Stewards in storage 2 | 3 | {/* TODO: This needs to be updated */} 4 | 5 | ## Addresses 6 | Governance adds 1 internal address: 7 | 8 | `PGF` internal address 9 | 10 | The internal address VP will hold the allowance of 10% inflation of NAM. This funding is allocated to the internal address at the start of each epoch. It is important to note that it is this internal address which holds the funds, rather than any of the stewards' multisigs. 11 | 12 | The stewards should be able to propose the burning of funds, but this hopefully should not require additional functionality beyond what currently exists. 13 | 14 | ### VP checks 15 | 16 | The VP must check that any spending in the form of `FundingProposals` or `StewardFundingProposal`s does not exceed the balance of the VP (in aggregate). 17 | 18 | The VP must also check that any `StewardFundingProposal` spending is only done by the active PGF stewards. 19 | 20 | ## Storage 21 | 22 | ### Storage keys 23 | 24 | Each recipient will be listed under this storage space (for cPGF) 25 | - `/PGFAddress/cPGF_recipients/address = Amount` 26 | - `/PGFAddress/active_stewards/address = Address` 27 | {/* TODO: Make this accurate */} 28 | - `/GovernanceParams/StewardTerm = Epoch` 29 | 30 | ### Struct 31 | 32 | The below is a rust implementation of the Steward structure. 33 | ```rust 34 | struct Stewards { 35 | addresses: Vec<Address>, 36 | } 37 | ``` -------------------------------------------------------------------------------- /packages/specs/pages/modules/governance/storage.mdx: -------------------------------------------------------------------------------- 1 | import { Callout } from 'nextra-theme-docs' 2 | 3 | 4 | # Governance storage 5 | 6 | Just like PoS, governance also has its own storage space. 7 | 8 | ## Proposals 9 | Each proposal is stored in a sub-key under the internal proposal address. The storage keys involved are: 10 | 11 | ``` 12 | /$GovernanceAddress/proposal/$id/content: Vec<u8> 13 | /$GovernanceAddress/proposal/$id/author: Address 14 | /$GovernanceAddress/proposal/$id/type: ProposalType 15 | /$GovernanceAddress/proposal/$id/start_epoch: Epoch 16 | /$GovernanceAddress/proposal/$id/end_epoch: Epoch 17 | /$GovernanceAddress/proposal/$id/grace_epoch: Epoch 18 | /$GovernanceAddress/proposal/$id/proposal_code: Option<Vec<u8>> 19 | /$GovernanceAddress/proposal/$id/funds: u64 20 | /$GovernanceAddress/proposal/$id/result: ProposalResult 21 | /$GovernanceAddress/proposal/epoch/$id: u64 22 | ``` 23 | 24 | <Callout type="info" emoji="⏱️"> 25 | **Definition of "Epoch":** 26 | 27 | An **epoch** is a range of blocks or time that is defined by the base ledger and made available to the PoS system. 28 | This document assumes that epochs are identified by consecutive natural numbers. 29 | All the data relevant to PoS are [associated with epochs](../proof-of-stake/objects-and-txs.mdx#epoched-data). 30 | </Callout> 31 | 32 | `/$GovernanceAddress/proposal/$epoch/$id` is used for efficient iteration over proposals by epoch. 33 | 34 | `$epoch` refers to the same value as the one specified in the `grace_epoch` field. 35 | 36 | `/$GovernanceAddress/proposal/$id/result` is used to store the result of the proposal after the tally has been performed: this allows the recover of a past result even after the validator set (and the corresponding voting powers) has changed. 37 | 38 | ## `GovernanceAddress` 39 | 40 | `GovernanceAddress` parameters and global storage keys are: 41 | 42 | ``` 43 | /$GovernanceAddress/counter: u64 44 | /$GovernanceAddress/min_proposal_fund: u64 45 | /$GovernanceAddress/max_proposal_code_size: u64 46 | /$GovernanceAddress/min_proposal_period: u64 47 | /$GovernanceAddress/max_proposal_content_size: u64 48 | /$GovernanceAddress/min_proposal_grace_epochs: u64 49 | /$GovernanceAddress/pending/$proposal_id: u64 50 | ``` 51 | 52 | - `counter` is used to assign a unique, incremental ID to each proposal. 53 | - `min_proposal_fund` represents the minimum amount of locked tokens to submit a proposal. 54 | - `max_proposal_code_size` is the maximum allowed size (in bytes) of the proposal WASM code. 55 | - `min_proposal_period` sets the minimum voting time window (in `Epoch`). 56 | - `max_proposal_content_size` tells the maximum number of characters allowed in the proposal content. 57 | - `min_proposal_grace_epochs` is the minimum required time window (in `Epoch`) between `end_epoch` and the epoch in which the proposal has to be executed. 58 | - `/$GovernanceAddress/pending/$proposal_id` - this storage key is written only before the execution of the code defined in `/$GovernanceAddress/proposal/$id/proposal_code` and deleted afterwards. Since this storage key can be written only by the protocol itself (and by no other means), VPs can check for the presence of this storage key to be sure that a proposal_code has been executed by the protocol and not by a transaction. 59 | 60 | ## Votes 61 | 62 | Vote transaction creates or modifies the following storage key: 63 | 64 | ``` 65 | /$GovernanceAddress/proposal/$id/vote/$delegation_address/$voter_address: ProposalVote 66 | ``` 67 | 68 | The storage key will only be created if the transaction is signed either by a validator or a delegator. 69 | In case a vote misses a required memo or carries a memo with an invalid format, the vote will be discarded at validation time (by the VP) and it won't be written to storage. 70 | 71 | 72 | ## External storage 73 | The governance machinery also relies on a subkey stored under the `NAM` token address: 74 | 75 | ``` 76 | /$NAMAddress/balance/$GovernanceAddress: u64 77 | ``` 78 | 79 | This is to leverage the `NAM` VP to check that the funds were correctly locked. 80 | The governance subkey, `/$GovernanceAddress/proposal/$id/funds` will be used after the tally step to know the exact amount of tokens to refund or move to Treasury. -------------------------------------------------------------------------------- /packages/specs/pages/modules/images/cubic_slash.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/specs/pages/modules/images/cubic_slash.png -------------------------------------------------------------------------------- /packages/specs/pages/modules/images/inflation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/specs/pages/modules/images/inflation.png -------------------------------------------------------------------------------- /packages/specs/pages/modules/images/locking.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/specs/pages/modules/images/locking.png -------------------------------------------------------------------------------- /packages/specs/pages/modules/masp.mdx: -------------------------------------------------------------------------------- 1 | ## Multi-asset shielded pool 2 | 3 | The multi-asset shielded pool (MASP) is an extension to the Sapling circuit which adds support for sending arbitrary assets. 4 | 5 | See the following documents: 6 | - [Cryptographic specification](https://github.com/anoma/masp/blob/main/docs/multi-asset-shielded-pool.pdf) 7 | - [Ledger integration](./masp/ledger-integration.mdx) 8 | - [Asset type schema](./masp/asset-type.mdx) 9 | - [Burn and mint](./masp/burn-and-mint.mdx) 10 | - [Convert circuit](./masp/convert-circuit.mdx) 11 | - [Shielded pool incentives](./masp/shielded-pool-incentives.mdx) -------------------------------------------------------------------------------- /packages/specs/pages/modules/masp/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "ledger-integration": "Ledger integration", 3 | "asset-type": "Asset type", 4 | "burn-and-mint": "Burn & mint", 5 | "convert-circuit": "Convert circuit", 6 | "trusted-setup": "Trusted setup", 7 | "shielded-pool-incentives": "Shielded pool rewards" 8 | } 9 | -------------------------------------------------------------------------------- /packages/specs/pages/modules/masp/asset-type.mdx: -------------------------------------------------------------------------------- 1 | ## Asset name schema 2 | 3 | MASP notes carry balances that are some positive integer amount of an 4 | asset type. Per both the MASP specification and the implementation, the 5 | asset *identifier* is an 32-byte [Blake2s hash](https://www.blake2.net/) of an arbitrary asset 6 | *name* string, although the full 32-byte space is not used because the 7 | identifier must itself hash to an elliptic curve point (currently 8 | guaranteed by incrementing a nonce until the hash is a curve point). The 9 | final curve point is the asset *type* proper, used in computations. 10 | 11 | The following is a schema for the arbitrary asset name string intended 12 | to support various uses - currently fungible tokens and NFTs, but possibly 13 | others in future. 14 | 15 | The asset name string is built up from a number of segments, joined by a 16 | separator. We use `/` as the separator. 17 | 18 | Segments may be one of the following: 19 | 20 | - **Controlling address** segment: a Namada address which controls the 21 | asset. For example, this is the fungible token address for a fungible 22 | token. This segment must be present, and must be first; it should in 23 | theory be an error to transparently transact in assets of this type 24 | without invoking the controlling address's VP. This should be achieved 25 | automatically by all transparent changes involving storage keys under 26 | the controlling address. 27 | 28 | - **Epoch** segment: An integer greater than zero, representing an epoch 29 | associated with an asset type. Mainly for use by the incentive 30 | circuit. This segment must be second if present. (should it be 31 | required? could be 0 if the asset is unepoched) (should it be first so 32 | we can exactly reuse storage keys?) This must be less than or equal to 33 | the current epoch. 34 | 35 | - **Address** segment: An ancillary address somehow associated with the 36 | asset. This address probably should have its VP invoked, and is 37 | probably in the transparent balance storage key. 38 | 39 | - **ID** segment: A nonnegative (?) integer identifying something, i.e., 40 | a NFT id. (should probably not be a u64 exactly - for instance, I 41 | think ERC721 NFTs are u256) 42 | 43 | - **Text** segment: A piece of text, normatively but not necessarily 44 | short (50 characters or less), identifying something. For 45 | compatibility with non-numeric storage keys used in transparent assets 46 | generally; an example might be a ticker symbol for a specific 47 | sub-asset. The valid character set is the same as for storage keys. 48 | 49 | For example, suppose there is a virtual stock certificate asset, 50 | incentivized (somehow), at transparent address `addr123`, which uses 51 | storage keys like `addr123/[owner address]/[ticker symbol]/[id]`. The 52 | asset name segments would be: 53 | 54 | - Controlling address: just `addr123` 55 | - Epoch: the epoch when the note was created 56 | - Owner address: an address segment 57 | - Ticker symbol: a text segment 58 | - ID: an ID segment 59 | 60 | This could be serialized to, e.g., `addr123/addr456/tSPY/i12345`. 61 | -------------------------------------------------------------------------------- /packages/specs/pages/modules/masp/shielded-pool-incentives.mdx: -------------------------------------------------------------------------------- 1 | ## Shielded pool rewards 2 | 3 | Privacy provided by the MASP in practice depends on how many users use the shielded pool and what assets they use it with. To increase the likelihood of a sizeable privacy set, Namada pays a variable portion of inflation, up to 10% per annum, to shielded pool incentives, which are allocated on a per-asset basis by a PD-controller targeting specific amounts of each asset being locked in the shielded pool. 4 | 5 | ### Rationale 6 | 7 | The economic rationale for subsidizing the shielded set comes from "positive externalities": the shielding of more assets into the current privacy set not only provides better privacy for the owner of the assets, but enhances privacy for *everyone*. In this way, even users that are indifferent about privacy, are "nudged" into shielding their assets. This is especially important in an environment where users pay for computation, and shielded transactions are expected to be more expensive than transparent transactions. 8 | 9 | The subsidy on Namada adheres to the following constraints in order to avoid perverse incentives: 10 | - Fee subsidies cannot reduce fees to zero, or reduce fees so much that inexpensive transaction spam can fill blocks and overload validators. 11 | - Incentives for contributing to the privacy set should not incentivise transactions which do not meaningfully contribute to the privacy set or merely repeat a previous action (shielded and unshielding the same assets, repeatedly transferring the same assets, etc.) 12 | - Incentives for contributing to the privacy set, since the MASP supports many assets, will need to be adjusted over time according to actual conditions of use. 13 | 14 | ### Design 15 | 16 | Namada enacts a shielded pool incentive which pays users a variable rate for keeping assets in the shielded pool. Assets do not need to be locked in any way. Users may claim rewards while remaining in the shielded pool using the convert circuit, and unshield the rewards (should they wish to) at some later point in time. The protocol uses a PD (proportional-derivative) controller to target the reward rate for each asset, as a function of the amount of the asset in the shielded pool. 17 | 18 | ### Implementation 19 | 20 | When users deposit assets into the shielded pool, the current epoch is appended to the asset type. Users can use these "epoched assets" as normal within the shielded pool. When epochs advance, users can use the [convert circuit](../masp/convert-circuit.mdx) to convert assets tagged with the old epoch to assets tagged with the new epoch, receiving shielded rewards in NAM proportional to the amount of the asset they had shielded, which automatically compound while the assets are shielded and the epochs progressing. When unshielding from the shielded pool, assets must be first converted to the current epoch (claiming any rewards), after which they can be converted back to the normal (un-epoched) unshielded asset denomination. 21 | 22 | Namada allocates up to 10% per annum inflation of NAM to pay for shielded pool rewards. 23 | 24 | {/* TODO: #82 Is the below still accurate */} 25 | This inflation is kept in a temporary shielded rewards pool, which is then allocated according to a set of PD (proportional-derivative) controllers for assets and target shielded amounts configured by Namada governance. Each epoch, subject to available rewards, each controller calculates the reward rate for its asset in this epoch, which is then used to compute entries into the conversion table. Entries from epochs before the previous one are recalculated based on cumulative rewards. Users may then asynchronously claim their rewards by using the convert circuit at some future point in time. 26 | -------------------------------------------------------------------------------- /packages/specs/pages/modules/multitoken.mdx: -------------------------------------------------------------------------------- 1 | # Fungible token 2 | 3 | {/* TODO: Unfamiliar with this VP, should be looked at */} 4 | 5 | The fungible token validity predicate authorises token balance changes on the basis of conservation-of-supply and approval-by-sender. Namada implements a "multitoken" validity predicate, in that all tokens have the same logic and can share one VP (with appropriate storage distinctions). 6 | 7 | A token balance is stored with a storage key. The token balance key should be `#Multitoken/{token_addr}/balance/{owner_addr}`. These keys can be made with [token functions](https://github.com/anoma/namada/blob/5da82f093f10c0381865accba99f60c557360c51/core/src/types/token.rs). 8 | 9 | We can have multitoken balances for the same owner by `{token_addr}`, e.g. a token received over IBC is managed in `#Multitoken/{ibc_token}/balance/{receiver_addr}`. It is distinguished from the receiver's original balance in `#Multitoken/{token_addr}/balance/{receiver_addr}` to know which chain the token was transferred from. The `{ibc_token}` is explained in [IBC](../modules/ibc.mdx). 10 | 11 | Transfers between the balances with the same `{token_addr}` are allowed. Specifically, we can transfer a token from `#Multitoken/{token_addr}/balance/{sender_addr}` to `#Multitoken/{token_addr}/balance/{receiver_addr}`. 12 | 13 | These balance changes are validated by the multitoken validity predicate. It also checks the minted or burned token. If a token is minted or burned, i.e. when `#Multitoken/{token_addr}/balance/minted` is updated in the transaction, not only the total minted balance is checked but also calling the minter's validity predicate is checked. The minter should be set in a transaction minting the token. For example, when a token is received over IBC, the received token will be minted for the receiver's balance `#Multitoken/{ibc_token}/balance/{receiver_addr}`. The minted balance `#Multitoken/{ibc_token}/balance/minted` is also increased by the amount of the received token. The minted amount should be checked by the multitoken validity predicate. And, the multitoken validity predicate checks if the minter's validity predicate, the IBC validity predicate in this case, will be called (IBC validity predicate checks the minted amount is correct for the corresponding IBC operation). 14 | -------------------------------------------------------------------------------- /packages/specs/pages/modules/proof-of-stake.mdx: -------------------------------------------------------------------------------- 1 | # Proof-of-stake (PoS) 2 | 3 | This section of the specification describes the proof-of-stake mechanism of Namada, which is largely modeled after [Cosmos bonded proof-of-stake](https://github.com/cosmos/cosmos-sdk/blob/master/x/staking/spec/README.md), but makes significant changes to bond storage representation, validator set change handling, reward distribution, and slashing, with the general aims of increased precision in reasoning about security, validator decentralisation, and avoiding unnecessary proof-of-stake-related transactions. 4 | 5 | This section is split into three subcomponents: the [bonding mechanism](./proof-of-stake/objects-and-txs.mdx), [reward distribution](./proof-of-stake/reward-distribution.mdx), and [cubic slashing](./proof-of-stake/cubic-slashing.mdx). 6 | 7 | ## Context 8 | 9 | Blockchain systems rely on economic security (directly or indirectly) to 10 | prevent 11 | abuse and 12 | for actors 13 | to behave according to the protocol. The aim is that economic incentives promote 14 | correct long-term operation of the system and economic punishments 15 | discourage diverging from correct protocol execution either by mistake or 16 | with the intent of carrying out attacks. Many PoS blockchains rely on the 1/3 Byzantine rule, where they make the assumption the adversary cannot control more 2/3 of the total stake or 2/3 of the actors. 17 | 18 | ## Goals of Rewards and Slashing: Liveness and Security 19 | 20 | * **Security: Delegation and Slashing**: we want to make sure validators are 21 | backed by enough funds to make misbehavior very expensive. Security is 22 | achieved by punishing (slashing) if they do. *Slashing* locked funds (stake) 23 | intends to disincentivize diverging from correct execution of protocol, 24 | which in this case is voting to finalize valid blocks. 25 | * **Liveness: Paying Rewards**. For continued operation of Namada we want to incentivize participating in consensus and delegation, which helps security. 26 | 27 | ### Security 28 | 29 | In blockchain systems we do not rely on altruistic behavior but rather economic 30 | security. We expect the validators to execute the protocol correctly. They get rewarded for doing so and punished otherwise. Each validator has some self-stake and some stake that is delegated to it by other token holders. The validator and delegators share the reward and risk of slashing impact with each other. 31 | 32 | The total stake behind consensus should be taken into account when value is transferred via a transaction. For example, if we have 1 billion tokens, we aim that 300 Million of these tokens is backing validators. This means that users should not transfer more than 200 million of this token within a block. 33 | -------------------------------------------------------------------------------- /packages/specs/pages/modules/proof-of-stake/_meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "objects-and-txs": "Objects and Txs", 3 | "cubic-slashing": "Cubic slashing", 4 | "reward-distribution": "Reward distribution", 5 | "inflation-system": "Inflation system" 6 | } 7 | -------------------------------------------------------------------------------- /packages/specs/public/favicon-16x16.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/specs/public/favicon-16x16.png -------------------------------------------------------------------------------- /packages/specs/public/favicon-32x32.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/specs/public/favicon-32x32.png -------------------------------------------------------------------------------- /packages/specs/public/favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/specs/public/favicon.ico -------------------------------------------------------------------------------- /packages/specs/public/images/namada_specs_ascii_dark.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/specs/public/images/namada_specs_ascii_dark.png -------------------------------------------------------------------------------- /packages/specs/public/images/namada_specs_ascii_light.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/specs/public/images/namada_specs_ascii_light.png -------------------------------------------------------------------------------- /packages/specs/public/images/trusted-setup-assets/contribution-sequence-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/specs/public/images/trusted-setup-assets/contribution-sequence-diagram.png -------------------------------------------------------------------------------- /packages/specs/public/images/trusted-setup-assets/namada-ts-arch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/specs/public/images/trusted-setup-assets/namada-ts-arch.png -------------------------------------------------------------------------------- /packages/specs/public/images/trusted-setup-assets/namda-ts-swimlane.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/specs/public/images/trusted-setup-assets/namda-ts-swimlane.png -------------------------------------------------------------------------------- /packages/specs/public/images/trusted-setup-assets/optimistic-mmorpg-mpc-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/specs/public/images/trusted-setup-assets/optimistic-mmorpg-mpc-diagram.png -------------------------------------------------------------------------------- /packages/specs/public/images/trusted-setup-assets/trusted-setup-actors.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/specs/public/images/trusted-setup-assets/trusted-setup-actors.png -------------------------------------------------------------------------------- /packages/specs/public/opengraph.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BrainCord/namada-docs/e0862eb4785891e7df7fc58e2f113d61cddd712e/packages/specs/public/opengraph.jpg -------------------------------------------------------------------------------- /packages/specs/theme.config.tsx: -------------------------------------------------------------------------------- 1 | import React from "react"; 2 | import { Logo } from "./components/Logo"; 3 | import { DocsThemeConfig } from "nextra-theme-docs"; 4 | import { PageHead } from "./components/PageHead"; 5 | 6 | const description = `"Specs for Namada, a Proof-of-Stake L1 for interchain asset-agnostic privacy.`; 7 | 8 | const config: DocsThemeConfig = { 9 | primaryHue: 180, 10 | useNextSeoProps() { 11 | return { 12 | titleTemplate: "Namada Specs - %s", 13 | defaultDescription: description, 14 | canonical: "https://specs.namada.net", 15 | description, 16 | }; 17 | }, 18 | head: <PageHead />, 19 | logo: <Logo />, 20 | project: { 21 | link: "https://github.com/anoma/namada", 22 | }, 23 | chat: { 24 | link: "https://discord.gg/namada", 25 | }, 26 | sidebar: { 27 | defaultMenuCollapseLevel: 1, 28 | }, 29 | docsRepositoryBase: 30 | "https://github.com/anoma/namada-docs/blob/master/packages/specs", 31 | footer: { 32 | text: "Namada", 33 | }, 34 | }; 35 | 36 | export default config; 37 | -------------------------------------------------------------------------------- /packages/specs/tsconfig.json: -------------------------------------------------------------------------------- 1 | { 2 | "extends": "../../tsconfig.base.json" 3 | } 4 | -------------------------------------------------------------------------------- /tsconfig.base.json: -------------------------------------------------------------------------------- 1 | { 2 | "compilerOptions": { 3 | "target": "es5", 4 | "lib": ["dom", "dom.iterable", "esnext"], 5 | "allowJs": true, 6 | "skipLibCheck": true, 7 | "strict": false, 8 | "forceConsistentCasingInFileNames": true, 9 | "noEmit": true, 10 | "incremental": true, 11 | "esModuleInterop": true, 12 | "module": "esnext", 13 | "moduleResolution": "node", 14 | "resolveJsonModule": true, 15 | "isolatedModules": true, 16 | "jsx": "preserve" 17 | }, 18 | "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx"], 19 | "exclude": ["node_modules"] 20 | } 21 | --------------------------------------------------------------------------------