[
  {
    "path": ".github/mk-pantry-accessible.sh",
    "content": "#!/bin/sh\n\ngit config --global url.\"https://teaxyz:$1@github.com/teaxyz/pantry\".insteadOf \"https://github.com/teaxyz/pantry\"\n"
  },
  {
    "path": ".github/workflows/cd.yml",
    "content": "name: CD\n\non:\n  push:\n    branches: [main]\n    paths: ['i18n/**']\n\nenv:\n  TEA_SECRET: ${{ secrets.TEA_SECRET }}\n\njobs:\n  cd:\n    uses: ./.github/workflows/make.yml\n    with:\n      upload: true\n    secrets: inherit\n"
  },
  {
    "path": ".github/workflows/ci.yml",
    "content": "name: CI\n\non:\n  pull_request:\n    paths:\n      - white-paper.md\n      - metadata.yml\n      - 'i18n/**'\n      - 'img/**'\n      - .github/workflows/ci.yml\n      - Makefile\n\nconcurrency:\n  group: ${{ github.ref }}\n  cancel-in-progress: true\n\njobs:\n  compile:\n    uses: ./.github/workflows/make.yml\n    secrets: inherit\n"
  },
  {
    "path": ".github/workflows/make.yml",
    "content": "name: make\n\non:\n  workflow_call:\n    inputs:\n      release:\n        default: false\n        required: false\n        type: boolean\n      upload:\n        default: false\n        required: false\n        type: boolean\n\nenv:\n  TEA_SECRET: ${{ secrets.TEA_SECRET }}\n\njobs:\n  make:\n    runs-on: ubuntu-latest\n    steps:\n    - uses: actions/checkout@v3\n    - run: | # Use on-box make until tea/pantry revlock is resolved\n        sudo apt-get update\n        sudo apt-get install \\\n          texlive-latex-base \\\n          texlive-fonts-recommended \\\n          texlive-fonts-extra \\\n          texlive \\\n          texlive-latex-extra \\\n          texlive-xetex\n        eval \"$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)\"\n        brew install \\\n          pandoc \\\n          pandoc-crossref \\\n          librsvg\n        #FIXME: Can't pass secrets to remote-branch CI, so this is until teaxyz/pantry is public\n        sed -ne 's/^# tea\\/white-paper \\([0-9]*\\.[0-9]*\\.[0-9]*\\)/VERSION=\\1/p' README.md >> $GITHUB_ENV\n    - run: | # install noto fonts for translated pdfs\n        sudo apt-get install fonts-noto fonts-noto-cjk\n    # - run: .github/mk-pantry-accessible.sh ${{ secrets.TEMP_JACOBS_GITHUB_PAT }}\n    # - uses: teaxyz/setup@v0\n\n    - name: Set Version - Release\n      if: ${{ inputs.release }}\n      run: echo \"- \\fancyfoot[L]{$VERSION}\" >> metadata.yml\n    - name: Set Version - CI/CD\n      if: ${{ !inputs.release }}\n      run: |\n        date=$(date '+%Y%m%d')\n        echo \"- \\fancyfoot[L]{$VERSION+$date}\" >> metadata.yml\n\n    # - run: tea make\n    - run: | # Use on-box make until tea/pantry revlock is resolved\n        eval \"$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)\"\n        make\n    - uses: actions/upload-artifact@v3\n      with:\n        name: tea.white-paper\n        path: |\n          tea.white-paper.pdf\n          tea.white-paper_??.pdf\n\n    # Following steps only run for upload: true\n    - name: AWS credentials\n      if: ${{ inputs.upload }}\n      uses: aws-actions/configure-aws-credentials@v1\n      with:\n        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}\n        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}\n        aws-region: us-east-1\n\n    - name: Bundle translations\n      if: ${{ inputs.upload }}\n      run: |\n        mkdir white-papers\n        cp tea.white-paper_??.pdf white-papers/\n    - name: Bundle release\n      if: ${{ inputs.upload && inputs.release }}\n      run: cp tea.white-paper.pdf white-papers/\n\n    - name: Upload to S3\n      if: ${{ inputs.upload }}\n      run: |\n        aws s3 sync \\\n          ./white-papers s3://www.tea.xyz/ \\\n          --metadata-directive REPLACE \\\n          --cache-control no-cache,must-revalidate\n    - name: Invalidate cache\n      if: ${{ inputs.upload }}\n      run: |\n        aws cloudfront create-invalidation \\\n          --distribution-id ${{ secrets.AWS_CF_DISTRIBUTION_ID }} \\\n          --paths / /tea.white-paper*.pdf\n"
  },
  {
    "path": ".github/workflows/release.yml",
    "content": "name: Release\n\npermissions:\n  contents: write\n\non:\n  push:\n    branches: [main]\n    paths: [README.md]\n\nenv:\n  TEA_SECRET: ${{ secrets.TEA_SECRET }}\n\njobs:\n  check:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v3\n      - run: .github/mk-pantry-accessible.sh ${{ secrets.TEMP_JACOBS_GITHUB_PAT }}\n      - uses: teaxyz/setup@v0\n      - id: rev-parse\n        name: did we already publish this version?\n        run: |\n          # fetch tags since actions/checkout is a shallow checkout\n          git fetch --prune --unshallow --tags\n\n          if git show-ref --tags v$VERSION --quiet; then\n            echo \"::set-output name=result::cancel\"\n          fi\n\n      - uses: andymckay/cancel-action@0.2\n        if: ${{ steps.rev-parse.outputs.result == 'cancel' }}\n\n  make:\n    needs: [check]\n    uses: ./.github/workflows/make.yml\n    with:\n      release: true\n      upload: true\n    secrets: inherit\n\n  release:\n    runs-on: ubuntu-latest\n    needs: [make]\n    steps:\n      - name: Tag Release\n        uses: rickstaa/action-create-tag@v1\n        with:\n          tag: ${{ env.VERSION }}\n      - name: Release\n        uses: softprops/action-gh-release@v1\n        with:\n          tag_name: ${{ env.VERSION }}\n          files: |\n            tea.white-paper.pdf\n            tea.white-paper_??.pdf\n"
  },
  {
    "path": ".gitignore",
    "content": "*.pdf\n"
  },
  {
    "path": ".markdownlint.json",
    "content": "{\n  \"MD012\": false,\n  \"MD013\": false,\n  \"MD025\": false\n}"
  },
  {
    "path": "Makefile",
    "content": ".PHONY: all\n.PHONY: i18n\n.PHONY: clean\n\ntranslations := $(patsubst i18n/%/white-paper.md,tea.white-paper_%.pdf,$(wildcard i18n/*/white-paper.md))\n\nall: tea.white-paper.pdf $(translations)\n\ntea.white-paper.pdf: white-paper.md metadata.yml tea.csl img/*\n\tpandoc \\\n\t--number-sections \\\n\t--output $@ \\\n\t--metadata-file metadata.yml \\\n\t--filter pandoc-crossref \\\n\t--csl=tea.csl \\\n\t--citeproc \\\n\t$<\n\ni18n: $(translations)\n\ntea.white-paper_%.pdf: i18n/%/white-paper.md i18n/%/metadata.yml tea.csl img/*\n\tpandoc \\\n\t--number-sections \\\n\t--output $@ \\\n\t--metadata-file i18n/$*/metadata.yml \\\n\t--filter pandoc-crossref \\\n\t--csl=tea.csl \\\n\t--citeproc \\\n\t--pdf-engine=xelatex \\\n\t--variable mainfont=\"Noto Serif\" \\\n\t$<\n\nclean:\n\trm -f tea.white-paper*.pdf\n"
  },
  {
    "path": "README.md",
    "content": "# README\n\nThe tea white paper is a [semantically versioned](https://semver.org), [Markdown](https://daringfireball.net/projects/markdown/) document. New releases are deployed to Gitbook.\n\n## Contributing\n\nIf you have general feedback, please open a [discussion](discussions/) thread.\n"
  },
  {
    "path": "SUMMARY.md",
    "content": "# Table of contents\n\n* [README](README.md)\n* [white-paper](white-paper.md)\n"
  },
  {
    "path": "i18n/es/metadata.yml",
    "content": "title: Un Protocolo Descentralizado para Remunerar el Ecosistema de Código Abierto\nabstract: >\n  Crear un registro público, abierto y estable para todo el software de código abierto\n  permitirá a los proyectos publicar lanzamientos de forma independiente en lugar\n  de depender de terceros que ensamblan estos datos irregulares en cientos de\n  sistemas separados (y duplicados). Los mantenedores de paquetes publicarán\n  sus lanzamientos en un registro descentralizado impulsado por una blockchain\n  tolerante a fallos bizantinos para eliminar fuentes únicas de fallo, proporcionar\n  lanzamientos inmutables y permitir que las comunidades gobiernen sus regiones\n  del ecosistema de código abierto, independientemente de agendas externas.\n  \n  tea incentiva el mantenimiento de código abierto permitiendo a los participantes \n  de la red apostar valor contra los paquetes de los que dependen y quieren asegurar. \n  El graph del protocolo tea proporciona registro de paquetes inmutable, requisitos \n  de dependencia, autenticidad de paquetes y oráculos de uso para informar al algoritmo \n  de remuneración de tea. La inflación sistemática se distribuye a todos los paquetes \n  basándose en ese algoritmo. Si se encuentran problemas de seguridad o desarrollo, \n  los desarrolladores pueden hacer reclamaciones respaldadas por evidencia contra\n  el paquete, y pueden ocurrir penalizaciones. Los miembros de la comunidad de código \n  abierto pueden revisar paquetes por problemas de calidad, y el protocolo puede\n  responder a estas revisiones realizando eventos de penalización proporcionales.\n\nauthor:\n- Max Howell\n- Timothy Lewis\n- Thomas Borrel\nreferences:\n- id: sources\n  url: https://github.com/teaxyz/white-paper\n- id: cc\n  url: https://creativecommons.org/licenses/by-sa/4.0/\n- id: nist\n  url: https://nvd.nist.gov/vuln/detail/CVE-2021-44228\n- id: reuters\n  url: https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA\n- id: twitter\n  url: https://twitter.com/yazicivo/status/1469349956880408583\n- id: w3\n  url: https://www.w3.org/TR/did-core/\n- id: theregister\n  url: https://www.theregister.com/2016/03/23/npm_left_pad_chaos/\n- id: fossa\n  url: https://fossa.com/blog/npm-packages-colors-faker-corrupted/\n- id: lunasec\n  url: https://www.lunasec.io/docs/blog/node-ipc-protestware/\n- id: github\n  url: https://github.com/dominictarr/event-stream/issues/116\n- id: zdnet\n  url: https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/\n- id: threatpost\n  url: https://threatpost.com/backdoor-found-in-utility-for-linux/147581/\n- id: fbi\n  url: https://www.fbi.gov/news/stories/phantom-secure-takedown-031618\n- id: europol\n  url: https://www.europol.europa.eu/media-press/newsroom/news/800-criminals-arrested-in-biggest-ever-law-enforcement-operation-against-encrypted-communication\n- id: medium\n  url: https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502\n- id: semver\n  url: https://semver.org/\n- id: npmjsCrossenv\n  url: https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry.html\n- id: npmjsLodash\n  url: https://www.npmjs.com/package/lodash\n- id: npmjsChalk\n  url: https://www.npmjs.com/package/chalk\n- id: npmjsLogFourjs\n  url: https://www.npmjs.com/package/log4js/\n- id: arxiv\n  url: https://arxiv.org/abs/1207.2617/\n- id: web3\n  url: https://research.web3.foundation/en/latest/polkadot/overview/2-token-economics.html\nheader-includes:\n- \\usepackage{fancyhdr,ragged2e}\n- \\lhead{\\parbox[t]{0.5\\textwidth}{\\RaggedRight\\rightmark\\strut}}\n- \\rhead{\\parbox[t]{0.5\\textwidth}{\\RaggedLeft\\leftmark\\strut}}\n- \\setlength{\\headheight}{5\\baselineskip}\n- \\pagestyle{fancy}\n- \\fancyfoot[LE,RO]{© 2022 tea.inc.}\n  - \\fancyfoot[L]{v2.1.0+es}   # expand these variables!\nlang: es       # https://pandoc.org/MANUAL.html#language-variables\ndir: ltr      # language direction; ltr:left-to-right or rtl:right-to-left\ntranslator:\n  - boredray"
  },
  {
    "path": "i18n/es/white-paper.md",
    "content": "---\ndescripción: Versión 2.1.0\n---\n\n# white-paper\n\n## Un Protocolo Descentralizado para que Desarrolladores de Código Abierto Capturen el Valor que Crean\n\n* Max Howell\n* Thomas Borrel\n* Timothy Lewis\n* Troy Wong\n\n## Resumen\n\nUn sistema en el que los desarrolladores de código abierto puedan recibir recompensas proporcionales a sus contribuciones mejoraría la sostenibilidad e integridad de la cadena de suministro de software. Un protocolo descentralizado, asegurado por la reputación y los incentivos, podría lograr esto facilitando la acumulación de valor de vuelta a los desarrolladores que mantienen bases de código abierto como una utilidad pública, promoviendo así la innovación futura y el crecimiento dentro del ecosistema de código abierto. Los mantenedores de paquetes registrarán sus proyectos en un registro impulsado por una blockchain tolerante a faltas bizantinas. El algoritmo único de “Prueba de Contribución” del Protocolo tea determinará la contribución e impacto de cada proyecto en la utilidad y salud del sistema. Los proyectos registrados recibirán recompensas del Protocolo tea proporcionales a su contribución, estarán asegurados mediante staking, se beneficiarán de un sistema de reputación que abarca proyectos y colaboradores, y tendrán la opción de permitir que las comunidades gobiernen sus regiones del ecosistema de código abierto, independientemente de agendas externas. El Protocolo tea incentivará el mantenimiento del código abierto permitiendo a los participantes de la red que registraron sus proyectos y cumplen con las reglas de la red recibir recompensas y contribuir a su reputación y la de sus proyectos. Si se encuentran problemas de seguridad o desarrollo, los desarrolladores pueden hacer reclamos respaldados por evidencia contra el paquete, y puede ocurrir un slashing. Los miembros de la comunidad de código abierto pueden revisar paquetes por problemas de calidad, y el protocolo puede responder a estas revisiones realizando eventos de slashing proporcionales.\n\n## Descargo de Responsabilidad\n\nLa información presentada en este documento técnico es de naturaleza preliminar. En consecuencia, ni los autores ni ninguna de sus respectivas afiliadas asumen responsabilidad alguna de que la información aquí presentada sea definitiva o correcta y cada uno de los anteriores rechaza, en la medida máxima permitida por la ley aplicable, toda responsabilidad, ya sea que surja en agravio, contrato u otra forma, con respecto a este documento técnico. Ni este documento técnico ni nada de lo que contiene formarán la base de o serán considerados en conexión con, o actuarán como un incentivo para entrar en cualquier contrato o compromiso de cualquier tipo.\n\nNada en este documento técnico constituye una oferta de venta o una solicitud de compra de los tokens aquí discutidos. En cualquier caso, si este documento técnico fuera considerado como tal oferta o solicitud, ninguna oferta o solicitud está intencionada o transmitida por este documento técnico en ninguna jurisdicción donde esto sea ilegal, donde dicha oferta o solicitud requiriera licencia o registro, o donde tal oferta o solicitud esté sujeta a restricciones. En particular, cualquier token aquí discutido no ha sido, y, a la fecha de emisión de este documento técnico, no se pretende que sea, registrado bajo las leyes de valores o leyes similares de ninguna jurisdicción, ya sea que dicha jurisdicción considere tales tokens como un valor o instrumento similar y no se puede ofrecer o vender en ninguna jurisdicción donde hacerlo constituiría una violación de las leyes relevantes de dicha jurisdicción. No compre ningún token a menos que esté preparado para perder el precio total de la compra. Es una compra de alto riesgo y es poco probable que esté protegido si algo sale mal.\n\n## Licencia\n\nEste documento está disponible bajo la licencia [Creative Commons Attribution-ShareAlike 4.0 International license](https://creativecommons.org/licenses/by-sa/4.0/).\n\n## Introducción\n\nEl Internet moderno está predominantemente compuesto por proyectos de código abierto y ha sido así desde su inicio. Los proyectos de código abierto se desarrollan y mantienen a través de la colaboración entre comunidades de desarrolladores globales, y sus bases de código están disponibles para que cualquiera las utilice como un bien público. En los últimos 80 años (se cree generalmente que el primer ejemplo de software libre y de código abierto se lanzó en 1953), el software de código abierto ha evolucionado desde ser el producto de aficionados tecnológicos de nicho hasta la infraestructura sobre la cual se ha construido toda innovación. A pesar de la importancia del software de código abierto, los desarrolladores que crean y mantienen la base de código como un servicio público no reciben recompensas fungibles por su inmensa contribución como innovadores y mantenedores.\n\nEl software empresarial, que se ha convertido en una industria de miles de millones de dólares, se construye sobre la base establecida por el código abierto. Sin embargo, casi no hay acumulación de valor de vuelta a los individuos que mantienen desinteresadamente sus cimientos. Y aunque se han hecho fortunas a partir de él, el software de código abierto se crea y mantiene principalmente como un servicio público sin medios viables para que los desarrolladores capturen el valor que crean.\n\nCreemos que el potencial del Internet moderno ha sido limitado al depender de un pequeño porcentaje de los ingenieros del mundo para mantener el software de código abierto puramente por altruismo. El código abierto es un trabajo de amor a menudo obstaculizado por la falta de incentivos significativos para los mantenedores principales. Los desarrolladores de código abierto deben elegir entre un trabajo diario que proporciona salarios dignos o mantener la base misma del software empresarial. La falta de incentivos resulta en que proyectos realmente valiosos nunca alcancen su potencial mientras que otros sufren de problemas de seguridad debido a la falta de mantenimiento a lo largo del ciclo de vida del software. Para desbloquear todo el potencial del código abierto, necesitamos un método universal para evaluar el \"valor justo\" de los proyectos de código abierto, permitiendo a los desarrolladores de código abierto capturar el valor que crean facilitando la entrada de capital a la comunidad de código abierto, todo sin alterar los principios fundamentales de cómo se desarrolla y utiliza el código abierto.\n\nLas empresas a menudo envuelven modelos de negocio alrededor del código abierto, generando ingresos directamente del trabajo de los desarrolladores benevolentes y también dependiendo de ellos para corregir errores a medida que ocurren. Las bases de código de código abierto ofrecen funcionalidad central plug-and-play para las empresas; sin embargo, las vulnerabilidades de software pueden representar un riesgo inmenso para las aplicaciones construidas sobre código abierto. Un gran ejemplo es un incidente reciente que involucra una vulnerabilidad crítica de seguridad en Log4j, un paquete de la [Apache Software Foundation](https://www.apache.org/) que se encontró en muchos software y servicios comerciales empleados por empresas y gobiernos. En noviembre de 2021, un investigador de seguridad que trabajaba para [Alibaba Group Holding Ltd.](https://www.alibabagroup.com/) reported vulnerability [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228), que recibió la puntuación base más alta posible de la Apache Software Foundation. Amit Yoran, Director Ejecutivo de [Tenable](https://www.tenable.com/) y director fundador del Equipo de Preparación para Emergencias Informáticas de los Estados Unidos (US-CERT), describió esta vulnerabilidad como “[\"la vulnerabilidad más crítica y grande de la última década\"](https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA)”. Se desató el pánico y los pocos voluntarios que mantenían este paquete se vieron públicamente criticados por el fallo. Tras abordar la indignación con un humilde llamado a la justicia, los sistemas se parchearon. Las empresas y los gobiernos eventualmente se dieron cuenta de que Log4j, un paquete utilizado por una amplia gama de sistemas críticos durante dos décadas, fue mantenido por unos pocos voluntarios no remunerados, los mismos héroes anónimos que entraron en acción a pesar de [los abusos de la industria](https://twitter.com/yazicivo/status/1469349956880408583) y trabajaron incansablemente para abordar la vulnerabilidad.\n\nLamentablemente, Log4j está lejos de ser el único ejemplo. core-js se descarga 30 millones de veces por semana como la base de cada aplicación de Node.js, pero también está apenas financiado, lo que podría obligar a su mantenedor principal [a alejarse del proyecto o incluso cambiar la licencia a código cerrado](https://www.thestack.technology/core-js-maintainer-denis-pusharev-license-broke-angry/). Recientemente, varios desarrolladores principales de bitcoin renunciaron, citando, entre otras razones, la falta de compensación financiera por su decisión.\n\n<figure><img src=\".gitbook/assets/xkcd-dependency (1).png\" alt=\"\"><figcaption><p>Figura 1 - Dependencia - Fuente:<a href=\"https://xkcd.com/2347/\">https://xkcd.com/2347/</a></p></figcaption></figure>\n\nHa habido múltiples intentos de proporcionar estructuras de incentivos, que típicamente involucran sistemas de patrocinio y recompensas. El patrocinio hace posible que los consumidores de código abierto donen a los proyectos que prefieren. Sin embargo, imagina el código abierto como una torre de ladrillos donde las capas inferiores son largamente olvidadas, pero aún mantenidas por ingenieros dedicados y en las que confían aún más desarrolladores. Solo los proyectos en la parte superior de la torre son típicamente conocidos y reciben patrocinio. Esta selección sesgada lleva a que los ladrillos esenciales que sostienen la torre no atraigan donaciones, mientras que los favoritos reciben más de lo que necesitan. Las recompensas permiten a los consumidores de proyectos proponer pagos para que los desarrolladores construyan características específicas, recompensando así solo a los proyectos por hacer cosas que pueden no estar en su mejor interés. Y, nuevamente, solo recompensando a los favoritos.\n\nEn tea, hemos visto demasiados proyectos de código abierto sufrir por estos intentos fallidos de apoyar a la comunidad de código abierto y hemos hecho de nuestra misión mejorar la sostenibilidad e integridad de la cadena de suministro de software permitiendo a los desarrolladores de código abierto capturar el valor que crean. \n\nEn este documento, proponemos tea — un sistema descentralizado para\n\n1. calcular y asignar una “[Prueba de Contribución](white-paper.md#proof-of-contribution)” cada proyecto de código abierto en relación con todo el ecosistema,\n2. asegurando que los proyectos de software de código abierto estén bien mantenidos,\n3. empoderando a los desarrolladores de código abierto con recompensas equitativas proporcionales a sus contribuciones en todo el ecosistema, logrado a través de la implementación del algoritmo de incentivos de tea en cada entrada del registro de tea, e\n4. incentivando a los participantes de la red a seguir prácticas de divulgación responsable de vulnerabilidades y errores.\n\n## Componentes\n\nUn desarrollador de software que construye una aplicación necesita cuatro cosas: un navegador, una terminal, un editor y un gestor de paquetes. De estos cuatro, el gestor de paquetes es lo que controla las herramientas y marcos que un desarrollador necesita para construir su producto. Esta capa es donde vemos el potencial para cambiar cómo se asegura y se recompensa el código abierto.\n\n### El Gestor de Paquetes\n\nEl gestor de paquetes sabe qué software de código abierto necesita un paquete o aplicación para funcionar, desde la cima de la torre hasta su base. Cada proyecto, junto con cada versión empaquetada, documenta meticulosamente todos los componentes esenciales y sus correspondientes versiones.\n\nSabe que la cima de la torre selecciona cuidadosamente sus dependencias, y que esta selección cuidadosa continúa hacia abajo. El gestor de paquetes está ubicado de manera única en el conjunto de herramientas del desarrollador para permitir una distribución de valor automatizada y precisa basada en la contribución real y práctica.\n\nProponemos un registro descentralizado e inmutable diseñado para distribuir valor basado en el “Prueba de Contribución” único del Protocolo tea, un algoritmo que determina la contribución de cada proyecto y su impacto en la utilidad y salud del sistema. El valor puede entrar en el gráfico en puntos ápice, como bibliotecas esenciales, y distribuirse a las dependencias de esos paquetes y sus dependencias de manera recursiva, ya que el registro conoce todo el graph de código abierto.\n\nAdemás, creemos que la información proporcionada por el Prueba de Contribución del protocolo debe estar disponible para que los desarrolladores evalúen si pueden confiar en un proyecto y su autor. Esta información puede basarse en la reputación, el reconocimiento de la comunidad, datos obtenidos de sistemas de identidad descentralizada (\"[DID](https://www.w3.org/TR/did-core/)\") otros gestores de paquetes o mecanismos de incentivos que potencialmente dependen de que los participantes de la red pongan valor en riesgo.\n\nPredecimos que la combinación de herramientas, información y recompensas de tea incentivará justamente a los desarrolladores, ayudando a asegurar la cadena de suministro de software, estimulando el crecimiento del software de código abierto y fomentando la innovación.\n\n### El Registro Descentralizado\n\nCada gestor de paquetes tiene su propio registro de paquetes, duplicando repetidamente los mismos metadatos. En algunos casos, este registro puede incluir [información que difiere del manifiesto del proyecto](https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/), permitiendo así que actores maliciosos potencialmente inyecten código nefasto sin que el usuario lo sepa. Es hora de que exista un registro único, integral y definitivo diseñado y gobernado por las comunidades que dependen de él. Este registro descentralizado e inmutable podría proporcionar seguridad, estabilidad y prevenir intenciones malévolas.\n\nInternet funciona con decenas de miles de componentes esenciales de código abierto. Es notable que hasta ahora, los incidentes causados por la eliminación de infraestructura esencial de código abierto hayan sido mínimos. El más famoso fue la [la eliminación de una dependencia de NPM left-pad](https://www.theregister.com/2016/03/23/npm\\_left\\_pad\\_chaos/) en 2016, que se propagó a sistemas de integración continua y despliegue continuo, dejando a los desarrolladores en la estacada durante días. Este evento demostró que Internet en sí está basado en sistemas de desarrollo frágiles. Otros ejemplos involucraron la participación activa o intencional de los mantenedores de paquetes saboteando sus paquetes populares (ver [colors.js and faker.js](https://fossa.com/blog/npm-packages-colors-faker-corrupted/), así como [node-ipc](https://www.lunasec.io/docs/blog/node-ipc-protestware/)), o actores maliciosos buscando beneficiarse pretendiendo ayudar a mantener paquetes y corrompiéndolos para robar, por ejemplo, claves privadas de Bitcoin (Ver [event-stream](https://github.com/dominictarr/event-stream/issues/116)), o paquetes maliciosos con errores intencionales de ortografía, también conocidos como “[typosquatting](https://en.wikipedia.org/wiki/Typosquatting)”, con la esperanza de engañar a los usuarios para que los instalen, por ejemplo [crossenv vs. cross-env NPM packages](https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry.html).\n\nLa integridad del software necesita ser garantizada a medida que la industria avanza hacia un futuro donde los activos digitales son parte del software. No podemos continuar dejándonos vulnerables a actores maliciosos que modifican el software.\n\nLa mayoría de las herramientas que llamamos gestores de paquetes no pueden garantizar que estos paquetes incorporados en las aplicaciones y dApps sean el código de código abierto sin alterar publicado por sus autores originales. [GitHub de Microsoft ha encontrado que el 17% de las vulnerabilidades en el software fueron plantadas con fines maliciosos](https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/), con algunas permaneciendo sin ser detectadas durante períodos prolongados (Ver [Webmin 1.890](https://threatpost.com/backdoor-found-in-utility-for-linux/147581/)).\n\nUn registro descentralizado global, complementado por un sistema de reputación y respaldado por incentivos diseñados para exponer a los actores maliciosos y recompensar a los buenos, puede proporcionar las garantías que las comunidades de desarrolladores han estado buscando para asegurar la cadena de suministro de software.\n\n### El Sistema de Almacenamiento\n\nLos proyectos de código abierto ofrecen una amplia gama de funcionalidades, algunas de las cuales pueden ser restringidas o no deseadas. La encriptación es un excelente ejemplo de esto. Un caso de uso crítico para la encriptación es el apoyo a la privacidad de las personas en todo el mundo. Sin embargo, la encriptación también puede ser utilizada con fines nefastos (ver [Phantom Secure](https://www.fbi.gov/news/stories/phantom-secure-takedown-031618), desmantelada por agencias de aplicación de la ley en marzo de 2018) o puede ser comprometida para apoyar actividades de las fuerzas del orden (ver [Operation Ironside (AFP), Operation Greenlight (Europol), and Operation Trojan Shield (FBI)](https://www.europol.europa.eu/media-press/newsroom/news/800-criminals-arrested-in-biggest-ever-law-enforcement-operation-against-encrypted-communication) donde el FBI operó una plataforma de comunicación “encriptada”, AN0M, y convenció a criminales a usar sus teléfonos “encriptados” para comunicación segura).\n\nLas amplias aplicaciones de la encriptación la han hecho un caso de uso perfecto para el software de código abierto y un gran ejemplo de que cualquier solución que almacene paquetes debe ser a prueba de manipulaciones y resistente a la censura. tea es un protocolo descentralizado que no pretende filtrar ni sancionar paquetes basados en su funcionalidad. Aunque la gobernanza de tea puede optar por eliminar paquetes maliciosos comprobados (ver la [sección de gobernanza](white-paper.md#governance) para más información), es crítico para el sistema tea conectarse con múltiples sistemas de almacenamiento, incluyendo aquellos descentralizados que demuestren que un paquete no está alterado y correctamente replicado. Los mantenedores de paquetes pueden elegir el sistema de almacenamiento más adecuado para sus necesidades para almacenar y distribuir sus paquetes de forma segura.\n\n## Resumen del Protocolo\n\nDiseñar un protocolo para recompensar las contribuciones de código abierto presenta desafíos formidables. El software de código abierto, al ser universalmente accesible, es susceptible a la mala atribución, apropiación y manipulación maliciosa. Sin embargo, la comunidad de código abierto ha demostrado consistentemente su voluntad de destacar a los buenos actores y exponer a los malos actores. Históricamente, la energía dedicada a revisar y comentar sobre las contribuciones de otros desarrolladores ha sido estrictamente voluntaria, a pesar de lo que consume tiempo y lo crucial que puede ser informar y defender los hallazgos.\n\nNuestra intención es crear un protocolo descentralizado asegurado por la reputación y los incentivos que mejoren la sostenibilidad e integridad de la cadena de suministro de software permitiendo a los desarrolladores de código abierto capturar el valor que crean de una manera sin confianza. Creemos que las recompensas adecuadas para las contribuciones de código abierto no pueden tener éxito sin un sistema de reputación y la capacidad de los miembros de la comunidad para comunicar sus hallazgos y apoyar (o disentir) un proyecto o el trabajo de un desarrollador. Además, debemos proporcionar a los desarrolladores herramientas para acceder y contribuir a este sistema de reputación. Herramientas que incluyan acceso visual y programable simple a la versión y reputación de todas las dependencias dentro de sus proyectos.\n\nLa transparencia en los tokens TEA en staking por los miembros de la comunidad para apoyar cada proyecto mejora la reputación de cada proyecto, de manera similar a cómo la cantidad de tokens que un mantenedor de paquetes pone en staking en su propio trabajo señala su compromiso con él. Estos puntos de datos combinados ayudarán a informar un sistema de reputación para todos los miembros de la comunidad y facilitarán la elección. Como el [event-stream package hack](https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502) no se realizó a través del paquete en sí, sino a través de una de sus dependencias, la visibilidad en todas las capas de dependencias será vital para construir este sistema sin confianza. Sin embargo, consideraciones como los costos de computación y transacción (“gas”) necesitarán tener prioridad a medida que el sistema se diseñe y construya.\n\nNuestro objetivo es recompensar tanto a los desarrolladores de Web 2.0 como a los de web3. Las complejidades y especificidades de cada pila hacen que el seguimiento de instalaciones de paquetes pueda fácilmente caer víctima de uno o más actores maliciosos. Esto incluye \"comprar\" instalaciones para inflar artificialmente los números. Un escenario aún peor sería introducir cambios fundamentales en la naturaleza del software de código abierto creando fricciones innecesarias con claves de licencia u otros mecanismos de seguimiento de implementación. Para proporcionar la cobertura más amplia, creemos que las recompensas no deben depender de una noción simplista de seguimiento de instalaciones, sino más bien de mecanismos de incentivo que fomenten la presentación de paquetes de calidad y la denuncia de paquetes nefastos o de alto riesgo. Por último, muchos paquetes dependen de dependencias comunes. Por ejemplo, [lodash](https://www.npmjs.com/package/lodash) tiene 176,308 dependientes de código abierto, mientras que [chalk](https://www.npmjs.com/package/chalk) tiene 100,247 dependientes o [log4js](https://www.npmjs.com/package/log4js/) tiene 3,809 dependientes. A medida que se crean más paquetes utilizando las mismas dependencias, ¿cómo aseguramos que las recompensas se distribuyan de manera justa y equitativa? ¿Cómo garantizamos que las dependencias más utilizadas sean recompensadas sin dejar de lado a los paquetes y desarrolladores nuevos o emergentes? ¿Cómo aseguramos que el sistema de incentivos no termine desviando a los desarrolladores de lenguajes de nicho para centralizarlos donde los incentivos son mejores? Pero también, como desarrolladores, ¿cómo identificamos los paquetes con más dependientes para construir alternativas - versiones más ligeras, más eficientes y mejor codificadas de estos paquetes?\n\nEn tea, creemos que la falta de visibilidad e incentivos ha impedido la evolución del software de código abierto. Respaldados por los incentivos y recompensas adecuados, más desarrolladores estarán en posición de construir, mejorar y aumentar el software de código abierto para el beneficio del mundo.\n\n### Prueba de Contribución\n\nEn este documento técnico, proponemos la \"Prueba de Contribución\", un novedoso mecanismo de consenso diseñado para cuantificar el impacto de todos los proyectos en todos los sistemas de código abierto.\n\nPrueba de Contribución asigna una puntuación dinámica, denominada teaRank del proyecto, basada en la orientación de cada proyecto de código abierto dentro de, y su utilización desde, el ecosistema de código abierto más amplio a lo largo del tiempo.\n\nCreemos que este enfoque beneficia al software fundamental alejado de la capa de aplicación (que tiende a ser la capa más visible para el público y atrae la mayor parte del interés) y extiende el mecanismo de recompensa para asegurar que todos los componentes de un proyecto, desde la cima del árbol hasta su base, sean recompensados por su contribución.\n\nPara calcular la puntuación de cada proyecto, teaRank se basa en los fundamentos establecidos por el algoritmo [Google's PageRank](https://en.wikipedia.org/wiki/PageRank). PageRank de Google es el componente definitorio del producto de búsqueda y se basa en la estructura similar a un graph de las páginas web. PageRank, en su esencia, es un algoritmo de distribución de probabilidad que asigna puntuaciones a los nodos en un graph, representando la probabilidad de que algo que navegue al azar por el graph llegue a un nodo particular. Este algoritmo es particularmente efectivo en una estructura de datos similar a un graph, como internet, porque cuantifica el impacto de cada nodo (o página web) basado en la cantidad y calidad de los bordes (enlaces) hacia él. Este algoritmo fue modificado con el tiempo para discernir mejor la topología de la web e identificar enlaces fraudulentos entre páginas web, permitiendo mitigar varios ataques.\n\nDado que la estructura de graph de internet y el registro descentralizado del Protocolo tea comparten notables similitudes, PageRank inicialmente pareció ser un enfoque prometedor para el análisis. Sin embargo, tras experimentación adicional, se hizo evidente que las estrategias anti-spam de PageRank eran menos efectivas cuando se aplicaban a código abierto.\n\nLa distinción clave radica en los metadatos del software de código abierto. A diferencia de las páginas web, la mayoría de los metadatos de paquetes de código abierto, como líneas de código y mensajes de commit, son generados por el usuario y susceptibles de ser falsificados. Los gestores de paquetes son vulnerables a campañas de spam, donde actores maliciosos inundan el registro con paquetes que contienen enlaces de phishing u otro contenido dañino. Los registros de los gestores de paquetes también pueden reflejar de manera inexacta las dependencias de proyectos específicos. Este problema, conocido como “[manifest confusion](https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/)” puede permitir a los actores maliciosos inyectar código nefasto o inflar artificialmente el impacto de dependencias de terceros, a menudo con fines nefastos.\n\nLa ardua tarea de identificar y abordar estos paquetes de spam generalmente recae en firmas de seguridad o individuos altruistas, ninguno de los cuales ofrece una solución escalable para combatir ataques de spam en código abierto.\n\nPrueba de Contribución es un algoritmo específicamente diseñado para abordar la identificación y aislamiento de paquetes de spam y asegurar que solo los proyectos impactantes reciban una recompensa justa. Los detalles del algoritmo de Prueba de Contribución serán el tema de un documento técnico dedicado.\n\n### Participantes de la Red\n\nEn este documento técnico, distinguimos a los participantes por sus contribuciones. Algunos pueden contribuir con código o verificar el código contribuido. Otros pueden apoyar a los desarrolladores y su reputación.\n\n#### Mantenedores de Paquete\n\ntea asume que los creadores de paquetes mantienen su trabajo. En este documento, nos referiremos a ellos como \"mantenedores de paquetes\".\n\nLos mantenedores de paquetes deben asegurarse de que su software continúe entregando un valor creciente a medida que evoluciona la industria. Son pilares de las comunidades de código abierto que necesitan ser empoderados y recompensados por sus contribuciones continuas. Sin embargo, un mantenedor de paquetes puede decidir discontinuar sus esfuerzos de mantenimiento o darse cuenta de que no pueden operar al ritmo que las expectativas de los usuarios del proyecto requieren. Para garantizar la continuidad, deben tener la capacidad de transferir el control de su proyecto a otro desarrollador o grupo de desarrolladores, nombrándolos como mantenedores y otorgándoles propiedad y control sobre las recompensas existentes y futuras asociadas con el proyecto.\n\nDe manera similar, un desarrollador puede decidir asumir el papel de mantenedor de paquetes al bifurcar el proyecto existente y registrar uno nuevo que mantendrán en adelante, convirtiéndose así en mantenedores de paquetes. Una vez registrado, los proyectos cuyo teaRank exceda un umbral definido por la gobernanza comienzan a recibir recompensas del Protocolo tea a través del algoritmo de Prueba de Contribución del protocolo, en paralelo con el proyecto bifurcado legado. A medida que la comunidad de código abierto se aleja del proyecto legado en favor de su nueva iteración, el algoritmo de Prueba de Contribución disminuirá gradualmente las recompensas asignadas al proyecto legado mientras aumenta las asignadas al nuevo proyecto bifurcado.\n\nEs esencial proporcionar a las comunidades de desarrolladores las herramientas adecuadas para determinar qué proyectos se están manteniendo y la reputación y calidad del trabajo de sus mantenedores pasados y presentes. Hemos visto con demasiada frecuencia cómo el trabajo de código abierto es manipulado y los esfuerzos de muchos arruinados por actores maliciosos. Aunque el trabajo de estos actores maliciosos generalmente se descubre y se remedia, a menudo no es hasta que se ha incurrido en daños significativos a través de pérdidas financieras o de datos. Tomemos como ejemplo el [event-stream npm package](https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502) que fue descargado más de 1.5 millones de veces por semana y en el que confiaban más de 1,500 paquetes cuando un hacker logró penetrar en el proyecto de código abierto, ganar la confianza de su autor original y modificar event-stream para que dependiera de un paquete malicioso que exfiltrara credenciales de billetera de bitcoin a un servidor de terceros. Aunque las herramientas pueden ayudar a detectar algunos de estos ataques, no siempre se pueden confiar, lo que crea una comunidad entera dependiente de la diligencia de los demás y la voluntad de compartir sus hallazgos.\n\nProponemos introducir incentivos a través del token TEA descrito en la sección \"[token TEA](white-paper.md#tea-token)\", para alentar a las comunidades de código abierto a informar sus hallazgos de manera constructiva, para que los mantenedores de paquetes puedan abordarlos antes de que sean explotados.\n\n#### Usuarios de Paquetes y miembros de la comunidad tea\n\nLos \"usuarios de paquetes\" son desarrolladores de software enfocados en resolver un problema específico. A menudo buscan en la comunidad de código abierto las herramientas que necesitan para experimentar rápidamente e iterar con poco o ningún costo, beneficiándose directamente del trabajo de los mantenedores de paquetes.\n\nCon más de 10 millones de paquetes accesibles a través de los 30 principales gestores de paquetes, la ausencia de una atribución de valor universal a los proyectos de código abierto puede transformar la selección de paquetes seguros y eficientes para el desarrollo en un esfuerzo arriesgado y desalentador. Sin medios discernibles para atribuir y medir el valor, ¿cómo seleccionan los usuarios de paquetes de manera eficiente paquetes seguros para su desarrollo?\n\nCreemos que el algoritmo de Prueba de Contribución del Protocolo tea, combinado con otros incentivos, puede proporcionar a los usuarios de paquetes la información que necesitan para seleccionar rápidamente y con reflexión la base de su propio proyecto.\n\n#### Participantes del Proyecto\n\nEn Web 2.0 y web3, un subconjunto de usuarios de paquetes, a menudo llamados \"patrocinadores\", ha optado por apoyar a los mantenedores de paquetes a través de donaciones u otras formas de remuneración; sin embargo, esto raramente ha sido el caso.\n\nEstos \"participantes del proyecto\" son organizaciones o usuarios de proyectos de código abierto que utilizan software de código abierto para construir sus productos comerciales, filántropos que buscan apoyar el ecosistema, o emprendedores que buscan financiar equipos para desarrollar componentes de un sistema más grande.\n\ntea propone extender las comunidades de participantes de proyectos de código abierto a toda la comunidad tea, ya sean organizaciones, desarrolladores, usuarios o entusiastas de la tecnología. El objetivo de tea es implementar mecanismos de incentivos descentralizados a través de casos de uso únicos del token TEA para que cualquier miembro de la comunidad tea contribuya a la sostenibilidad perpetua y el crecimiento continuo del código abierto. Los participantes del proyecto son libres de decidir qué proyectos o mantenedores de paquetes quieren apoyar en función de su trabajo, creencias o cualquier criterio y métrica que influya en su decisión. Además, los participantes del proyecto son libres de decidir cómo quieren apoyar estos proyectos.\n\nEl patrocinio puede ser un sistema efectivo para apoyar el desarrollo de código abierto; sin embargo, estos patrocinios no suelen extenderse a todas las dependencias. Esta limitación beneficia a los favoritos y obstaculiza la innovación y la construcción de software. Para esforzarse como la base del desarrollo de software, el código abierto debe empoderar a todos los desarrolladores, ya sean principiantes o expertos, en todas las capas de la torre.\n\n\n#### Usuarios de Paquetes y miembros de la comunidad tea\n\nLos \"usuarios de paquetes\" son desarrolladores de software enfocados en resolver un problema específico. A menudo buscan en la comunidad de código abierto las herramientas que necesitan para experimentar rápidamente e iterar con poco o ningún costo, beneficiándose directamente del trabajo de los mantenedores de paquetes.\n\nCon más de 10 millones de paquetes accesibles a través de los 30 principales gestores de paquetes, la ausencia de una atribución de valor universal a los proyectos de código abierto puede transformar la selección de paquetes seguros y eficientes para el desarrollo en un esfuerzo arriesgado y desalentador. Sin medios discernibles para atribuir y medir el valor, ¿cómo seleccionan los usuarios de paquetes de manera eficiente paquetes seguros para su desarrollo?\n\nCreemos que el algoritmo de Prueba de Contribución del Protocolo tea, combinado con otros incentivos, puede proporcionar a los usuarios de paquetes la información que necesitan para seleccionar rápidamente y con reflexión la base de su propio proyecto.\n\nParticipantes del Proyecto\nEn Web 2.0 y web3, un subconjunto de usuarios de paquetes, a menudo llamados \"patrocinadores\", ha optado por apoyar a los mantenedores de paquetes a través de donaciones u otras formas de remuneración; sin embargo, esto raramente ha sido el caso.\n\nEstos \"participantes del proyecto\" son organizaciones o usuarios de proyectos de código abierto que utilizan software de código abierto para construir sus productos comerciales, filántropos que buscan apoyar el ecosistema, o emprendedores que buscan financiar equipos para desarrollar componentes de un sistema más grande.\n\ntea propone extender las comunidades de participantes de proyectos de código abierto a toda la comunidad tea, ya sean organizaciones, desarrolladores, usuarios o entusiastas de la tecnología. El objetivo de tea es implementar mecanismos de incentivos descentralizados a través de casos de uso únicos del token TEA para que cualquier miembro de la comunidad tea contribuya a la sostenibilidad perpetua y el crecimiento continuo del código abierto. Los participantes del proyecto son libres de decidir qué proyectos o mantenedores de paquetes quieren apoyar en función de su trabajo, creencias o cualquier criterio y métrica que influya en su decisión. Además, los participantes del proyecto son libres de decidir cómo quieren apoyar estos proyectos.\n\nEl patrocinio puede ser un sistema efectivo para apoyar el desarrollo de código abierto; sin embargo, estos patrocinios no suelen extenderse a todas las dependencias. Esta limitación beneficia a los favoritos y obstaculiza la innovación y la construcción de software. Para esforzarse como la base del desarrollo de software, el código abierto debe empoderar a todos los desarrolladores, ya sean principiantes o expertos, en todas las capas de la torre.\n\nPara reforzar la sostenibilidad e integridad de la cadena de suministro de software y permitir que los desarrolladores de código abierto capturen el valor que crean, tea tiene como objetivo establecer mecanismos donde el apoyo beneficie a todos los aspectos de un proyecto. El apoyo de los patrocinadores se extenderá a través de las dependencias de un proyecto, desde la cima hasta la base del árbol. Esto coloca implícitamente la confianza en la capacidad del mantenedor de paquetes para tomar decisiones informadas sobre su pila, mejorando así su reputación.\n\n<figure><img src=\".gitbook/assets/figure-2.png\" alt=\"\"><figcaption><p>Figura 2 - Distribución de recompensas a través de las dependencias</p></figcaption></figure>\n\n#### Catacatadores de tea\n\nA medida que se lanzan nuevos proyectos o nuevas versiones de proyectos existentes, la validez del trabajo necesita ser demostrada de manera comprobable. Esta información es crítica para que los usuarios de paquetes decidan si pueden confiar en el paquete y sus mantenedores. Dentro del Protocolo tea, esta función es proporcionada por los \"catacatadores de tea\".\n\nLos catacatadores de tea, típicamente, son desarrolladores de software experimentados dispuestos a dedicar parte de su tiempo a verificar las afirmaciones asociadas con un paquete (funcionalidad, seguridad, [versionado semántico](https://semver.org/) precisión de la licencia, etc.) y apostar tanto su reputación como tokens TEA para demostrar el resultado de su investigación y respaldar sus revisiones. En el Protocolo tea, \"apostar tu tea\" es el proceso de bloquear tokens TEA para respaldar tus revisiones, potencialmente ganando recompensas o enfrentando penalizaciones basadas en el consenso sobre la calidad de tus revisiones. Los catacatadores de tea también tienen la opción de informar confidencialmente sobre errores o vulnerabilidades a los mantenedores de paquetes. Los informes válidos resultan en recompensas del tesoro del proyecto, mientras que los informes inválidos llevan a la pérdida de la apuesta del catacatador de tea. Por último, si los mantenedores de paquetes ignoran estos problemas reportados, desencadena penalizaciones, o \"reducciones\", para el tesoro del proyecto.\n\nAl igual que los partidarios del proyecto, los catacatadores de tea pueden influir en la reputación de un proyecto y de un mantenedor de paquetes; sin embargo, su impacto es mayor dado su papel en validar la seguridad, funcionalidad y calidad de un proyecto. Los catacatadores de tea también necesitarán construir su reputación para respaldar sus afirmaciones. La calidad de su trabajo y los tokens TEA que ponen en riesgo al apostar sus revisiones combinados con otras fuentes de datos externas construirán la reputación de cada catacatador de tea, aportando más valor a su trabajo. Ver la sección \"[Reputación del Paquete y del Mantenedor del Paquete](white-paper.md#package-and-package-maintainer-reputation)\" para más detalles sobre los mecanismos utilizados para influir en la reputación de un proyecto y de un mantenedor de paquetes.\n\n### Registro de Proyecto y Recompensas de Prueba de Contribución\n\nEl registro de un lanzamiento de proyecto requiere que ocurran múltiples transacciones de manera atómica. Específicamente:\n\n* El mantenedor del paquete debe registrar el proyecto en el registro descentralizado,\n* El Protocolo tea debe instanciar un tesoro del proyecto propiedad, controlado y configurado por los mantenedores de paquetes de acuerdo con las reglas definidas por los mantenedores de paquetes, y\n* El Protocolo tea debe registrar el nombre único del tesoro en el Servicio de Nombres de Ethereum, o ENS, simplificando así todas las interacciones de los usuarios con el tesoro.\n\nEl fracaso de cualquiera de las operaciones resultará en que el protocolo vuelva a su estado anterior.\n\nras el registro exitoso de un proyecto con un teaRank que supera un umbral definido por la gobernanza, el Protocolo tea inicia la distribución de recompensas de Prueba de Contribución al tesoro del proyecto. Sugerimos distribuir estas recompensas siguiendo una curva predeterminada desde un grupo predefinido de tokens controlado por el Protocolo tea y asignado desde el suministro total de tokens TEA.\n\nSe requiere que los mantenedores de paquetes refuercen la reputación y confiabilidad de su proyecto apostando constantemente una parte de las recompensas de Prueba de Contribución recibidas por el tesoro del proyecto. Por cada staked token, los participantes de la red recibirán un “staked TEA” no transferible, o stTEA, en una relación de 1:1, para participar en la gobernanza del Protocolo tea. De acuerdo con las reglas del protocolo, estas recompensas apostadas, y sus correspondientes stTEA, pueden estar sujetas a reducción (“reducción”) o redistribución si los mantenedores de paquetes no abordan errores o vulnerabilidades.\n\nPor último, el no mantener la proporción mínima del tesoro apostado definida en las reglas de gobernanza resultará en la suspensión de la distribución de recompensas de Prueba de Contribución al proyecto. En su lugar, estas recompensas se redistribuirán entre los proyectos que cumplan con las normas.\n\n### Reputación del Paquete y del Mantenedor del Paquete\n\nUn sistema de reputación que depende únicamente de la contribución económica del autor no proporciona suficiente protección al usuario y puede estar sujeto a ataques Sybil, donde un individuo crea múltiples representaciones de sí mismo para dejar un gran volumen de reseñas positivas sobre su trabajo, engañando a los usuarios para que crean que su trabajo fue revisado y aprobado por muchos.\n\nExisten varias metodologías disponibles para prevenir ataques Sybil, algunas de las cuales son descritas por Nitish Balachandran y Sugata Sanyal en “[A Review of Techniques to Mitigate Sybil Attacks](https://arxiv.org/abs/1207.2617/)”. Como tea es un protocolo descentralizado, usar un sistema de certificación de confianza que dependa de una autoridad centralizada de emisión de certificados sería contrario a su esencia. Proponemos enfocarnos en enfoques descentralizados para la mitigación de ataques Sybil y, más específicamente, en metodologías que dependan de un gran grupo de participantes de la red incentivados para evaluar y representar públicamente la reputación de cada paquete y su mantenedor.\n\nSimilar a la producción de bloques en una blockchain de prueba de participación, donde los nodos no productores pueden validar el trabajo de otros y, cuando sea necesario, destacar una violación de las reglas de la red, lo que lleva a una penalización del actor malicioso a través del slashing (destrucción de una parte de su staking), proponemos un sistema donde terceros, como los catacatadores de tea, puedan revisar los paquetes producidos por los mantenedores de paquetes y ser incentivados para actuar en el mejor interés de la comunidad de software de código abierto y sus usuarios, así como reconocer el buen comportamiento y penalizar el mal comportamiento. Este sistema debe ser resistente a Sybil y evitar que los poseedores de grandes cantidades de tokens influyan materialmente en el protocolo o en la reputación de paquetes específicos. Creemos que este enfoque está más alineado con el código abierto, proporcionando un sustrato más fértil para fomentar la adopción y la confianza, y facilitar en última instancia el crecimiento de tea.\n\nAdemás, a medida que la reputación de cualquier miembro de la comunidad tea alcance hitos clave, se le puede otorgar acceso a partes elevadas del protocolo.\n\n### Revisión de Paquetes por Terceros\n\nLa revisión de paquetes por terceros es un componente esencial en la construcción de reputación y la seguridad de la cadena de suministro de software. Sin embargo, las revisiones de terceros vienen con su propio conjunto de amenazas únicas, incluyendo los ataques Sybil mencionados anteriormente.\n\nLa tecnología blockchain, y más explícitamente el staking, ofrece una oportunidad única para que tea aborde este desafío. Aunque las direcciones de billetera pueden estar disponibles en cantidades infinitas, no es el caso con los tokens TEA, cuyo suministro total se espera sea de 10 mil millones. Además, cada acción realizada por los desarrolladores, como enviar, verificar o staking paquetes, contribuirá a su reputación, creando así un perfil único que cada desarrollador puede usar tanto para contribuir a la comunidad tea como para participar en la gobernanza de tea.\n\nAl requerir que los revisores realicen staking de TEA tokens e incurran en el riesgo de perder una parte de su apuesta si resultan actuar en contra del interés de la red o ser un actor malicioso, los terceros pueden proporcionar credibilidad adicional a un paquete y recibir una recompensa, en forma de tokens TEA.\n\nTambién proponemos extender el sistema de reputación a los terceros que realizan la verificación independiente de los paquetes, los catacatadores de tea. La finalización de una revisión positiva requerirá que ocurran dos operaciones de manera atómica:\n\n* La presentación de la revisión de código, firmada por el catacatador de tea y accesible públicamente para todos los miembros de la comunidad, junto con\n* El acto de staking del paquete, para fundamentar su revisión.\n\nLa finalización de una revisión negativa que incluye una o más vulnerabilidades críticas requerirá que los catacatadores de tea primero contacten al mantenedor del paquete usando un protocolo de mensajería para notificarles sobre la vulnerabilidad y permitirles abordar el problema de manera oportuna. Tras la expiración del período definido por la gobernanza asignado al mantenedor del paquete para abordar su vulnerabilidad o a medida que el paquete corregido esté disponible, el mismo protocolo de mensajería se utilizará para notificar a los usuarios y probadores de este paquete (incluyendo dependientes) que se ha identificado una vulnerabilidad, y con suerte abordado, para que sepan actualizar su aplicación o dependencias. Para desincentivar la pérdida de tiempo de los desarrolladores, la comunicación entre los catacatadores de tea y los mantenedores de paquetes requerirá que los catacatadores de tea apuesten tokens TEA.\n\nTras completar ambas operaciones, los catacatadores de tea recibirán un NFT como evidencia de su trabajo en el paquete y versión específica del paquete. La acumulación de NFTs combinada con la proporción de staking de cada uno de los paquetes revisados e información extraída de sistemas externos informará la reputación de un catacatador de tea. A medida que su reputación alcance hitos clave, los catacatadores de tea pueden ganar acceso a partes elevadas del protocolo o recompensas aceleradas del protocolo, según lo decida la gobernanza de tea.\n\n### Paquetes Desactualizados o Corruptos\n\nLa misión de tea es mejorar la sostenibilidad e integridad de la cadena de suministro de software permitiendo a los desarrolladores de código abierto capturar el valor que crean; sin embargo, las recompensas deben ser proporcionales a los esfuerzos desplegados por los mantenedores de paquetes y los catacatadores de tea. Los paquetes poco mantenidos, desactualizados o corruptos son claras indicaciones de que los mantenedores de paquetes no están cumpliendo con las expectativas de la comunidad o no están entregando en la confianza y el apoyo impresionados sobre ellos a través del staking de paquetes. Otra manifestación de paquetes desactualizados puede ser el uso continuado de un lenguaje heredado o una versión heredada de lenguajes multi-versión. Paquetes que permanecen desactualizados o corruptos durante demasiado tiempo indican que los catacatadores de tea necesitan revisar regular y consistentemente el trabajo de los mantenedores de paquetes.\n\nLos catacatadores de tea juegan un papel pivotal en las comunidades de código abierto, ya que sus revisiones y reclamaciones asociadas pueden influir en los usuarios de paquetes, guiándolos hacia o alejándolos de paquetes específicos. Para garantizar que las revisiones puedan ser confiables de manera continua, proponemos un mecanismo por el cual las revisiones publicadas por los catacatadores de tea deben estar asociadas con tokens TEA apostados. Los paquetes desactualizados o corruptos pueden ver una parte de su tesoro reducida, mientras que otra parte se envía al catacatador de tea que primero reconoció la falta de mantenimiento de cualquier paquete.\n\nA medida que los paquetes ganan popularidad y uso, con más aplicaciones y potencialmente sistemas críticos dependiendo de ellos, debemos incentivar a los desarrolladores a informar discretamente los defectos al mantenedor del paquete y animar a los mantenedores de paquetes a abordar tales defectos antes de que puedan ser explotados. En consecuencia, proponemos que cualquier revisión negativa que describa un defecto, como una vulnerabilidad de día cero o el uso de una dependencia desactualizada y que permanezca abierta más allá de un período de gracia definido por la gobernanza, debe considerarse un fallo por parte del mantenedor del paquete y estar sujeto a las mismas penalizaciones, con el primer catacatador de tea que informe del defecto recibiendo una parte de los tokens reducidos.\n\nLo mismo se puede decir de los partidarios del paquete que apostaron su reputación y tokens TEA en el trabajo de mantenedores de paquetes delincuentes y recibieron recompensas por ello. Como no lograron identificar la falta de mantenimiento o eligieron continuar apoyando el paquete independientemente, proponemos que todas las actividades de reducción se extiendan a los partidarios del paquete.\n\nLa distribución a todos los catacatadores de tea podría basarse en la antigüedad de su revisión y la cantidad de tokens TEA que apostaron por su revisión.\n\n## Token TEA\n\nTEA es un token criptográfico que sirve como clave de acceso a ciertas partes y características designadas del Protocolo tea.\n\nLos poseedores del token TEA tienen la capacidad de:\n\n* Registrar sus paquetes;\n* Apoyar paquetes apostando tokens TEA en paquetes específicos;\n* Contribuir a la seguridad de la cadena de suministro de software desafiando paquetes y realizando revisiones para informar sobre errores y/o vulnerabilidades.\n\nComo se ha discutido, el Protocolo tea desbloquea la economía de código abierto y crea valor para los constructores, mantenedores y usuarios finales del software empresarial. En última instancia, el valor capturado por el Protocolo tea se acumula de nuevo a los poseedores de tokens a medida que la comunidad escala, creando un ciclo de retroalimentación que incentiva aún más la participación.\n\n### Recompensando a los Desarrolladores de Código Abierto\n\nEsperamos que los mecanismos de Prueba de Contribución y staking de tea fomenten el crecimiento del código abierto al empoderar a sus participantes con los recursos que necesitan para seguir su pasión sin trabas.\n\nComo se detalla en \"[Registro de Proyecto y Recompensas de Prueba de Contribución](white-paper.md#project-registration-and-proof-of-contribution-rewards)\", los proyectos registrados en el Protocolo tea y con un teaRank que supere un umbral definido por la gobernanza recibirán recompensas de Prueba de Contribución en forma de tokens TEA del Protocolo tea. Esta distribución persistirá siempre y cuando el paquete cumpla con las reglas del protocolo. Específicamente, el paquete deberá mantener un teaRank por encima del umbral definido por la gobernanza y los mantenedores del paquete tendrán que contribuir a la reputación y confiabilidad de su proyecto apostando continuamente una parte de las recompensas de Prueba de Contribución recibidas por el tesoro del proyecto. El incumplimiento de estas reglas resultará en la suspensión de la distribución de recompensas de Prueba de Contribución y la redistribución de futuras recompensas entre proyectos que cumplan con las normas.\n\nLas dependencias pueden afectar significativamente la fiabilidad y seguridad de un paquete, y la ausencia de registro para las dependencias de un paquete debe ser vista como un riesgo potencial. Los mantenedores de paquetes, siendo tanto validadores como usuarios de estas dependencias, están en una posición privilegiada para conectar con los mantenedores de esas dependencias. Pueden animarlos a registrar sus proyectos en tea, haciéndolos así sujetos a la supervisión de los catacatadores de tea y elegibles para recompensas asociadas. Para fomentar este compromiso comunitario dirigido a mejorar el sistema de reputación, recomendamos que cualquier paquete con dependencias que no estén registradas en el Protocolo tea vea una fracción de sus recompensas de Prueba de Contribución quemadas. Esta quema sería proporcional al número y contribución, cuantificada en teaRank, de cada dependencia no registrada, y continuaría mientras estas dependencias permanezcan sin registrarse.\n\nNumerosos casos han demostrado que fuertes incentivos pueden tentar a actores maliciosos a comprometer el software de código abierto. La mayoría de la infraestructura crítica de Internet funciona con código abierto, y la carrera para encontrar exploits y otras vulnerabilidades está en marcha. En tea, creemos que los mantenedores de paquetes no son los que deberían ser culpados (aunque a menudo lo son).\n\nLos incentivos del Protocolo tea abordan este problema asegurando una distribución justa y equitativa de incentivos. Un paquete como lodash con más de 176k dependientes es un pilar del desarrollo de código abierto, y sus mantenedores merecen ser recompensados proporcionalmente. Sin embargo, un sistema de recompensas basado únicamente en el número de dependientes impediría a los innovadores perturbar estos monopolios a menos que estén suficientemente financiados por terceros o ya hayan acumulado suficientes recursos para autofinanciarse. Este enfoque probablemente llevaría a un número decreciente de contribuyentes, resultando en lo opuesto a lo que tea pretende.\n\nPara abordar esta limitación y empoderar a cada poseedor de tokens TEA con la capacidad de apoyar a los mantenedores de paquetes, también recomendamos que una fracción definida por la gobernanza de todas las recompensas de staking recibidas por todos los participantes de la red se dirija hacia el tesoro del paquete apostado, junto con sus dependencias.\n\n### Apostando para Asegurar la Cadena de Suministro de Software\n\nEl staking puede ser una metodología efectiva para apoyar un sistema descentralizado de reputación. Sin embargo, para facilitar la seguridad de la cadena de suministro de software, el sistema de distribución de incentivos de tea debe considerar cuidadosamente la proporción de staking de cada paquete y ajustar el incentivo de cada paquete en consecuencia.\n\nPara reducir el riesgo de que un pequeño número de paquetes utilizados como dependencias en muchas aplicaciones recolecten la mayoría de las recompensas de staking, recomendamos la implementación de una proporción óptima de staking, similar al enfoque descrito en la [investigación producida por la web3 Foundation](https://research.web3.foundation/Polkadot/overview/token-economics).\n\nCuando un paquete excede la proporción óptima de staking definida por la gobernanza, la cantidad total de recompensas de staking asignadas al paquete permanecerá fija, independientemente del número de tokens TEA apostados al paquete. Esta medida, diseñada para desincentivar a los partidarios del paquete y a los catacatadores de tea de seguir apostando paquetes altamente apostados, resultará en una disminución lineal de las recompensas de staking recibidas por cada partidario del paquete.\n\nUn enfoque basado en curvas, como el descrito en la investigación de la web3 Foundation, ralentizaría la reducción del fondo de recompensas de staking asignado al paquete, continuando así quitando a paquetes menos apostados e introduciendo externalidades negativas al otorgar más influencia a los grandes poseedores de tokens sobre la distribución del fondo de recompensas de staking.\n\nEl diseño lineal recomendado debería permitir que los paquetes menos apostados sean más atractivos tanto para los partidarios del paquete como para los catacatadores de tea. También puede incentivar a los desarrolladores experimentados a construir alternativas a paquetes altamente apostados, creando una oportunidad para que la comunidad tea equilibre el apoyo al software existente y promueva la innovación. En su diseño inicial, la proporción de staking se calculará utilizando el suministro circulante. La comunidad tea puede alterar este diseño para mejorar aún más la escalabilidad del sistema.\n\nAsí como es necesario recompensar a los buenos actores, también es necesario identificar y penalizar a los malos actores. El software de código abierto ofrece muchas oportunidades para que los malos actores creen puntos de dolor y riesgos reputacionales para toda una comunidad de desarrolladores. Desde la apropiación indebida de trabajo hasta la alteración y redistribución de paquetes de software, o la inyección de código nefasto, la guerra entre buenos y malos actores continúa, a menudo con malos actores bien financiados que ven la contaminación de paquetes de código abierto como una oportunidad para beneficiarse financieramente. Las desventajas han sido relativamente mínimas, con paquetes potencialmente prohibidos de los estantes digitales o sujetos a una mala reputación.\n\nPara abordar directamente a los actores maliciosos e intensificar las repercusiones por acciones contrarias al código abierto, recomendamos implementar el mecanismo de slashing detallado en las secciones  “[Revisión de Paquetes por Terceros](white-paper.md#package-review-by-third-parties)” and “[Paquetes Desactualizados o Corruptos](white-paper.md#outdated-or-corrupt-packages)” sections.\n\nA medida que los catacatadores de tea evalúan y analizan el código en paquetes recién enviados, sugerimos que los catacatadores de tea reciban las herramientas e incentivos para identificar y resaltar código nefasto para que:\n\n* los usuarios de paquetes puedan ser conscientes de los riesgos, y\n* los mantenedores de paquetes y los partidarios de paquetes sean penalizados por enviar o apoyar código nefasto.\n\nEn ese sentido, para todas las revisiones negativas evidenciadas realizadas según las reglas de la red y que hayan sido abordadas por el mantenedor del paquete dentro del período definido por la gobernanza, el mantenedor del paquete no debería incurrir en ninguna penalización, a diferencia de los partidarios del paquete o los catacatadores de tea que proporcionaron una revisión positiva del paquete en cuestión.\n\nPara las revisiones negativas realizadas según las reglas de la red y que el mantenedor del paquete no haya abordado dentro del período definido por la gobernanza, una fracción de los tokens TEA en staking por el tesoro del proyecto, los partidarios del paquete y los catacatadores de tea anteriores será reducida y enviada al catador de tea que identificó el error o vulnerabilidad. Otra fracción será bloqueada en un fondo de seguro controlado por la gobernanza de tea. La gobernanza de tea establecerá políticas y reglas en estrecha colaboración con la comunidad para distribuir los contenidos del fondo a los afectados por vulnerabilidades. El protocolo distribuirá una tercera fracción de los tokens TEA reducidos entre todos los catacatadores de tea que contribuyeron a la revisión negativa.\n\nEl staking y el slashing son componentes vitales del sistema de incentivos y penalizaciones del Protocolo tea. Se requiere que los mantenedores de paquetes apuesten una parte del tesoro de su proyecto, asegurando que tengan una participación sustancial en riesgo en caso de que descuiden abordar errores o vulnerabilidades. Los usuarios de paquetes, partidarios y catacatadores de tea también pueden hacer staking de tokens TEA para contribuir a la reputación de un paquete o mantenedor de paquetes y participar activamente en el protocolo para mantener la sostenibilidad e integridad de la cadena de suministro de software.\n\nLa gobernanza está estrechamente vinculada a este compromiso activo. Por cada token TEA en staking, los participantes reciben \"staked TEA\" no transferible (stTEA) en una relación de 1:1, lo que les permite participar en la gobernanza del Protocolo tea. Las recompensas apostadas y sus correspondientes tokens stTEA pueden enfrentar reducción (slashing) o redistribución si no se siguen las reglas del protocolo, reforzando la responsabilidad dentro del ecosistema.\n\n### Distribución del Suministro de Tokens TEA\n\nLa mayoría de los tokens TEA creados por el protocolo se utilizan como incentivos para animar a los mantenedores de paquetes, usuarios y partidarios a realizar actividades que aporten valor a la red descentralizada. La distribución de tokens TEA a varios interesados dentro del protocolo está dictada por un \"calendario de distribución\".\n\nLos incentivos de la red serán distribuidos directamente por el Protocolo tea, en forma de tokens TEA, a cuatro grupos de interesados:\n\n* Mantenedores de Paquetes;\n* Usuarios de Paquetes (que incluyen a todos los miembros de la comunidad tea);\n* Partidarios del Proyecto; y,\n* Catacatadores de tea.\n\nLos tokens TEA también se utilizarán para apoyar paquetes y asegurar la cadena de suministro de software a través del staking, incluyendo el derecho de desafiar un paquete realizando una revisión e informando errores o vulnerabilidades, recompensar a los desarrolladores de código abierto de proyectos registrados y participar en la gobernanza del Protocolo tea.\n\nSe recomienda que un suministro máximo de 10 mil millones de tokens sea distribuido entre todos los miembros de la comunidad tea como se describe a continuación:\n\n<figure><img src=\".gitbook/assets/Token Allocation-Updated.svg\" alt=\"\"><figcaption><p>Figura 3 - Distribución de tokens del suministro máximo</p></figcaption></figure>\n\nAproximadamente el 51.4% del suministro máximo de tokens debería asignarse a \"Ecosistema y Gobernanza\", que incluye incentivos para que los proyectos de código abierto se unan y mantengan su base de código, así como recompensas por contribuir a votaciones descentralizadas y consenso a través del tea DAO. Los tokens asignados a \"Ecosistema y Gobernanza\" deben distribuirse como recompensas de Prueba de Contribución, recompensas de staking y otros tipos de incentivos centrados en el desarrollador.\n\nAproximadamente el 18.6% del suministro máximo de tokens debería asignarse al \"Desarrollo del Protocolo\" para garantizar la sostenibilidad y la evolución continua del Protocolo tea. Aproximadamente el 12.7% debería reservarse para \"Partidarios y Asesores Iniciales\". Aproximadamente el 11.0% debería reservarse para una venta privada, el 3.0% para una venta pública, mientras que el 3.2% restante debería asignarse para apoyar la liquidez del mercado una vez que ocurra un evento de generación de tokens.\n\nTokenomics detallados, incluyendo una Distribución de Tokens integral y un calendario de Emisiones serán el tema de un documento dedicado.\n\n## Gobernanza\n\nLa gobernanza es crítica para el desarrollo, la sostenibilidad y la adopción de cualquier sistema distribuido.\n\nProponemos que el Protocolo tea incorpore mecanismos de gobernanza que permitan a los contribuyentes activos que han puesto sus tokens TEA en staking proponer y votar sobre cambios de parámetros críticos no financieros. El proceso de votación estaría ponderado por la propiedad de tokens stTEA y la reputación individual.\n\nLos parámetros del protocolo podrían incluir la prioridad para apoyar gestores de paquetes específicos o introducir nuevas características o funciones del protocolo, así como el impacto de factores externos en la reputación de usuarios y paquetes. Esta funcionalidad asegurará que los parámetros críticos puedan evolucionar y optimizarse a lo largo del tiempo por miembros activos de la comunidad tea. Anticipamos que la gobernanza se lanzará con una estructura simple y se expandirá progresivamente a medida que el sistema tea madure, facilitando la adopción y garantizando una descentralización progresiva.\n\nAlgunos parámetros del sistema pueden no estar sujetos a la gobernanza o admitir cambios de alta frecuencia para reducir la superficie de ataque representada por la gobernanza. Una transición progresiva de parámetros a una gobernanza abierta y descentralizada asegurará la estabilidad y previsibilidad del sistema.\n\n## Extensibilidad de Terceros\n\nMientras construimos las herramientas iniciales para encender el tan esperado apoyo a las comunidades de código abierto, creemos que parte de nuestra misión es asegurar que terceros puedan extender el conjunto total de herramientas. Además de proporcionar la infraestructura para que los desarrolladores construyan extensiones al protocolo, incluyendo nuevas formas de innovar y apoyar aún más a los desarrolladores de código abierto, nuestros planes incluyen la posibilidad de que otros gestores de paquetes contribuyan al protocolo.\n\nLos sueños y esfuerzos de los desarrolladores de código abierto han construido la innovación que respalda nuestra vida cotidiana. Esperamos descubrir los nuevos usos y extensiones para el Protocolo tea propuestos por la comunidad tea.\n\n## El Futuro y Posibles Esfuerzos de la Comunidad\n\nA medida que el sistema tea madure, prevemos que la comunidad decida y contribuya a alteraciones y extensiones del sistema tea a través de la gobernanza. A continuación, presentamos algunas ideas que creemos que pueden inspirar a algunos, sin embargo, no garantizamos ningún rendimiento futuro.\n\n### Mayoristas de tea\n\nLas comunidades de software de código abierto son vibrantes y constantemente buscan innovar y entregar valor. Esta dedicación y altruismo llevan a la construcción constante de nuevo software y paquetes, cada uno utilizando dependencias. Como resultado, anticipamos que el mapa de dependencias evolucione constantemente, llevando a cambios frecuentes en la proporción de staking y recompensas. En el futuro, la comunidad tea puede proponer el desarrollo de un sistema diseñado para monitorear dinámicamente la proporción de staking para cada proyecto y reequilibrar cómo los partidarios del proyecto apuestan sus tokens TEA basándose en sus propios criterios.\n\n### Regalías por Transferencia de Paquetes\n\nReconocemos que los mantenedores de paquetes pueden decidir transferir su flujo de recompensas a uno o más desarrolladores. La gobernanza de tal transferencia debe permanecer como la decisión del mantenedor del paquete y sus socios, sin interferencia de tea. Se necesitarán herramientas para que dicha transferencia sea total o parcial (tal vez a través de solo una porción de las recompensas siendo redirigidas a uno o más desarrolladores, mientras que las recompensas restantes continúan fluyendo al mantenedor del paquete original) y para que las recompensas de staking fluyan a través de una única cuenta controlada por un único participante de la red, múltiples participantes de la red, o distribuidas automáticamente entre múltiples cuentas usando proporciones estáticas o dinámicas.\n\n### Distribución de Recompensas Entre Varios Mantenedores\n\nEl mantenimiento de un paquete puede depender del trabajo de un equipo o más de desarrolladores. Antes de que comiencen a fluir las recompensas, los equipos deberían considerar automatizar la distribución del valor entre ellos mismos. Cómo ocurre la distribución debe ser decidido por los propios mantenedores, ya que están en la mejor posición para evaluar quién contribuyó y cómo deben ser recompensados.\n\nPara lograrlo, cada equipo (o equipos) podría configurar su propia organización autónoma descentralizada ([DAO](https://ethereum.org/en/dao/)) y automatizar la distribución o desplegar sistemas más complejos para determinar la distribución de valor adecuada basada en factores externos como un voto de todos los miembros de la DAO, o distribuciones basadas en tiempo en función de la contribución continua, la finalización exitosa de recompensas, etc.\n\n### Manejo de Paquetes \"forks\"\n\nCreemos que los forks son esenciales y en gran medida subutilizados. Los forks pueden ser una herramienta efectiva para desarrollar paquetes que compiten en funcionalidad, rendimiento, seguridad e incluso atención. Por útiles que puedan ser, los forks deben reconocer los esfuerzos originales. A través del trabajo futuro o posibles contribuciones, la comunidad tea puede mejorar el sistema para requerir que los forks sean declarados, tal vez incluso detectados cuando un proyecto se registre. Los forks no declarados revelados por los catacatadores de tea pueden resultar en una reducción de una parte de la apuesta del tesoro del fork, transferida al mantenedor del paquete original o enviada a los catacatadores de tea que revelaron el fork.\n\n### Dependencias de Ejecución vs. Construcción\n\ntea puede no distinguir entre dependencias de construcción y dependencias de ejecución al distribuir recompensas de Prueba de Contribución en el lanzamiento. Sin embargo, si la comunidad tea siente fuertemente acerca de hacer tal distinción, la comunidad tea puede proponer mejoras al algoritmo de distribución de recompensas para tener en cuenta la criticidad de cada dependencia y su contribución al valor individual de los paquetes que dependen de ellas. Estas propuestas serían votadas e implementadas según la decisión de la comunidad.\n\n### Recompensas Basadas en el Uso\n\nA medida que se construyan más aplicaciones utilizando proyectos registrados con tea, la comunidad puede aumentar el algoritmo de recompensas para que la asignación pueda ser influenciada por conjuntos de datos externos atestiguados como el uso. Esta actualización al mecanismo de recompensas podría permitir una mayor asignación de recompensas de tokens TEA hacia paquetes con el uso más alto, respetando aún las restricciones de la proporción de staking descrita en la sección de tokens TEA. Los mantenedores de paquetes podrían usar un enfoque similar para distribuir recompensas a través de sus dependencias basado en la lógica transparente de su elección. Tenga en cuenta que toda la información utilizada para afectar la distribución de recompensas entre paquetes y dependencias en el sistema tea necesitará ser comprobablemente confiable.\n\n## Agradecimientos\n\nEste documento técnico no existiría sin el apoyo y la dedicación de muchos teaófilos. Los autores desean reconocer a Jacob Heider, Jadid Khan, Josh Kruger y Shane Molidor por su contribución a la tokenomía, Sanchit Ram por su contribución al algoritmo teaRank, y a los muchos individuos discretos que ofrecieron voluntariamente su tiempo para proporcionar retroalimentación sobre el contenido de este documento.\n\n## Glosario de Términos\n\n| Término     | Definición                                                                                                                                                                                        |\n| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Leaf     | TLa denominación más pequeña del token TEA. Un \"leaf\" corresponde a una quintillonésima parte (10^−18) de un TEA.                                                                                            |\n| Slashing | La acción de penalizar a los que hacen staking en respuesta a comportamientos contrarios a las reglas del protocolo.                                                                                                       |\n| Staking  | \tLa acción de bloquear tokens TEA para respaldar tu reclamo y recibir recompensas (o penalizaciones) basadas en el consenso sobre la validez de tu reclamo.                                                |\n| stTEA    | Token “TEA en staking” no transferible o “stTEA” recibido por los participantes de la red por cada token apostado en una relación de 1:1. stTEA puede utilizarse para participar en la gobernanza del Protocolo tea |\n| teaRank  | Puntuación de impacto dinámica asignada a cada proyecto por el algoritmo “Prueba de Contribución” del protocolo.                                                                                              |\n\n## Referencias\n\n1. [https://creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/)\n2. [https://archive.org/details/historyofmodernc00ceru](https://archive.org/details/historyofmodernc00ceru)\n3. [https://nvd.nist.gov/vuln/detail/CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228)\n4. [https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA](https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA)\n5. [https://twitter.com/yazicivo/status/1469349956880408583](https://twitter.com/yazicivo/status/1469349956880408583)\n6. [https://www.thestack.technology/core-js-maintainer-denis-pusharev-license-broke-angry/](https://www.thestack.technology/core-js-maintainer-denis-pusharev-license-broke-angry/)\n7. [https://www.w3.org/TR/did-core/](https://www.w3.org/TR/did-core/)\n8. [https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/](https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/)\n9. [https://www.theregister.com/2016/03/23/npm\\_left\\_pad\\_chaos/](https://www.theregister.com/2016/03/23/npm\\_left\\_pad\\_chaos/)\n10. [https://fossa.com/blog/npm-packages-colors-faker-corrupted/](https://fossa.com/blog/npm-packages-colors-faker-corrupted/)\n11. [https://www.lunasec.io/docs/blog/node-ipc-protestware/](https://www.lunasec.io/docs/blog/node-ipc-protestware/)\n12. [https://github.com/dominictarr/event-stream/issues/116](https://github.com/dominictarr/event-stream/issues/116)\n13. [https://blog.npmjs.org/post/163723642530/crossenv-malware-on-thenpm-registry.html](https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry.html)\n14. [https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/](https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/)\n15. [https://threatpost.com/backdoor-found-in-utility-for-linux/147581/](https://threatpost.com/backdoor-found-in-utility-for-linux/147581/)\n16. [https://www.fbi.gov/news/stories/phantom-secure-takedown-031618](https://www.fbi.gov/news/stories/phantom-secure-takedown-031618)\n17. [https://www.europol.europa.eu/media-press/newsroom/news/800-criminalsarrested-in-biggest-ever-law-enforcement-operation-against-encryptedcommunication](https://www.europol.europa.eu/media-press/newsroom/news/800-criminals-arrested-in-biggest-ever-law-enforcement-operation-against-encrypted-communication)\n18. [https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502](https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502)\n19. [https://www.npmjs.com/package/lodash](https://www.npmjs.com/package/lodash)\n20. [https://www.npmjs.com/package/chalk](https://www.npmjs.com/package/chalk)\n21. [https://www.npmjs.com/package/log4js/](https://www.npmjs.com/package/log4js/)\n22. [https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/](https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/)\n23. [https://medium.com/intrinsic-blog/compromised-npm-package-eventstream-d47d08605502](https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502)\n24. [https://semver.org/](https://semver.org/)\n25. [https://arxiv.org/abs/1207.2617](https://arxiv.org/abs/1207.2617)\n26. [https://research.web3.foundation/Polkadot/overview/token-economics](https://research.web3.foundation/Polkadot/overview/token-economics)\n"
  },
  {
    "path": "i18n/pt-br/metadata.yml",
    "content": "title: Um Protocolo Descentralizado Para Remunerar o Ecossistema de Código Aberto\nabstract: |-\n  A criação de um registro aberto, público e estável para todos os softwares de código aberto\n  autorizaria os projetos a publicar lançamentos de forma independente, ao invés de confiar  \n  em terceiros que reúnem esses dados irregulares em centenas de sistemas separados e duplicados.\n  Os mantenedores de pacotes publicarão seus lançamentos para um registro descentralizado\n  alimentado por uma blockchain Bizantina tolerante a falhas para eliminar fontes únicas de falha,\n  fornecer liberações imutáveis e permitir que comunidades governem suas regiões\n  do ecossistema de código aberto, independentemente de agendas externas.\n\n  O tea incentiva a manutenção do código aberto, permitindo que os participantes da rede\n  apostem valor em relação aos pacotes dos quais dependem e desejam garantir.\n  O gráfico do protocolo tea fornece o registro imutável do pacote, os requisitos de dependência,\n  a autenticidade do pacote e os oráculos de utilização para informar o algoritmo de\n  remuneração do tea. A inflação sistemática é distribuída a todos os pacotes com base\n  nesse algoritmo. Se forem encontrados problemas de segurança ou desenvolvimento,\n  os desenvolvedores podem fazer reivindicações apoiadas por evidências contra o pacote,\n  e pode ocorrer Slashing. Os membros da comunidade de código aberto podem rever os\n  pacotes para questões de qualidade, e o protocolo pode responder a essas avaliações\n  executando eventos de Slashing proporcionais.\nauthor:\n- Max Howell\n- Timothy Lewis\n- Thomas Borrel\nreferences:\n- id: sources\n  url: https://github.com/teaxyz/white-paper\n- id: cc\n  url: https://creativecommons.org/licenses/by-sa/4.0/\n- id: nist\n  url: https://nvd.nist.gov/vuln/detail/CVE-2021-44228\n- id: reuters\n  url: https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA\n- id: twitter\n  url: https://twitter.com/yazicivo/status/1469349956880408583\n- id: w3\n  url: https://www.w3.org/TR/did-core/\n- id: theregister\n  url: https://www.theregister.com/2016/03/23/npm_left_pad_chaos/\n- id: fossa\n  url: https://fossa.com/blog/npm-packages-colors-faker-corrupted/\n- id: lunasec\n  url: https://www.lunasec.io/docs/blog/node-ipc-protestware/\n- id: github\n  url: https://github.com/dominictarr/event-stream/issues/116\n- id: zdnet\n  url: https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/\n- id: threatpost\n  url: https://threatpost.com/backdoor-found-in-utility-for-linux/147581/\n- id: fbi\n  url: https://www.fbi.gov/news/stories/phantom-secure-takedown-031618\n- id: europol\n  url: https://www.europol.europa.eu/media-press/newsroom/news/800-criminals-arrested-in-biggest-ever-law-enforcement-operation-against-encrypted-communication\n- id: medium\n  url: https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502\n- id: semver\n  url: https://semver.org/\n- id: npmjsCrossenv\n  url: https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry.html\n- id: npmjsLodash\n  url: https://www.npmjs.com/package/lodash\n- id: npmjsChalk\n  url: https://www.npmjs.com/package/chalk\n- id: npmjsLogFourjs\n  url: https://www.npmjs.com/package/log4js/\n- id: arxiv\n  url: https://arxiv.org/abs/1207.2617/\n- id: web3\n  url: https://research.web3.foundation/en/latest/polkadot/overview/2-token-economics.html\nheader-includes:\n- \\usepackage{fancyhdr,ragged2e}\n- \\lhead{\\parbox[t]{0.5\\textwidth}{\\RaggedRight\\rightmark\\strut}}\n- \\rhead{\\parbox[t]{0.5\\textwidth}{\\RaggedLeft\\leftmark\\strut}}\n- \\setlength{\\headheight}{5\\baselineskip}\n- \\pagestyle{fancy}\n- \\fancyfoot[LE,RO]{© 2022 tea.inc.}\n- \\fancyfoot[L]{v${1.0.5}+${pt-br}}\nlang: pt-br\ndir: ltr\ntranslator:\n  - Lucas Eduardo de Lima"
  },
  {
    "path": "i18n/pt-br/white-paper.md",
    "content": "# Isenção de responsabilidade\n\nAs informações apresentadas no presente livro branco são de caráter preliminar.\nConsequentemente, nem os autores nem qualquer uma dos seus respectivos afiliados assumem qualquer responsabilidade de que as informações aqui estabelecidas sejam finais ou corretas e cada uma das anteriores renuncia,\nna medida máxima permitida pela lei aplicável, toda e qualquer responsabilidade decorrente de ato ilícito, contrato ou de outra forma em relação a este livro branco.\nNem este livro branco nem qualquer coisa aqui contida devem constituir a base ou ser invocados em conexão com ou agir como um incentivo para celebrar qualquer contrato ou compromisso de qualquer natureza.\n\nNada neste livro branco constitui uma oferta de venda ou uma solicitação para comprar quaisquer tokens aqui discutidos.\nEm qualquer caso, se este livro branco for considerado como tal oferta ou solicitação, nenhuma oferta ou solicitação é pretendida ou transmitida por este livro branco em qualquer jurisdição onde seja ilegal fazê-lo,\nquando tal oferta ou solicitação exigir uma licença ou registro, ou quando tal oferta ou solicitação estiver sujeita a restrições.\nEm particular, quaisquer tokens discutidos neste documento não foram, e, até a data de emissão deste livro branco, não têm a intenção de serem registrados sob as leis de valores mobiliários ou similares de qualquer jurisdição, independentemente de essa jurisdição considerar tais tokens como um valor mobiliário ou instrumento similar, e podem não ser oferecidos ou vendidos em qualquer jurisdição onde fazê-lo constituiria uma violação das leis relevantes de tal jurisdição.\n\n\n# Licença\n\nO código-fonte[^src] deste documento está disponível sob a licença Creative Commons Atribuição-CompartilhaIgual 4.0 Internacional[^cc].\n\n[^src]: Veja: @sources\n[^cc]: Veja: @cc\n\n\n# Introdução\n\nA internet é predominantemente composta por projetos de código aberto e tem sido assim desde o seu início. \nCom o tempo, muitos desses projetos se tornaram peças fundamentais sobre as quais toda inovação futura é construída.\nE embora fortunas tenham sido feitas a partir disso, o código aberto é principalmente criado e mantido sem compensação.\n\nNós acreditamos que a totalidade do empreendimento humano moderno foi prejudicada ao depender do menor percentual de engenheiros do mundo para escolher entre um salário ou manter a Internet funcionando.\nO código aberto é um trabalho de amor frequentemente prejudicado pela falta de incentivos econômicos significativos, resultando em projetos genuinamente valiosos nunca alcançarem seu potencial, enquanto outros sofrem com problemas de segurança devido à falta de incentivos para manter o software ao longo de seu ciclo de vida.\nPara realizar plenamente nosso potencial, precisamos de um sistema de remuneração justo para o ecossistema de código aberto que não mude fundamentalmente como ele é construído ou utilizado.\n\nEmpresas frequentemente criam modelos de negócios em torno do código aberto, gerando receita diretamente a partir do trabalho dos desenvolvedores benevolentes, enquanto também dependem deles para corrigir bugs conforme surgem problemas. \nUm ótimo exemplo é um incidente recente envolvendo uma vulnerabilidade crítica de segurança no Log4j, um pacote da Apache Software Foundation que se espalhou por muitos softwares comerciais e serviços usados por empresas e governos.\nEm novembro de 2021, um pesquisador de segurança que trabalhava para a Alibaba Group Holding Ltd. reportou a vulnerabilidade CVE-2021-44228[^1], que recebeu a pontuação base mais alta possível da Apache Software Foundation. Amit Yoran, CEO da Tenable e diretor fundador do United States Computer Emergency Readiness Team (US-CERT), descreveu essa vulnerabilidade como 'a maior e mais crítica vulnerabilidade da última década'[^2].\nO pânico se instaurou e os poucos voluntários que mantinham esse pacote foram publicamente criticados pelo fracasso.\nApós abordar a indignação com um humilde pedido de Justiça, os sistemas foram corrigidos.\nEmpresas e governos eventualmente perceberam que o Log4j, um pacote usado por uma ampla gama de sistemas críticos por duas décadas, era mantido por alguns voluntários não remunerados, os mesmos heróis desconhecidos que entraram em ação apesar do abuso da indústria[^3] e trabalharam incansavelmente para resolver a vulnerabilidade.\n\nInfelizmente, o Log4j está longe de ser o único exemplo.\nO core-js é baixado 30 milhões de vezes por semana como base de cada aplicativo Node.js, mas também recebe pouquíssimo financiamento.\nRecentemente, vários desenvolvedores principais do Bitcoin Core renunciaram, citando, entre outras razões, a *falta de compensação financeira* por suas decisões.\n\nHouveram múltiplas tentativas de fornecer estruturas de incentivo, geralmente envolvendo patrocínio e sistemas de recompensa.\nO patrocínio torna possível para consumidores de código aberto doarem para os projetos que favorecem.\nNo entanto, imagine o código aberto como uma torre de tijolos onde as camadas inferiores são há muito esquecidas, mas ainda mantidas por engenheiros dedicados e utilizadas por ainda mais desenvolvedores.\nApenas projetos no topo da torre são normalmente conhecidos e recebem patrocínio.\nEssa seleção tendenciosa leva a tijolos essenciais que sustentam a torre não receberem doações, enquanto os favoritos recebem mais do que precisam.\nRecompensas permitem que consumidores de projetos proponham pagamento para desenvolvedores construírem recursos específicos, assim remunerando apenas projetos por fazer coisas não necessariamente no seu melhor interesse. \nE novamente, apenas recompensando os favoritos.\n\nNeste documento, propomos o tea — um sistema descentralizado para remunerar justamente os desenvolvedores de código aberto com base em suas contribuições para todo o ecossistema e implementado através do algoritmo de incentivo tea aplicado a todas as entradas no registro do tea.\n\n![Simplified view of the tea steeping rewards system.](img/figure-1.svg)\n\n$\\parskip=0pt plus 1pt$\n\n[^1]: Fonte: @nist\n[^2]: Fonte: @reuters\n[^3]: Fonte: @twitter\n\n\n# Componentes\n\nUm desenvolvedor de software construindo uma aplicação precisa de quatro coisas: um navegador, um terminal, um editor e um gerenciador de pacotes.\nDestes quatro, o gerenciador de pacotes é o que controla as ferramentas e estruturas que um desenvolvedor precisa para construir seu produto.\nEsta camada é onde vemos o potencial de mudar como o código aberto é remunerado.\n\n## O Gerenciador de Pacotes\n\nO gerenciador de pacotes conhece o software de código aberto no qual uma aplicação depende para funcionar, desde o topo da torre até sua base.\nCada componente e versão essencial para a aplicação são conhecidos e registrados.\nEle sabe que o topo da torre seleciona cuidadosamente suas dependências e que essa seleção cuidadosa continua descendendo.\nO gerenciador de pacotes está posicionado de forma única na pilha de ferramentas do desenvolvedor para permitir a distribuição automatizada e precisa de valor com base no uso real e prático.\n\nNós propomos um registro descentralizado imutável projetado para distribuir valor com base em um algoritmo que determina a contribuição de cada entrada para a utilidade e saúde do sistema.\nO valor pode entrar no gráfico nos pontos de ápice — aplicativos e bibliotecas essenciais — e ser distribuído para as dependências desses pontos de ápice e suas dependências recursivamente, já que o registro conhece todo o gráfico de código aberto.\n\nAlém disso, acreditamos que informações materiais devem estar disponíveis via gerenciador de pacotes para que os desenvolvedores possam avaliar se podem confiar em um pacote e em seu autor.\nEssas informações podem se basear em reputação, reconhecimento da comunidade, dados obtidos de sistemas de identidade descentralizados (DID[^4]) outros gerenciadores de pacotes ou mecanismos de incentivo que potencialmente dependem dos participantes da rede colocando valor econômico em risco.\n\nPrevemos que a combinação de ferramentas, informações e recompensas do tea incentivará justamente os desenvolvedores, ajudando a estimular o crescimento do software de código aberto e fomentar a inovação.\n\n[^4]: See: @w3\n\n## O Registro Descentralizado\n\nCada gerenciador de pacotes possui seu próprio registro de pacotes duplicando os mesmos metadados repetidamente.\nEstá na hora de haver um registro único, abrangente e definitivo projetado e governado pelas comunidades que dependem dele.\nEste registro descentralizado e imutável poderia fornecer segurança, estabilidade e impedir intenções maliciosas.\n\nA internet opera com dezenas de milhares de componentes vitais de código aberto.\nÉ notável que, até agora, incidentes causados pela remoção de infraestrutura de código aberto essencial tenham sido mínimos.\nO mais famoso foi a remoção de uma dependência do NPM chamada left-pad[^5] em 2016, que causou problemas em sistemas de integração contínua e implantação contínua, deixando os desenvolvedores em situação delicada por dias.\nEsse evento demonstrou que a própria internet é baseada em sistemas frágeis de desenvolvimento.\nOutros exemplos envolveram participação ativa ou intencional dos mantenedores de pacotes sabotando seus pacotes populares (Veja colors.js, faker.js[^6], e node-ipc[^7]),\nou malfeitores tentando lucrar fingindo ajudar a manter pacotes e corrompendo-os para roubar, por exemplo, chaves privadas de Bitcoin (Veja event-stream[^8]),\nou pacotes maliciosos com erros de grafia intencionais, também conhecidos como typosquatting,\nna esperança de enganar os usuários para que os instalem, por exemplo, os pacotes NPM crossenv vs. cross-env[^npmjsCrossenv].\n\nA integridade do software precisa ser garantida à medida que a indústria avança para um futuro onde os ativos digitais fazem parte do software.\nNão podemos continuar vulneráveis a malfeitores modificando o software.\n\nA maioria das ferramentas que chamamos de gerenciadores de pacotes não pode garantir que esses pacotes integrados nos aplicativos e dApps sejam o código de código aberto não adulterado publicado por seus autores originais. \nO GitHub da Microsoft descobriu que 17% das vulnerabilidades de software foram implantadas com propósitos maliciosos[^9], sendo que algumas permaneceram não detectadas por longos períodos (Veja Webmin 1.890[^10]).\n\nUm registro descentralizado, complementado por um sistema de reputação e apoiado por incentivos econômicos projetados para expor malfeitores e recompensar benfeitores, pode oferecer as garantias que as comunidades de desenvolvedores têm procurado.\n\n[^5]: Fonte: @theregister\n[^6]: Fonte: @fossa\n[^7]: Fonte: @lunasec\n[^8]: Fonte: @github\n[^npmjsCrossenv]: Fonte: @npmjsCrossenv\n[^9]: Fonte: @zdnet\n[^10]: Fonte: @threatpost\n\n\n## O sistema de Amarzenamento\n\nPacotes de código aberto oferecem uma ampla gama de funcionalidades, algumas das quais podem ser restritas ou indesejadas.\nA criptografia é um excelente exemplo disso.\nUm caso de uso crítico para a criptografia é o suporte à privacidade das pessoas em todo o mundo.\nNo entanto, a criptografia também pode ser usada para fins nefastos (Veja Phantom Secure, desmantelada por agências de aplicação da lei em março de 2018[^11]) ou pode ser comprometida para apoiar atividades de aplicação da lei (Veja Operação Ironside (AFP), Operação Greenlight (Europol),\ne Operação Trojan Shield (FBI)[^12] onde o FBI operava uma plataforma de comunicação \"criptografada\", AN0M, e convenceu criminosos a usar seus telefones \"criptografados\" para comunicação segura.\n\nAs amplas aplicações da criptografia a tornaram um caso de uso perfeito para software de código aberto e um ótimo exemplo de que qualquer solução que armazene pacotes deve ser à prova de manipulações e resistente à censura. \nO tea é um protocolo descentralizado que não tem a intenção de filtrar ou sancionar pacotes com base em sua funcionalidade. \nEmbora a governança do tea possa optar por remover pacotes comprovadamente maliciosos (consulte a seção de governança para mais informações), é fundamental para o sistema tea se conectar a vários sistemas de armazenamento, incluindo sistemas descentralizados que demonstrem que um pacote não foi alterado e está corretamente replicado.\nOs mantenedores de pacotes podem escolher o sistema de armazenamento mais adequado às suas necessidades para armazenar e distribuir seus pacotes de forma segura.\n\n[^11]: Fonte: @fbi\n[^12]: Fonte: @europol\n\n# Participantes da Rede\n\nA missão do tea é capacitar comunidades de código aberto e garantir que seus contribuintes sejam apoiados enquanto criam as ferramentas que constroem a Internet.\nNeste livro branco, distinguimos os participantes por meio de suas contribuições. \nAlguns podem contribuir com código ou verificar o código contribuído. \nOutros podem fornecer valor econômico para apoiar os desenvolvedores e sua reputação.\n\n## Package Maintainers\n\nOs mantenedores de pacotes devem garantir que seu software continue entregando valor crescente à medida que a indústria evolui.\n\nO tea assume que os criadores de pacotes mantêm seu trabalho.\nOs mantenedores de pacotes são pilares das comunidades de código aberto que precisam ser capacitados e recompensados por suas contribuições contínuas.\nUm mantenedor de pacote pode decidir interromper seus esforços de manutenção ou perceber que não pode operar no mesmo ritmo das expectativas dos usuários do pacote.\nOs mantenedores de pacotes recebem um token não fungível (NFT) quando concluem uma submissão de pacote (consulte a seção de NFT do mantenedor para detalhes adicionais).\nEste NFT é usado para comprovar seu trabalho e é a chave que direciona as recompensas do tea.\nO detentor do NFT de um pacote pode transferir sua propriedade para outro desenvolvedor (ou grupo de desenvolvedores), tornando-os assim mantenedores do pacote e receptores de quaisquer recompensas futuras.\nDa mesma forma, um desenvolvedor pode decidir assumir o papel de mantenedor de pacote ao bifurcar o pacote existente e submeter um novo pacote que eles manterão no futuro, tornando-se assim tanto criador quanto mantenedor do pacote.\n\nÉ essencial fornecer às comunidades de desenvolvedores as ferramentas adequadas para determinar quais pacotes estão sendo mantidos, bem como a reputação passada e presente dos mantenedores e a qualidade do trabalho.\nCom frequência, vimos trabalhos de código aberto sendo adulterados e os esforços de muitos arruinados por malfeitores.\nEmbora o trabalho desses malfeitores seja em grande parte descoberto e remediado, muitas vezes isso só ocorre depois que danos significativos foram causados, seja por perda financeira ou de dados.\nVeja, por exemplo, o pacote npm EventStream[^13] que foi baixado mais de 1,5 milhão de vezes por semana e era utilizado por mais de 1.500 pacotes, quando um hacker conseguiu penetrar no projeto de código aberto, ganhar a confiança de seu autor original e modificar o EventStream para depender de um pacote malicioso que exfiltraria credenciais de carteiras de bitcoin para um servidor de terceiros. \nEmbora ferramentas possam ajudar a detectar alguns desses ataques, nem sempre se pode depender delas, o que cria uma comunidade inteira dependente da diligência e vontade de compartilhar descobertas uns dos outros.\n\nPropomos a introdução de incentivos por meio do token tea descrito na seção do token tea, incentivando comunidades de código aberto a relatar construtivamente suas descobertas, para que os mantenedores de pacotes possam abordá-las antes que sejam exploradas.\n\n[^13]: Fonte: @medium\n\n## Usuários de Pacotes\n\nOs usuários de pacotes são desenvolvedores de software focados em resolver um problema específico.\nMuitas vezes, eles buscam na comunidade de código aberto as ferramentas de que precisam para experimentar rapidamente e iterar com custo mínimo ou nenhum, beneficiando-se diretamente do trabalho dos criadores e mantenedores de pacotes.\nTradicionalmente, um subconjunto pode ter optado por apoiar os mantenedores de pacotes por meio de doações ou outras formas de remuneração; no entanto, isso raramente foi o caso.\n\nO patrocínio pode ser um sistema eficaz para apoiar o desenvolvimento de código aberto; no entanto, a remuneração geralmente não se estende a todas as dependências.\nEssa limitação beneficia os favoritos e atrapalha a inovação e a construção de software.\nPara prosperar como a base do desenvolvimento de software, o código aberto deve capacitar todos os desenvolvedores, sejam iniciantes ou especialistas, em todas as camadas da torre.\n\nO objetivo do tea é manter os valores fundamentais do software de código aberto enquanto fornece um sistema descentralizado para remunerar os mantenedores de pacotes por seu trabalho.\nPara cumprir essa missão, o tea pretende desenvolver — e incentivar outros a desenvolver — mecanismos para que os usuários de pacotes apoiem os mantenedores de pacotes por meio de casos de uso únicos do token tea, conforme descrito nas seções do token tea, trabalho futuro e esforço potencial da comunidade.\n\n## Package Supporters and Sponsors\n\nNa Web 2.0 e na web3, os apoiadores de pacotes frequentemente foram chamados de 'patrocinadores'. Eles são organizações ou usuários de pacotes que usam software de código aberto para construir seus produtos comerciais, filantropos que desejam apoiar o ecossistema ou empreendedores que procuram financiar equipes para desenvolver componentes de um sistema maior.\n\nO tea propõe ampliar as comunidades de apoiadores de pacotes para toda a comunidade do tea, sejam organizações, desenvolvedores, usuários ou entusiastas da tecnologia.\nO objetivo do tea é implementar mecanismos de incentivo descentralizados por meio de casos de uso exclusivos do token tea para que qualquer membro da comunidade do tea contribua para a sustentabilidade perpétua e o crescimento contínuo do código aberto.\nApoiadores de pacotes e patrocinadores são livres para decidir quais pacotes ou mantenedores de pacotes desejam apoiar com base em seu trabalho, crenças ou qualquer critério e métrica que influenciaria sua decisão.\nAlém disso, o apoio fornecido pelos apoiadores de pacotes e patrocinadores fluirá para as dependências de cada pacote, confiando implicitamente no mantenedor do pacote para fazer boas escolhas sobre sua pilha de tecnologia e usando essas informações para contribuir para sua reputação.\n\nDesde que o mantenedor do pacote ofereça esse serviço, um apoiador de pacote e patrocinador pode receber um NFT de nível de suporte premium em troca, beneficiando-se de SLAs acelerados ou licenciamento mais flexível.\nAlém disso, apoiadores de pacotes e patrocinadores podem decidir apoiar pacotes ou mantenedores de pacotes e redirecionar automaticamente todas ou parte de suas recompensas para incentivar equipes a construir novo software de código aberto.\nEm outras palavras, os pacotes não precisam existir para que o tea comece a contribuir.\nProjetos incipientes podem ser apoiados da mesma forma que os mais maduros, incentivando ainda mais um cenário de código aberto em constante evolução.\n\n## tea Tasters\n\nÀ medida que novos pacotes ou novas versões de pacotes existentes são lançados, a validade do trabalho precisa ser demonstrada de forma comprovável.\nEssas informações são essenciais para os usuários de pacotes decidirem se confiam ou não tanto no pacote quanto em seus mantenedores.\nCom o protocolo tea, essa função é fornecida pelos tea tasters.\n\nOs tea tasters, geralmente, são desenvolvedores de software experientes dispostos a dedicar parte do seu tempo para verificar as reivindicações associadas a um pacote (funcionalidade, segurança, versionamento semântico[^14],  precisão da licença, etc.) e apostar tanto sua reputação quanto valor econômico para demonstrar o resultado de suas pesquisas e análises e apoiar suas avaliações.\nOs tea Tasters recebem recompensas por sua diligência e esforços.\nNo tea, chamamos de 'infusão do seu tea' a ação de bloquear tokens tea para apoiar suas análises e receber recompensas (ou penalidades) com base no consenso sobre a validade de suas avaliações.\n\nAssim como os apoiadores de pacotes, os tea Tasters podem influenciar a reputação de um pacote e de um mantenedor de pacote; no entanto, seu impacto é mais significativo devido ao papel na validação da segurança, funcionalidade e qualidade de um pacote.\nOs tea Tasters também precisarão construir sua reputação para apoiar suas alegações.\nA qualidade de seu trabalho e o valor econômico que arriscam ao fazer suas análises, combinados com outras fontes externas de dados, construirão a reputação de cada tea Taster, agregando mais valor ao seu trabalho.\nConsulte a seção de reputação de pacotes para mais detalhes sobre os mecanismos usados para influenciar a reputação de um pacote e de um mantenedor de pacote.\n\n[^14]: Veja: @semver\n\n# Visão Geral do Protocolo\n\nO design de um protocolo para recompensar contribuições de código aberto é repleto de desafios.\nO software de código aberto, por definição, está aberto a todos e, como resultado, pode ser alvo de má atribuição, apropriação ou manipulação maliciosa.\nNo entanto, a comunidade de código aberto consistentemente demonstrou disposição para destacar benfeitores e expor os maus.\nHistoricamente, o tempo gasto revisando e comentando as contribuições de outros desenvolvedores tem sido estritamente voluntário, apesar de quão demoradas e cruciais podem ser as atividades de relatar e defender descobertas.\n\nNossa intenção é criar uma plataforma de distribuição sem confiança para aplicativos protegidos por reputação e incentivos financeiros, pois acreditamos que recompensas adequadas para contribuições de código aberto não podem ter sucesso sem um sistema de reputação e a capacidade dos membros da comunidade de comunicar suas descobertas e apoiar (ou discordar) de um pacote ou do trabalho de um desenvolvedor.\n\nDevemos fornecer aos desenvolvedores ferramentas para acessar e contribuir para esse sistema de reputação.\nFerramentas que incluam acesso visual e programável à versão e reputação de todas as dependências em seus pacotes.\nUm entendimento claro de quais membros da comunidade apoiam cada pacote e quantos tokens tea estão sendo utilizados contribuirá para a reputação de cada pacote, assim como quanto um mantenedor de pacote está investindo em seu trabalho comunica o quanto eles o apoiam.\nEsses pontos de dados combinados ajudarão a informar um sistema de reputação para todos os membros da comunidade e facilitarão a escolha.\nComo o hack do pacote EventStream não foi conduzido pelo pacote em si, mas por meio de uma de suas dependências, a visibilidade em todas as camadas de dependências será vital para construir esse sistema sem confiança.\nNo entanto, considerações como custos de computação e transação (\"gas\") precisarão ter prioridade à medida que o sistema for projetado e construído.\n\nNosso objetivo é recompensar tanto os desenvolvedores da Web 2.0 quanto da web3.\nAs complexidades e especificidades de cada pilha tecnológica tornam possível que o rastreamento de instalações e desinstalações de pacotes possa facilmente ser vítima de um ou mais malfeitores, incluindo a \"compra\" de instalações para inflar artificialmente os números.\nUm cenário ainda pior seria introduzir mudanças fundamentais na natureza do software de código aberto, criando fricção desnecessária com chaves de licença ou outros mecanismos de rastreamento de implantação.\nPara oferecer a maior cobertura possível, acreditamos que as recompensas não devem depender de uma noção simplista de rastreamento de instalações ou desinstalações, mas sim de mecanismos de incentivo que incentivem a submissão de pacotes de qualidade e a denúncia de pacotes maliciosos ou de alto risco.\nPor fim, muitos pacotes dependem de dependências comuns.\nPor exemplo, o Lodash tem 151.209 dependentes[^15] enquanto o chalk tem 78.854 dependentes[^16] e o Log4js tem 3.343 dependentes[^17].\nÀ medida que mais pacotes são criados usando as mesmas dependências, como garantimos que os incentivos sejam distribuídos de forma justa e equitativa?\nComo garantimos que as dependências mais utilizadas sejam recompensadas sem prejudicar os novos ou emergentes pacotes e desenvolvedores?\nComo garantimos que o sistema de incentivo não acabe direcionando os desenvolvedores longe de linguagens de nicho para centralizá-los onde os incentivos são melhores?\nMas também, como desenvolvedores, como identificamos pacotes com o maior número de dependentes para construir alternativas - versões mais enxutas, mais eficientes e melhor codificadas desses pacotes?\nNo tea, acreditamos que a falta de incentivo tem impedido a evolução do software de código aberto.\nCom os incentivos econômicos e recompensas certas, mais desenvolvedores estarão em posição de construir, melhorar e ampliar o software de código aberto para o benefício do mundo.\nSomente então o token tea será capaz de representar o valor total do software de código aberto.\n\n[^15]: Fonte: @npmjsLodash\n[^16]: Fonte: @npmjsChalk\n[^17]: Fonte: @npmjsLogFourjs\n\n## Submissão de Pacote\n\nA submissão de um lançamento de pacote requer múltiplas transações para ocorrerem atomicamente.\nEspecificamente, o mantenedor do pacote deve:\n\n* Registrar o pacote (e sua versão semântica) no registro descentralizado.\n* Fazer upload do pacote no sistema de armazenamento descentralizado para resiliência, resitência à censura e facilidade de distribuição.\n* Contribuir para a reputação e confiabilidade do pacote 'infundindo' tokens tea.\n\nO fracasso de qualquer uma das três operações resultará no protocolo revertendo para seu estado anterior, eliminando assim qualquer evidência da submissão.\n\nQuando um pacote é submetido com sucesso, o mantenedor do pacote receberá um NFT de mantenedor para evidenciar seu trabalho e contribuição para o código aberto.\nO mantenedor do pacote pode transferir as recompensas de 'infusão' associadas ao NFT do mantenedor para um terceiro.\nNo entanto, a reputação associada à criação e manutenção do ativo permanecerá com o mantenedor do pacote, de modo que sua reputação possa ser afetada ao longo do tempo.\nConforme a reputação de qualquer membro da comunidade do tea atinge marcos importantes, eles podem receber acesso a partes elevadas do protocolo ou receber recompensas aceleradas, conforme decidido pela governança do tea.\nPara mais detalhes sobre o NFT do mantenedor, consulte a seção do NFT do mantenedor.\n\n### Análise de Dependências\n\nAs dependências de pacotes podem ser extensas, já que cada pacote frequentemente possui dependentes e dependências.\nPara fornecer uma metodologia simples que recompense todos os desenvolvedores que contribuíram para o software de código aberto, mantendo a criação da árvore de dependências rápida e computacionalmente eficiente, propomos verificar apenas as dependências de primeiro nível ao submeter um pacote.\n\nEste design é baseado na hipótese de que cada dependência é, por si só, um pacote que foi submetido independentemente para a árvore do tea.\nAo fazer isso, cada uma de suas dependências pode ser mapeada e, se suas dependências também tiverem dependências, essas serão mapeadas no momento em que o pacote de dependência for submetido\n\n![Diagrama de análise de dependências](img/figure-3.svg){#fig:dep-analysis}\n\n\nNa @fig:dep-analysis, a submissão do pacote A aciona uma análise das dependências de tempo de execução 1 até n e das dependências de compilação 1 até n, enquanto as dependências de tempo de execução 1.1 até 1.n e as dependências de compilação 1.1 até 1.n foram analisadas quando o pacote B foi submetido.\nAplicaremos a mesma metodologia para a distribuição de incentivos, já que os tokens infundidos são distribuídos entre todas as dependências, infundindo recursivamente os pacotes listados como dependências (ver @fig:steeping-rewards).\n\n![A distribuição das recompensas de infusão entre as dependências.](img/figure-2.svg){#fig:steeping-rewards}\n\n\nVersionamento e dependências conflitantes são desafios significativos, e solucioná-los pode se tornar uma enorme perda de tempo.\nPara lidar com isso, propomos que cada pacote seja submetido a uma varredura abrangente de dependências ao ser enviado, para garantir que o pacote esteja em conformidade com as seguintes regras para intervalos de versão semântica.\n\n* Pacotes podem apenas restringir suas dependências para uma versão principal, embora o início do intervalo possa ser qualquer versão semântica válida (por exemplo, >=5.2.1 <6).\n* Se uma dependência for atualizada para uma versão principal mais recente, o tea pode exigir que a versão principal do pacote seja aumentada.\n* Da mesma forma, se uma dependência for atualizada para uma versão secundária mais recente, o tea pode exigir que a versão secundária do pacote seja aumentada.\n* Se uma nova dependência for adicionada, o tea pode exigir que a versão secundária do pacote seja aumentada.\n\nConsiderando o esforço desnecessário imposto a qualquer usuário de pacote quando as regras acima são desrespeitadas, propomos que uma parte dos tokens tea infundidos pelo mantenedor do pacote seja reduzida para refletir a falta de diligência adequada.\nSe um desenvolvedor obriga todos a malabarismar com suas xícaras, alguém vai derramar chá.\nComo espera-se que a varredura de dependências ocorra na submissão, devemos observar que nenhuma infusão dos apoiadores de pacotes e patrocinadores, ou dos tea Tasters, terá ocorrido.\n\n## A reputação do Pacote e do Mantenedor do Pacote\n\nOs mantenedores de pacotes devem contribuir para a reputação e confiabilidade de seus pacotes infundindo tokens tea.\nNo entanto, um sistema de reputação que depende exclusivamente da contribuição econômica do autor não oferece proteção suficiente ao usuário e pode estar sujeito a ataques Sybil, nos quais um único indivíduo cria várias representações de si mesmo para deixar um grande volume de avaliações positivas sobre seu trabalho, enganando os usuários a acreditarem que seu trabalho foi revisado e aprovado por muitos.\n\nVárias metodologias estão disponíveis para evitar ataques Sybil, algumas das quais são descritas por Nitish Balachandran e Sugata Sanyal em \"A Review of Techniques to Mitigate Sybil Attacks\"[^18].\nComo o tea é um protocolo descentralizado, o uso de um sistema de certificação de confiança que depende de uma autoridade centralizada de emissão de certificados seria contrário ao seu cerne.\nPropomos focar em abordagens descentralizadas para mitigação de ataques Sybil e, mais especificamente, em metodologias que dependem de um grande grupo de participantes da rede incentivados a avaliar e representar publicamente a reputação de cada pacote e seu mantenedor.\n\nSimilar à produção de blocos em uma blockchain de prova-de-participação, onde nós não produtores podem validar o trabalho de outros e, quando necessário, destacar uma violação das regras da rede, o que leva à penalização do malfeitor por meio de redução (destruição de uma parte de sua participação),\npropomos um sistema no qual terceiros (também conhecidos como tea Tasters) seriam capazes de revisar pacotes produzidos por mantenedores de pacotes e seriam economicamente incentivados a agir no melhor interesse da comunidade de software de código aberto e de seus usuários, reconhecendo comportamentos bons e penalizando os ruins.\nEste sistema deve ser resistente a ataques Sybil e impedir que grandes detentores de tokens influenciem materialmente o protocolo ou a reputação de pacotes específicos.\nAcreditamos que essa abordagem está mais alinhada com o código aberto, fornecendo um substrato mais fértil para promover adoção e confiança e, por fim, facilitar o crescimento do tea.\n\n[^18]: Fonte: @arxiv\n\n## Revisão de Pacotes por Terceiros\n\nA revisão de pacotes por terceiros é um componente essencial na construção de reputação, no entanto, a revisão de terceiros possui seu próprio conjunto de ameaças exclusivas, incluindo os ataques Sybil mencionados anteriormente.\n\nA tecnologia blockchain, e mais explicitamente o staking, oferece uma oportunidade única para o tea lidar com esse desafio.\nEmbora os endereços de carteira possam estar disponíveis em quantidades infinitas, esse não é o caso dos tokens tea, cujo fornecimento inicial é esperado para ser de 10 bilhões.\nAlém disso, cada ação realizada pelos desenvolvedores, como submeter pacotes, verificar pacotes ou infundi-los, contribuirá para sua reputação, criando assim um perfil único para cada desenvolvedor usar tanto para contribuir para a comunidade do tea quanto para participar da governança do tea.\n\nAo exigir que os revisores de terceiros infundam tokens tea e incorram no risco de perder uma parte dos tokens infundidos caso se comportem contra o interesse da rede ou sejam malfeitores, os terceiros podem fornecer credibilidade adicional a um pacote e receber uma recompensa na forma de tokens tea.\n\nTambém propomos estender o sistema de reputação para os terceiros que realizam a verificação independente de pacotes - os tea Tasters.\nA conclusão de uma revisão positiva exigirá que duas operações ocorram de forma atômica:\n\n* A submissão da revisão de código, assinada pelo tea Taster e acessível publicamente a todos os membros da comunidade, juntamente com\n* O ato de infundir \"para\" o pacote (em vez de \"contra\" o pacote), para substantiar sua revisão.\n\nA conclusão de uma revisão negativa que inclui uma ou mais vulnerabilidades críticas exigirá que os tea Tasters primeiro entrem em contato com o mantenedor do pacote usando um protocolo de mensagens para notificá-los da vulnerabilidade e permitir que eles abordem o problema de forma oportuna.\nApós o vencimento do período definido pela governança atribuído ao mantenedor do pacote para abordar sua vulnerabilidade ou quando o pacote corrigido estiver disponível, o mesmo protocolo de mensagens será usado para notificar todos os usuários e testadores deste pacote (incluindo dependentes) que uma vulnerabilidade foi identificada,\ne esperançosamente resolvida, para que saibam atualizar sua aplicação ou dependências.\nPara desincentivar o desperdício de tempo dos desenvolvedores, a comunicação entre os tea Tasters e os mantenedores de pacotes exigirá que os tea Tasters infundam tokens tea.\n\nAo concluir ambas as operações, os tea Tasters receberão um NFT como prova de seu trabalho no pacote específico e na versão do pacote. O acúmulo de NFTs combinado com a taxa de infusão de cada um dos pacotes revisados e informações extraídas de sistemas externos informarão a reputação de um tea Taster.\nConforme sua reputação atinge marcos-chave, os tea Tasters podem ter acesso a partes elevadas do protocolo ou a recompensas aceleradas, conforme decidido pela governança do tea.\n\n## Pacotes Desatualizados ou Corrompidos\n\nA missão do tea é recompensar os contribuidores e participantes das comunidades de código aberto; no entanto, as recompensas devem ser proporcionais aos esforços empreendidos pelos mantenedores de pacotes e tea Tasters.\nPacotes mal mantidos, desatualizados ou corrompidos são indicações claras de que os mantenedores de pacotes não estão atendendo às expectativas da comunidade ou não estão cumprindo a confiança e o apoio depositados neles por meio da infusão de pacotes.\nOutra manifestação de pacotes desatualizados pode ser o uso contínuo de uma linguagem antiga ou de uma versão antiga de linguagens multiversão.\nPacotes permanecendo desatualizados ou corrompidos por muito tempo indicam que os tea Tasters precisam revisar regular e consistentemente o trabalho dos mantenedores de pacotes.\n\nOs tea Tasters são membros críticos das comunidades de código aberto, pois suas revisões e reivindicações associadas podem orientar os usuários de pacotes na direção ou para longe de pacotes.\nPara garantir que as revisões possam ser confiáveis continuamente, propomos um mecanismo pelo qual pacotes desatualizados ou corrompidos possam ter uma parte de seus tokens infundidos enviados aos tea Tasters que foram os primeiros a reconhecer a falta de manutenção de qualquer pacote.\n\nQualquer revisão negativa que destaque uma falha, como uma vulnerabilidade zero-day ou o uso de uma dependência desatualizada e permaneça aberta após um período de carência definido pela governança, deve ser considerada uma falha por parte do mantenedor do pacote.\nEles não completaram a tarefa com a qual foram incumbidos e recompensados.\nO mesmo vale para os apoiadores e patrocinadores do pacote que apostaram sua reputação no trabalho dos mantenedores de pacotes negligentes e receberam recompensas por isso, mas não identificaram a falta de manutenção ou optaram por continuar a apoiar o pacote, independentemente.\n\nÀ medida que os pacotes ganham popularidade e uso, com mais aplicativos e sistemas potencialmente críticos dependendo deles, precisamos incentivar os desenvolvedores a relatar discreta e rapidamente falhas ao mantenedor do pacote e os mantenedores de pacotes a resolverem tais falhas antes que possam ser exploradas.\nConsequentemente, propomos que qualquer pacote desatualizado ou corrompido que seja objeto de uma ou mais revisões negativas comprovadas e permaneça nesse estado após o período de carência definido pela governança tenha uma parte de seus tokens infundidos destruída, independentemente de sua origem (mantenedor do pacote, apoiadores e patrocinadores do pacote ou revisores anteriores de tea),\nenquanto outra parte é enviada aos tea Tasters que enviaram as revisões negativas. A distribuição para todos os tea Tasters pode ser baseada na idade de suas revisões e na quantidade de tokens de tea que infundiram para suas revisões.\n\n## Maintainer NFT\n\nApós a submissão bem-sucedida de um pacote, o mantenedor do pacote receberá um NFT como prova de seu trabalho e contribuição.\nO detentor deste NFT receberá automaticamente todas as recompensas associadas ao pacote.\nOs mantenedores de pacotes podem transferir a propriedade da manutenção de um pacote para outro mantenedor de pacote simplesmente transferindo o NFT do pacote.\nA transferência bem-sucedida do NFT levará o novo proprietário a receber automaticamente as futuras recompensas do pacote.\n\nUma parte importante da construção de reputação depende da frequência e quantidade de submissões de pacotes de qualidade.\nO NFT entregue aos mantenedores de pacotes como evidência de seu trabalho pode ser usado pelo sistema de reputação para atualizar a reputação de um mantenedor de pacotes e dar a eles acesso a partes elevadas do protocolo, conforme decidido pela governança do tea.\nNo entanto, para prevenir vetores de ataque, como membros da comunidade comprando sua reputação, a transferência do NFT do mantenedor não resultará na transferência de reputação.\nA reputação deve permanecer diretamente associada ao trabalho de um desenvolvedor específico e não pode ser transferida.\n\n# Token tea\n\n## Garantindo a Rede\n\nEmbora muitas blockchains possam parecer soluções de infraestrutura eficazes e seguras para apoiar os objetivos do tea, acreditamos que uma consideração cuidadosa deve ser dada à pilha de tecnologia sobre a qual o sistema tea é construído.\n\nEscalabilidade, eficiência de custos, ESG e extensibilidade de terceiros são considerações importantes de design que um sistema de prova-de-participação soberano por meio do tea poderia melhor servir.\nNo modelo de prova-de-participação, os operadores de nós e os participantes da rede apostam valor econômico na forma do token nativo da cadeia para aumentar a segurança do sistema.\nOs operadores de nós e os participantes da rede recebem recompensas pela produção bem-sucedida de blocos que estejam em conformidade com as regras da rede e incluam informações precisas de transações.\nInatividade (também conhecida como *node down*) ou atividade maliciosa/incorreta são penalizadas pela destruição de uma fração dos tokens apostados por meio de Slashing.\n\nUm sistema de prova-de-participação alimentado pelo token tea permitirá que os detentores do token tea contribuam para a segurança do sistema apostando tea e apoiem os desenvolvedores de código aberto deixando tea.\nEstamos totalmente cientes de que fatores econômicos podem impedir alguns desenvolvedores de apostar ou deixar tea; como tal, a aposta e o ato de deixar estarão disponíveis por tão pouco quanto uma folha, a menor denominação de tea, representando um centésimo de um bilionésimo ($10^{-8}$) de um tea.\n\nAmbos os usos do token tea têm funções vitais no suporte e crescimento do ecossistema de código aberto.\nO staking de tea garantirá que o sistema tea continue a operar de forma segura, para que todos os participantes da rede possam enviar e acessar pacotes para revisá-los, integrá-los em suas aplicações, etc.\nPor outro lado, o ato de infusão tea apoiará o objetivo do tea de fornecer ferramentas para todos os participantes da rede apoiarem e usarem pacotes que atendam aos requisitos de qualidade e confiabilidade, conforme formulado pela comunidade tea por meio de seu apoio e objeção a cada pacote.\nSerá tomado cuidado ao definir e implementar os parâmetros de aposta e de deixar para que um não se torne parasitário do outro.\n\n## Incentivos e Penalidades\n\nComo discutido anteriormente, há fortes incentivos para malfeitores comprometerem o software de código aberto.\nA maioria da infraestrutura crítica da internet está rodando em código aberto, e a corrida para encontrar exploits e outras vulnerabilidades está em curso.\nNo tea, acreditamos que os mantenedores de pacotes não devem ser culpados (embora muitas vezes o sejam).\n\nOs incentivos do protocolo tea corrigem isso por meio de uma distribuição justa e equitativa de incentivos.\nUm pacote como o Lodash, com mais de 151 mil dependentes, é um pilar do desenvolvimento de código aberto, e seu mantenedor merece ser recompensado proporcionalmente.\nNo entanto, um sistema de recompensa baseado unicamente no número de dependentes impediria inovadores de interromper esses monopólios, a menos que sejam financiados suficientemente por terceiros ou já tenham acumulado recursos suficientes para se autofinanciar.\nEssa abordagem provavelmente levaria a uma redução no número de contribuintes, resultando no oposto do que o tea pretende.\n\nO objetivo do tea é representar o valor do software de código aberto e, ao fazê-lo, promover seu crescimento capacitando seus participantes com os recursos necessários para perseguir sua paixão sem obstáculos.\nO sistema de distribuição de incentivos do tea precisa considerar cuidadosamente a taxa de \"deixar\" de cada pacote e ajustar os incentivos de cada pacote de acordo.\nPara reduzir o risco de um pequeno número de pacotes, usados como dependências em muitos aplicativos, coletarem a maioria das recompensas de \"deixar\", vamos aproveitar a pesquisa produzida pela Fundação Web3[^19] para o mecanismo de recompensas baseado em prova-de-participação do Polkadot.\nPodemos ajustar ainda mais a implementação e suas variáveis com base nos resultados de experimentos práticos.\n\nÀ medida que um pacote se aproxima de uma taxa de \"infusão\" ideal definida pela governança, sua proporção de recompensas de \"infusão\" diminuirá progressivamente.\nQuando um pacote excede sua taxa de \"infusão\" ideal, a proporção de recompensas de \"infusão\" diminuirá acentuadamente para desincentivar os apoiadores do pacote e os tasters de deixar ainda mais pacotes altamente infundidos.\nEsse design poderia tornar pacotes menos infundidos mais atraentes tanto para apoiadores quanto para tasters.\nTambém pode incentivar desenvolvedores experientes a criar alternativas para pacotes altamente infundidos, criando uma oportunidade para a comunidade tea equilibrar o suporte ao software existente e promover a inovação.\nA taxa de \"infusão\" será calculada usando o suprimento circulante em seu design inicial.\nA comunidade tea pode alterar esse design para aprimorar ainda mais a escalabilidade do sistema.\nSeja $\\chi$ a taxa de \"deixar\" em todos os pacotes.\nEla representa o número total de tokens de tea infundidos pelos mantenedores de pacotes, usuários de pacotes, apoiadores e patrocinadores de pacotes, e tasters de tea dividido pelo suprimento total de tokens de tea.\nDado quantos pacotes de código aberto estão disponíveis hoje e seu crescimento esperado, $\\chi$ será sempre um valor muito pequeno entre $0$ e $1$.\n\nConsidere $\\psi$ como a taxa de staking.\nEla representa o número total de tokens de ea apostados por qualquer participante da rede para garantir a segurança da rede.\n\nConsidere $\\chi_{ideal}$ como a taxa de infusão que gostaríamos que cada pacote alcançasse para uma distribuição justa de recompensas entre todos os pacotes e suas dependências.\nO valor de $\\chi_{ideal}$ deve ser atualizado à medida que novos pacotes são adicionados ao registro descentralizado e dependências são criadas.\nPara determinar o melhor valor para $\\chi_{ideal}$, usaremos uma curva de popularidade atualizada no início de cada ciclo de recompensas.\n\nConsidere $\\tau = \\tau(\\chi)$ como a taxa de juros anual de infusão distribuída a todos os membros da comunidade de tea que infundem tokens de tea para apoiar desenvolvedores de código aberto.\nEm outras palavras, $\\tau(\\chi)$ corresponde à recompensa de infusão recebida ao longo de um ano por um membro da comunidade que infunde tokens de tea durante todo o ano.\n\nConsidere $\\gamma = \\gamma(\\psi)$ como a taxa de juros anual de staking distribuída a todos os operadores de *nodes* e participantes da rede que apostam tokens de tea para garantir a rede.\nEm outras palavras, $\\gamma(\\psi)$ corresponde à recompensa de staking recebida ao longo de um ano por um membro da comunidade que aposta tokens de tea durante todo o ano.\n\nConsidere $\\delta$ como a inflação anual direcionada ao tesouro da rede.\n$\\delta$ pode variar à medida que fatores externos afetam o fornecimento de tokens.\n\nConsideramos a taxa de recompensa anual de infusão como uma função de $\\chi$ e a taxa de recompensa anual de staking como uma função de $\\psi$.\n\n* $\\tau(\\chi)$ corresponde ao incentivo para as pessoas infundirem um pacote.\nConforme $\\chi$ aumenta, são necessárias menos recompensas $\\tau(\\chi)$.\n* $\\gamma(\\psi)$ corresponde ao incentivo para as pessoas apostarem na rede.\nConforme $\\psi$ aumenta, são necessárias menos recompensas $\\gamma(\\psi)$ para garantir a rede\n\nA inflação anual $I$ será equivalente a $(\\tau + \\gamma + \\delta)$ e calculada da seguinte forma\n\n$$\nI = \\frac{\\textrm{oferta de tokens no final do ano} - \\textrm{oferta de tokens no início do ano}}{\\textrm{oferta de tokens no início do ano}} = (\\tau + \\gamma + \\delta)\n$$\n\nA contribuição para a inflação de $\\tau_{\\textsc{all}}$ (incentivo distribuído a todos os infusores de pacotes) e $\\gamma_{\\textsc{all}}$ (incentivo distribuído entre todos os contribuidores para a segurança da rede) deve ser ponderada para garantir que o sistema incentive a proporção ideal de infusão/aposta.\n\nEnquanto focamos nos incentivos distribuídos a todos os infusores de pacotes, determinamos que\n$\\tau_{\\textsc{all}}$\né uma função da taxa de infusão $\\chi$ e, portanto,\n$\\tau_{\\textsc{all}}(\\chi) = \\chi \\cdot \\tau(\\chi)$.\nA partir de nossa análise anterior, podemos ver que\n$\\tau_{\\textsc{all}}(\\chi_{ideal}) = \\chi_{ideal} \\cdot \\tau_{ideal}$.\nUma vez que o objetivo é atingir um estado onde\n$\\chi = \\chi_{ideal}$\n, as recompensas\n$\\tau_{ideal}(\\chi)$\ndevem ser máximas nesse valor.\n\nConsidere $\\tau_{ideal} = \\tau(\\chi_{ideal})$\ncomo a taxa de recompensa entregue pela rede no cenário ideal onde\n$\\chi = \\chi_{ideal}$.\n\nConsidere $\\tau_{0}$ como o limite de $\\tau_{\\textsc{all}}(\\chi)$ quando $\\chi$ tende a zero, quando nenhum membro da comunidade de tea infunde pacotes.\nO valor de $\\tau_{0}$ deve ser próximo de zero, mas não zero, para incentivar os primeiros adotantes.\nConforme sugerido pela pesquisa da Web3 Foundation, propomos que:\n\n* a função de inflação cresça linearmente entre $\\chi = 0$ e $\\chi = \\chi_{ideal}$, e\n* decaia exponencialmente entre $\\chi = \\chi_{ideal}$ e $\\chi = 1$.\n\nEscolhemos um decaimento exponencial semelhante para $\\tau_{\\textsc{all}}(\\chi)$ porque implica um decaimento exponencial de $\\tau(\\chi)$, e queremos que as recompensas caiam abruptamente além de $\\chi_{ideal}$ para evitar que um único pacote receba todas as recompensas.\n\nO decaimento é definido para que a taxa de inflação diminua no máximo em 50% quando $\\chi$ se desloca $d$ unidades à direita de $\\chi_{ideal}$ – ou seja,\n$\\tau_{\\textsc{all}}(\\chi_{ideal} + d) \\geq \\tau_{\\textsc{all}} \\cdot 0.5$.\n\nPropomos as seguintes funções de taxa de juros e inflação, que dependem dos parâmetros $\\chi_{ideal}$, $\\tau_{ideal}$, $\\tau_{0}$ e $d$.\n\n\\begin{align*}\n&\\tau_{\\textsc{all}}(\\chi) = \\tau_{0} + (\\tau_{\\textsc{all}}(\\chi_{ideal}) - \\tau_{0})\\frac{\\chi}{\\chi_{ideal}}\\enspace\\textrm{for}\\;0 < \\chi \\leq \\chi_{ideal} \\\\\n&\\tau_{\\textsc{all}}(\\chi) = \\tau_{0} + (\\tau_{\\textsc{all}}(\\chi_{ideal}) - \\tau_{0}) \\cdot 2^{(\\chi_{ideal}-\\chi)/d}\\enspace\\textrm{for}\\;\\chi_{ideal} < \\chi \\leq 1\n\\end{align*}\n\nAssim como os benfeitores precisam ser recompensados, os malfeitores precisam ser identificados e penalizados.\nO software de código aberto oferece muitas oportunidades para malfeitores criarem pontos de dor e riscos reputacionais para toda uma comunidade de desenvolvedores.\nDesde a apropriação indébita de trabalho até a alteração e redistribuição de pacotes de software, ou a inserção de código malicioso, a guerra entre bons e malfeitores continua, muitas vezes com malfeitores bem financiados que veem a contaminação de pacotes de código aberto como uma oportunidade de lucrar financeiramente.\nAs consequências têm sido relativamente mínimas, com pacotes potencialmente banidos das prateleiras digitais ou sujeitos a uma má reputação.\n\nPropomos a introdução de um mecanismo de corte para estabelecer uma desvantagem mais significativa que afete diretamente o valor econômico dos malfeitores.\nConforme os tea tasters avaliam e analisam o código nos pacotes recém-submetidos, sugerimos que recebam ferramentas e incentivos para identificar e destacar códigos maliciosos, de forma que os usuários dos pacotes possam ser alertados sobre os riscos, e os mantenedores do pacote, apoiadores do pacote e patrocinadores sejam penalizados por submeter ou apoiar código malicioso.\nNesse sentido, para todas as avaliações negativas evidenciadas conforme as regras da rede e que foram tratadas pelo mantenedor do pacote dentro do período definido pelo governo, o mantenedor do pacote não deve incorrer em nenhuma penalidade contrária aos apoiadores do pacote e patrocinadores, ou dos tea tasters que forneceram uma avaliação positiva do pacote em questão.\nPara avaliações negativas realizadas de acordo com as regras da rede e que o mantenedor do pacote não tenha abordado dentro do período definido pela governança, uma fração dos tokens infundidos pelo mantenedor do pacote, pelos apoiadores do pacote e patrocinadores, e pelos tea tasters anteriores será cortada.\nOutra fração será bloqueada em um pool de seguro controlado pela governança do tea.\nA governança do tea estabelecerá políticas e regras em estreita colaboração com a comunidade para distribuir o conteúdo do pool para aqueles afetados por vulnerabilidades.\nO protocolo distribuirá uma terceira fração dos tokens infundidos entre todos os tea tasters que contribuíram para a avaliação negativa e infundiram \"contra\" o pacote, com base no número de tokens de tea que infundiram \"contra\" o pacote e quanto tempo esses tokens foram infundidos.\nEm outras palavras, quanto mais cedo um ou mais tea tasters identificarem e relatarem a falha de acordo com as regras da rede, maior será a recompensa que receberão por apoiar o desenvolvimento de código aberto seguro e produtivo.\n\nPara evitar que os membros da comunidade votem aleatoriamente \"contra\" pacotes altamente infundidos na esperança de receber a maioria de qualquer penalidade, todos os tokens de tea infundidos \"contra\" não serão recompensados com inflação e podem estar sujeitos a um mecanismo de decaimento, reduzindo assim seu valor ao longo do tempo.\n\n[^19]: Fonte: @web3\n\n\n# Governança\n\nA governança é fundamental para o desenvolvimento, sustentabilidade e adoção de qualquer sistema distribuído.\n\nPropomos que o tea inclua uma governança on-chain, onde todos os detentores de tokens de tea possam sugerir e votar em mudanças nos parâmetros críticos ponderados pela posse de tokens e reputação.\nEsses parâmetros podem incluir inflação, taxas de transação, recompensas de staking, recompensas de infusão ou a proporção ideal de infusão. \nEssa funcionalidade garantirá que os parâmetros críticos possam evoluir e ser otimizados ao longo do tempo pelos membros da comunidade de tea.\nAntecipamos que a governança será lançada com uma estrutura simples e se expandirá progressivamente à medida que o sistema tea amadureça, facilitando a adoção e garantindo uma descentralização progressiva.\n\nAlguns parâmetros do sistema podem não estar sujeitos à governança ou apoiar mudanças de alta frequência para reduzir a superfície de ataque representada pela governança.\nUma transição progressiva dos parâmetros para uma governança aberta e descentralizada garantirá a estabilidade e previsibilidade do sistema.\n\n\n# Extensibilidade de Terceiros\n\nEnquanto construímos as ferramentas iniciais para impulsionar o suporte há muito esperado das comunidades de código aberto, acreditamos que parte de nossa missão é garantir que terceiros possam expandir o conjunto de ferramentas como um todo.\nAlém de fornecer a infraestrutura para os desenvolvedores criarem extensões para o protocolo, incluindo novas formas de inovar e ampliar o apoio aos desenvolvedores de código aberto, nossos planos incluem o potencial para outros gerenciadores de pacotes contribuírem para o protocolo.\nOs sonhos e esforços dos desenvolvedores de código aberto construíram a inovação que sustenta nossa vida cotidiana.\nEstamos ansiosos para descobrir os novos usos e extensões para o tea propostos pela comunidade tea.\n\n\n# Trabalho Futuro e Possíveis Esforços Comunitários\n\nÀ medida que o sistema tea amadurece, prevemos que a comunidade decida e contribua para alterações e extensões do sistema tea por meio da governança.\nAbaixo estão algumas ideias que acreditamos que possam inspirar alguns.\n\n## Atacadistas de tea\n\nAs comunidades de software de código aberto são vibrantes e estão sempre em busca de inovação e entrega de valor.\nEsta dedicação e altruísmo levam à constante construção de novos softwares e pacotes, cada um puxando dependências. Como resultado, antecipamos que o mapa de dependências evolua constantemente, levando a mudanças frequentes na proporção de infusão e recompensas.\nNo futuro, a comunidade tea pode propor o desenvolvimento de um sistema projetado para monitorar dinamicamente a proporção de infusão para cada pacote e reequilibrar como os apoiadores de pacotes infundem seus tokens com base em seus próprios critérios.\n\n## Royalties em Transferência de Pacotes\n\nReconhecemos que os mantenedores de pacotes podem decidir transferir sua fonte de recompensas de infusão para um ou mais desenvolvedores.\nA governança dessa transferência deve permanecer na decisão do mantenedor do pacote e de seus parceiros, sem interferência do tea.\nFerramentas serão necessárias para que essa transferência seja total ou parcial (talvez através de apenas uma parte das recompensas de infusão sendo redirecionada para um ou mais desenvolvedores, enquanto as recompensas restantes continuam a fluir para o mantenedor original do pacote)\ne para que as recompensas de infusão fluam por meio de uma única conta controlada por um único participante da rede, vários participantes da rede ou sejam distribuídas automaticamente entre várias contas usando proporções estáticas ou dinâmicas.\n\n## Distribuição de Recompensas Entre Múltiplos Mantenedores\n\nA manutenção de um pacote pode depender do trabalho de uma ou mais equipes de desenvolvedores.\nAntes que as recompensas de infusão comecem a fluir, as equipes devem considerar automatizar a distribuição das recompensas de infusão entre si.\nComo a distribuição ocorre deve ser decidido pelos mantenedores, já que estão na melhor posição para avaliar quem contribuiu e como devem ser recompensados.\nPara realizar isso, cada equipe (ou equipes) poderia criar sua própria organização autônoma descentralizada (DAO) e automatizar a distribuição de recompensas ou implementar sistemas mais complexos para determinar a distribuição adequada de recompensas com base em fatores externos, como um voto de todos os membros da DAO, ou distribuições baseadas no tempo com base em contribuições contínuas, conclusão bem-sucedida de recompensas, etc.\n\n## Tratamento de \"Forks\" de Pacotes\n\nAcreditamos que \"forks\" são essenciais e amplamente subutilizados.\n\"Forks\" podem ser uma ferramenta eficaz para desenvolver pacotes que competem em funcionalidade, desempenho, segurança e até mesmo atenção.\nPor mais úteis que possam ser, os \"forks\" devem reconhecer os esforços originais.\nAtravés de trabalho futuro ou contribuições potenciais, a comunidade tea pode aprimorar o sistema para exigir que os \"forks\" sejam declarados, talvez até detectados quando um pacote é submetido.\n\"Forks\" não declarados revelados por tea tasters podem resultar em uma parte dos tokens infundidos sendo cortados, transferidos para o mantenedor original do pacote e enviados aos tea tasters que revelaram o \"fork\"\n\n## Dependências de Tempo de Compilação vs. Dependências de Tempo de Execução\n\nO tea pode não distinguir as dependências de tempo de compilação das dependências de tempo de execução ao distribuir recompensas de infusão no lançamento.\nNo entanto, desde que a comunidade tea sinta fortemente a necessidade de fazer essa distinção, a comunidade tea pode propor melhorias ao algoritmo de distribuição de recompensas de infusão para considerar a criticidade de cada dependência e sua contribuição para o valor dos pacotes que dependem delas.\nEssas propostas seriam votadas e implementadas com base na decisão da comunidade.\n\n## Remuneração Baseada em Uso\n\nÀ medida que mais aplicações são construídas usando pacotes registrados com o tea, a comunidade pode aprimorar o algoritmo de recompensa para que a alocação possa ser influenciada por conjuntos de dados externos atestados, como o uso.\nEssa atualização do mecanismo de recompensas poderia permitir uma alocação maior de recompensas em tokens de tea para pacotes com o maior uso, ao mesmo tempo em que respeita as restrições da proporção de infusão descritas na seção de tokens de tea.\nOs mantenedores de pacotes poderiam usar uma abordagem semelhante para distribuir recompensas de infusão entre suas dependências com base na lógica transparente de sua escolha.\nObserve que todas as informações usadas para afetar a distribuição de recompensas entre pacotes e dependências no sistema tea precisarão ser comprovadamente confiáveis.\n\n\n# Agradecimentos\n\nEste white paper não existiria sem o apoio e dedicação de muitos entusiastas do tea.\nOs autores gostariam de agradecer a Josh Kruger, Jadid Khan e Jacob Heider por sua contribuição para a economia dos tokens e aos muitos indivíduos discretos que voluntariamente dedicaram seu tempo para fornecer feedback sobre o conteúdo deste documento.\n\n$\\parskip=0pt plus 1pt$\n\n# Glossário de Termos\n\n| Termo | Definição |\n|------|------------|\n| Folha | A menor denominação do token de tea. Uma folha corresponde a uma centésima milionésima ($10^{-8}$) parte de um tea. |\n| Slashing | A ação de penalizar infusores ou stakers em resposta a comportamentos contrários às regras da rede. |\n| Staking | A ação de travar tokens de tea para garantir a rede de prova-de-participação na qual o sistema de tea é construído. |\n| Infusão | A ação de travar tokens de tea para apoiar sua reivindicação e receber recompensas (ou penalidades) com base no consenso sobre a validade de sua reivindicação. |\n\n\n# Referências\n"
  },
  {
    "path": "i18n/vi/metadata.yml",
    "content": "title: Giao thức trả thưởng phi tập trung cho hệ sinh thái mã nguồn mở\nabstract: |-\n  Việc tạo một sổ đăng ký mở, công khai và có tính ổn định cho tất cả phần mềm\n  mã nguồn mở sẽ cấp quyền cho các dự án tự xuất bản các bản phát hành một cách\n  độc lập thay vì dựa vào các bên thứ ba, những người tập hợp dữ liệu phức tạp\n  này thành hàng trăm hệ thống riêng biệt (và trùng lặp). Những người bảo trì \n  gói sẽ xuất bản các bản phát hành của họ lên một sổ đăng ký phi tập trung\n  được cung cấp bởi chuỗi khối có khả năng chịu lỗi Byzantine để loại bỏ các\n  nguồn lỗi độc lập, cung cấp các bản phát hành bất biến và cho phép các cộng\n  đồng quản lý các khu vực của họ trong hệ sinh thái nguồn mở, độc lập với các\n  chương trình nghị sự bên ngoài.\n\n  Tea khuyến khích việc duy trì nguồn mở bằng cách cho phép những người tham\n  gia mạng stake giá trị vào các gói mà họ phụ thuộc và muốn bảo mật. Biểu đồ\n  của giao thức Tea cung cấp việc đăng ký các gói bất biến, các yêu cầu phụ\n  thuộc, tính xác thực của gói và các nguồn dữ liệu được sử dụng để truyền cho\n  thuật toán trả thưởng Tea. Lạm phát có hệ thống được phân phối cho tất cả các\n  gói dựa trên thuật toán đó. Nếu các vấn đề về bảo mật hoặc phát triển được\n  phát hiện, nhà phát triển có thể đưa ra yêu cầu được hỗ trợ bởi bằng chứng đó\n  và việc loại bỏ có thể xảy ra. Các thành viên của cộng đồng nguồn mở có thể\n  xem xét các vấn đề chất lượng của gói và giao thức có thể phản hồi các đánh\n  giá này bằng cách tạo các sự kiện sửa lỗi liên quan.\nauthor:\n- Max Howell\n- Timothy Lewis\n- Thomas Borrel\nreferences:\n- id: sources\n  url: https://github.com/teaxyz/white-paper\n- id: cc\n  url: https://creativecommons.org/licenses/by-sa/4.0/\n- id: nist\n  url: https://nvd.nist.gov/vuln/detail/CVE-2021-44228\n- id: reuters\n  url: https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA\n- id: twitter\n  url: https://twitter.com/yazicivo/status/1469349956880408583\n- id: w3\n  url: https://www.w3.org/TR/did-core/\n- id: theregister\n  url: https://www.theregister.com/2016/03/23/npm_left_pad_chaos/\n- id: fossa\n  url: https://fossa.com/blog/npm-packages-colors-faker-corrupted/\n- id: lunasec\n  url: https://www.lunasec.io/docs/blog/node-ipc-protestware/\n- id: github\n  url: https://github.com/dominictarr/event-stream/issues/116\n- id: zdnet\n  url: https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/\n- id: threatpost\n  url: https://threatpost.com/backdoor-found-in-utility-for-linux/147581/\n- id: fbi\n  url: https://www.fbi.gov/news/stories/phantom-secure-takedown-031618\n- id: europol\n  url: https://www.europol.europa.eu/media-press/newsroom/news/800-criminals-arrested-in-biggest-ever-law-enforcement-operation-against-encrypted-communication\n- id: medium\n  url: https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502\n- id: semver\n  url: https://semver.org/\n- id: npmjsCrossenv\n  url: https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry.html\n- id: npmjsLodash\n  url: https://www.npmjs.com/package/lodash\n- id: npmjsChalk\n  url: https://www.npmjs.com/package/chalk\n- id: npmjsLogFourjs\n  url: https://www.npmjs.com/package/log4js/\n- id: arxiv\n  url: https://arxiv.org/abs/1207.2617/\n- id: web3\n  url: https://research.web3.foundation/en/latest/polkadot/overview/2-token-economics.html\nheader-includes:\n- \\usepackage{fancyhdr,ragged2e}\n- \\lhead{\\parbox[t]{0.5\\textwidth}{\\RaggedRight\\rightmark\\strut}}\n- \\rhead{\\parbox[t]{0.5\\textwidth}{\\RaggedLeft\\leftmark\\strut}}\n- \\setlength{\\headheight}{5\\baselineskip}\n- \\pagestyle{fancy}\n- \\fancyfoot[LE,RO]{© 2022 tea.inc.}\n- \\fancyfoot[L]{v1.0.5+vi}\nlang: vi      # https://pandoc.org/MANUAL.html#language-variables\ndir: ltr      # language direction; ltr:left-to-right or rtl:right-to-left\ntranslator:\n  - Le  Phuoc Can"
  },
  {
    "path": "i18n/vi/white-paper.md",
    "content": "# Tuyên bố miễn trừ trách nhiệm\n\nThông tin nêu trong sách trắng này là thông tin sơ bộ. Do đó, cả tác giả cũng như bất kỳ nhánh tương ứng nào của họ đều không chịu bất kỳ trách nhiệm nào rằng thông tin nêu ở đây là cuối cùng hoặc chính xác và mỗi tuyên bố từ chối trách nhiệm nêu trên, trong phạm vi tối đa được luật hiện hành cho phép, bất kỳ và tất cả trách nhiệm pháp lý cho dù phát sinh trong hợp đồng, hoặc mặt khác liên quan đến sách trắng này. \nSách trắng này cũng như bất kỳ nội dung nào trong tài liệu này sẽ không tạo thành cơ sở hoặc được dựa vào có liên quan đến hoặc hành động như một sự xúi giục kêu gọi để ký kết bất kỳ hợp đồng hay cam kết nào.\n\nKhông có nội dung nào trong sách trắng này cấu thành một đề nghị bán hoặc chào mời mua bất kỳ mã thông báo nào được thảo luận ở đây. \nTrong bất kỳ trường hợp nào, liệu sách trắng này có được coi là một lời đề nghị hoặc lời chào mời như vậy không, không có lời đề nghị hoặc lời chào mời nào như vậy được dự định hoặc chuyển tải bởi sách trắng này ở bất kỳ khu vực tài phán nào nếu làm như vậy là bất hợp pháp, \nkhi lời đề nghị hoặc lời chào mời đó sẽ yêu cầu giấy phép hoặc đăng ký, hoặc khi đề nghị hoặc chào mời như vậy bị hạn chế. Đặc biệt, bất kỳ mã thông báo nào được thảo luận ở đây đều chưa được đăng ký theo chứng khoán hoặc luật tương tự của bất kỳ khu vực tài phán nào, \nkể từ ngày phát hành sách trắng này, cho dù khu vực tài phán đó có coi các mã thông báo đó là là chứng khoán hoặc công cụ tương tự và không được cung cấp hoặc bán ở bất kỳ khu vực tài phán nào nếu làm như vậy sẽ cấu thành vi phạm luật liên quan của khu vực tài phán đó.\n\n\n# Giấy phép\n\nMã nguồn[^src] của sách trắng này có sẵn theo giấy phép Creative Commons Attribution-ShareAlike 4.0 International[^cc].\n\n[^src]: Xem thêm: @sources\n[^cc]: Xem thêm: @cc\n\n\n# Lời nói đầu\n\nInternet chủ yếu bao gồm các dự án nguồn mở và chúng đã được thành lập.\nTheo thời gian, nhiều dự án này đã trở thành những phần nền tảng mà tất cả các đổi mới trong tương lai được xây dựng.\nVà trong khi vận may đã được tạo ra từ nó, nguồn mở chủ yếu được tạo ra và duy trì mà không cần trả phí.\n\nTo fully realize our potential, we need a fair remuneration system for the open-source ecosystem that doesn’t fundamentally change how it is built or utilized.\nChúng tôi tin rằng toàn bộ nỗ lực của con người hiện đại đã bị cản trở khi dựa vào phẩn ít các kỹ sư trên thế giới để lựa chọn giữa tiền lương hoặc duy trì hoạt động trên Internet.\nNguồn mở là lao động phi lợi nhuận thường bị cản trở do thiếu các động cơ về kinh tế dẫn đến các dự án thực sự đáng giá không bao giờ đạt được tiềm năng của chúng trong khi các dự án khác gặp vấn đề về bảo mật do thiếu các động lực để duy trì phần mềm trong suốt vòng đời của nó. \nĐể nhận ra đầy đủ tiềm năng của chúng tôi, chúng tôi cần một hệ thống trả thù lao công bằng cho hệ sinh thái nguồn mở mà không thay đổi về cơ bản cách nó được xây dựng hoặc sử dụng.\n\nCác doanh nghiệp thường bao bọc các mô hình kinh doanh xung quanh mã nguồn mở, tạo doanh thu trực tiếp từ công việc của các nhà phát triển cốt lõi từ trong khi cũng dựa vào chúng để khắc phục lỗi khi xảy ra vấn đề. \nMột ví dụ tuyệt vời là một sự cố gần đây liên quan đến lỗ hổng bảo mật quan trọng trong Log4j, một gói từ Quỹ phần mềm Apache đã tìm thấy trên nhiều phần mềm và dịch vụ thương mại được sử dụng bởi các doanh nghiệp và chính phủ.\nVào tháng 11 năm 2021, một nhà nghiên cứu bảo mật làm việc cho Alibaba Group Holding Ltd. đã báo cáo lỗ hổng CVE-2021-44228[^1], nhận được điểm cơ bản cao nhất có thể từ Quỹ phần mềm Apache. Amit Yoran, giám đốc điều hành của Tenable và Giám đốc sáng lập của đội ngũ sẵn sàng khẩn cấp máy tính Hoa Kỳ (US-CERT), đã mô tả lỗ hổng này là một lỗ hổng lớn nhất trong thập kỷ qua[^2]. \nPanic xảy ra sau đó và một vài tình nguyện viên duy trì gói này đã công khai bị sa thải vì thất bại. \nSau khi giải quyết sự phẫn nộ với một lời cầu xin khiêm tốn cho sự công bằng, các hệ thống đã được vá lại. \nCác doanh nghiệp và chính phủ cuối cùng đã nhận ra rằng Log4j, một gói được sử dụng bởi một loạt các hệ thống quan trọng trong hai thập kỷ, được duy trì bởi một vài tình nguyện viên không được trả lương, cùng một anh hùng vô danh đã hành động bất chấp sự lạm dụng của ngành công nghiệp[^3] và làm việc không mệt mỏi để giải quyết lỗ hổng.\n\nĐáng buồn thay, Log4j không phải là ví dụ duy nhất.\ncore-js được tải xuống 30 triệu lần mỗi tuần dưới dạng cơ sở của mọi ứng dụng Node.js, nhưng nó cũng hầu như không được tài trợ.\nGần đây, một số nhà phát triển Bitcoin Core đã từ chức, trích dẫn, trong số các lý do khác, *thiếu lợi ích tài chính* cho quyết định của họ.\n\nĐã có nhiều nỗ lực cung cấp các cấu trúc khuyến khích, thường liên quan đến các hệ thống tài trợ và tiền thưởng. \nKhoản tài trợ giúp người tiêu dùng có thể quyên góp cho các dự án mà họ ủng hộ.\nTuy nhiên, bức tranh mã nguồn mở như một tòa tháp bằng gạch nơi các lớp thấp hơn bị lãng quên từ lâu, nhưng vẫn được duy trì bởi các kỹ sư chuyên dụng và dựa vào nhiều nhà phát triển hơn nữa.\nChỉ các dự án ở đầu tháp thường được biết đến và nhận tài trợ. Lựa chọn thiên vị này dẫn đến những viên gạch thiết yếu giữ tòa tháp không thu hút được sự đóng góp, trong khi các mục yêu thích nhận được nhiều hơn họ cần.\nBounties cho phép người tiêu dùng các dự án đề xuất thanh toán cho các nhà phát triển để xây dựng các tính năng cụ thể, do đó chỉ các dự án trả thù lao để làm những việc không nhất thiết là lợi ích tốt nhất của họ. \nVà một lần nữa, chỉ có yêu thích bổ ích.\n\nTrong bài báo này, chúng tôi đề xuất Tea — một hệ thống phi tập trung cho các nhà phát triển mã nguồn mở nhận thù lao một cách công bằng dựa trên sự đóng góp của họ cho toàn bộ hệ sinh thái và được ban hành thông qua thuật toán khuyến khích Tean được áp dụng trên tất cả các mục trong đăng ký Tea.\n\n![Góc nhìn đơn giản của hệ thống phần thưởng Tea.](img/figure-1.svg)\n\n$\\parskip=0pt plus 1pt$\n\n[^1]: Nguồn: @nist\n[^2]: Nguồn: @reuters\n[^3]: Nguồn: @twitter\n\n\n# Các thành phần\n\nMột nhà phát triển phần mềm xây dựng một ứng dụng cần bốn điều: trình duyệt, thiết bị đầu cuối, trình soạn thảo và người quản lý gói.\nTrong số bốn người này, trình quản lý gói là thứ kiểm soát công cụ và khung mà nhà phát triển cần xây dựng sản phẩm của họ.\nLớp này là nơi chúng ta thấy tiềm năng để thay đổi cách thức nguồn mở được trả thù lao.\n\n## Người quản lý gói\n\nNgười quản lý gói biết phần mềm mã nguồn mở mà một ứng dụng phụ thuộc vào chức năng, từ ngọn ngành đến gốc rể của nó.\nMỗi thành phần và phiên bản cần thiết cho ứng dụng được biết và ghi lại.\nNó biết rằng đỉnh của tòa tháp cẩn thận chọn các đối tượng phụ thuộc của nó và sự lựa chọn cẩn thận đó tiếp tục xuống.\nTrình quản lý gói được đặt duy nhất trong ngăn xếp công cụ nhà phát triển để cho phép phân phối giá trị chính xác và tự động dựa trên việc sử dụng trong thế giới thực thực tế.\n\nChúng tôi đề xuất một cơ quan đăng ký phi tập trung bất biến được thiết kế để phân phối giá trị dựa trên một thuật toán xác định mỗi đóng góp của mục nhập vào tiện ích và sức khỏe của hệ thống.\nGiá trị có thể nhập biểu đồ tại các điểm ứng dụng Apex và các thư viện thiết yếu và được phân phối cho các đối tượng phụ thuộc của các điểm Apex đó và các đối tượng phụ thuộc của chúng một cách đệ quy vì Cơ quan đăng ký biết toàn bộ biểu đồ nguồn mở.\n\nNgoài ra, chúng tôi tin rằng thông tin vật liệu phải có sẵn thông qua trình quản lý gói cho các nhà phát triển để đánh giá xem họ có thể tin tưởng một gói và tác giả của nó hay không.\nThông tin này có thể dựa trên danh tiếng, danh tiếng cộng đồng, dữ liệu được lấy từ các hệ thống nhận dạng phi tập trung (DID[^4]), các nhà quản lý gói khác hoặc các cơ chế khuyến khích có khả năng dựa vào những người tham gia mạng gây rủi ro cho giá trị kinh tế.\n\nChúng tôi dự đoán rằng sự kết hợp các công cụ của Tea, thông tin và phần thưởng sẽ khuyến khích các nhà phát triển, giúp kích thích sự phát triển của phần mềm nguồn mở và thúc đẩy đổi mới.\n\n[^4]: Xem thêm: @w3\n\n## Cơ quan đăng ký phi tập trung\n\nMỗi người quản lý gói đều có sổ đăng ký gói riêng lặp lại cùng một siêu dữ liệu.\nĐó là thời gian có một cơ quan đăng ký duy nhất, toàn diện và dứt khoát được thiết kế và chi phối bởi các cộng đồng phụ thuộc vào nó.\nCơ quan đăng ký bất biến, phi tập trung này có thể cung cấp bảo mật, ổn định và ngăn chặn ý định xấu xa.\n\nInternet chạy trên hàng chục ngàn thành phần mã nguồn mở quan trọng.\nĐiều đáng chú ý là cho đến nay, các sự cố gây ra bởi việc loại bỏ cơ sở hạ tầng mã nguồn mở thiết yếu là tối thiểu.\nNổi tiếng nhất là việc loại bỏ sự phụ thuộc pad[^5]-trái NPM vào năm 2016, được xếp vào các hệ thống tích hợp liên tục và triển khai liên tục khiến các nhà phát triển bỏ mặt trong nhiều ngày.\nSự kiện này đã chứng minh rằng bản thân Internet dựa trên các hệ thống phát triển mong manh.\nCác ví dụ khác liên quan đến sự tham gia tích cực hoặc có chủ ý từ người bảo trì gói độc hại phổ biến của họ (Xem colors.js, faker.js[^6], and node-ipc[^7]) hoặc các tác nhân xấu đang tìm kiếm lợi nhuận bằng cách giả vờ duy trì các gói và làm hỏng chúng để đánh cắp, cho ví dụ, các khóa riêng Bitcoin (xem luồng sự kiện[^8]) hoặc các gói độc hại có lỗi chính tả có chủ ý, còn được gọi là lỗi chính tả, với hy vọng lừa người dùng cài đặt chúng, ví dụ như các gói NPM crossenv vs. cross-env [^npmjsCrossenv].\n\nTính toàn vẹn của phần mềm cần được đảm bảo khi ngành công nghiệp tiến tới một tương lai nơi tài sản kỹ thuật số là một phần của phần mềm.\nChúng ta không thể tiếp tục khiến bản thân dễ bị tổn thương trước các diễn viên độc hại sửa đổi phần mềm.\n\nHầu hết các công cụ mà chúng tôi gọi là trình quản lý gói không thể đảm bảo rằng các gói này được tích hợp trong các apps và dApps là mã nguồn mở không thay đổi được xuất bản bởi các tác giả ban đầu của chúng. \nGithub của Microsoft đã phát hiện ra rằng 17% lỗ hổng trong phần mềm được nuôi cấy cho mục đích độc hại[^9], với một số còn lại không bị phát hiện trong thời gian dài (xem Webmin 1.890[^10]).\n\nMột cơ quan đăng ký phi tập trung được tăng cường bởi một hệ thống danh tiếng và được hỗ trợ bởi các ưu đãi kinh tế được thiết kế để phơi bày các tác nhân xấu và phần thưởng cho các diễn viên giỏi có thể cung cấp cho các cộng đồng phát triển bảo đảm.\n\n[^5]: Nguồn: @theregister\n[^6]: Nguồn: @fossa\n[^7]: Nguồn: @lunasec\n[^8]: Nguồn: @github\n[^npmjsCrossenv]: Nguồn: @npmjsCrossenv\n[^9]: Nguồn: @zdnet\n[^10]: Nguồn: @threatpost\n\n\n## Hệ thống lưu trữ\n\nCác gói nguồn mở cung cấp một loạt các chức năng, một số trong đó có thể bị hạn chế hoặc không mong muốn.\nMã hóa là một ví dụ tuyệt vời về điều đó. Một trường hợp sử dụng quan trọng để mã hóa là sự hỗ trợ của sự riêng tư của cá nhân trên toàn cầu.\nTuy nhiên, mã hóa cũng có thể được sử dụng cho các mục đích bất chính (xem bảo mật Phantom, bị dỡ bỏ bởi các cơ quan thực thi pháp luật vào tháng 3 năm 2018[^11]) hoặc có thể bị xâm phạm để hỗ trợ các hoạt động thực thi pháp luật (xem Chiến dịch Ironside (AFP), Chiến dịch Greenlight (Europol),\nvà hoạt động Trojan Shield (FBI)[^12] nơi mà FBI vận hành một nền tảng truyền thông “được mã hóa”, AN0M, và đã thuyết phục tội phạm sử dụng điện thoại được mã hóa trên mạng của họ để giao tiếp an toàn).\n\nCác ứng dụng rộng rãi của mã hóa đã làm cho nó trở thành một trường hợp sử dụng hoàn hảo cho phần mềm nguồn mở và một ví dụ tuyệt vời cho thấy bất kỳ giải pháp nào lưu trữ các gói phải chống giả mạo và chống kiểm duyệt.\nTea là một giao thức phi tập trung không có ý định lọc hoặc xử phạt các gói dựa trên chức năng của chúng. \nMặc dù quản trị Tea có thể chọn loại bỏ các gói độc hại đã được chứng minh (xem phần Quản trị để biết thêm thông tin), nhưng điều quan trọng đối với hệ thống Tea là kết nối với nhiều hệ thống lưu trữ, bao gồm các hệ thống phi tập trung chứng minh rằng một gói không được thay đổi và sao chép chính xác.\nNgười bảo trì gói có thể chọn hệ thống lưu trữ phù hợp nhất với nhu cầu lưu trữ và phân phối các gói của họ một cách an toàn.\n\n[^11]: Nguồn: @fbi\n[^12]: Nguồn: @europol\n\n# Những người tham gia mạng lưới\n\nNhiệm vụ của Tea là trao quyền cho các cộng đồng nguồn mở và đảm bảo những người đóng góp của họ được hỗ trợ khi họ tạo ra các công cụ xây dựng Internet.\nTrong sách trắng này, chúng tôi phân biệt người tham gia thông qua những đóng góp của họ.\nMột số có thể đóng góp mã hoặc xác minh mã đóng góp.\nNhững người khác có thể cung cấp giá trị kinh tế để hỗ trợ các nhà phát triển và danh tiếng của họ.\n\n## Người bảo trì gói\n\nNgười bảo trì gói phải đảm bảo phần mềm của họ tiếp tục mang lại giá trị ngày càng tăng khi ngành công nghiệp phát triển.\n\nTea giả định rằng những người sáng tạo gói duy trì công việc của họ.\nNgười bảo trì gói là trụ cột của các cộng đồng nguồn mở, những người cần được trao quyền và thưởng cho những đóng góp liên tục của họ.\nNgười bảo trì gói có thể quyết định ngừng nỗ lực bảo trì của họ hoặc nhận ra rằng họ không thể hoạt động với tốc độ phù hợp với mong đợi của người dùng gói.\nCác nhà bảo trì gói nhận được Token không thể thay thế (NFT) khi họ hoàn thành việc gửi gói (xem phần NFT duy trì để biết thêm chi tiết).\nNFT này được sử dụng để chứng minh công việc của họ và là chìa khóa chỉ đạo phần thưởng Tea. Người nắm giữ NFT của gói có thể chuyển quyền sở hữu của mình cho một nhà phát triển khác (hoặc nhóm nhà phát triển), do đó họ trở thành bảo trì gói và người nhận bất kỳ phần thưởng nào trong tương lai.\nTương tự, một nhà phát triển có thể quyết định đảm nhận vai trò bảo trì gói bằng cách lấy gói hiện tại và gửi một gói mới mà họ sẽ duy trì tiến về phía trước, do đó tự trở thành người tạo và bảo trì gói.\n\nĐiều cần thiết là cung cấp cho các cộng đồng nhà phát triển các công cụ phù hợp để xác định các gói nào đang được duy trì và những người bảo trì trong quá khứ và hiện tại của họ danh tiếng và chất lượng công việc.\nChúng tôi thường thấy công việc mã nguồn mở bị giả mạo và những nỗ lực của nhiều người bị hủy hoại bởi các thành phần xấu.\nMặc dù công việc của các tác nhân xấu này phần lớn được phát hiện và khắc phục, nhưng thường phải phát sinh ra thiệt hại đáng kể thông qua mất tài chính hoặc dữ liệu.\nLấy ví dụ, gói NPM EventStream[^13] đã được tải xuống hơn 1,5 triệu lần mỗi tuần và dựa vào hơn 1.500 gói khi một hacker quản lý để thâm nhập dự án nguồn mở, hãy lấy sự tin tưởng của tác giả ban đầu và sửa đổi EventStream để phụ thuộc vào một điều độc hại Gói sẽ vượt qua thông tin về ví Bitcoin cho máy chủ của bên thứ ba\\.\nMặc dù các công cụ có thể giúp phát hiện một số cuộc tấn công này, nhưng chúng không thể luôn luôn dựa vào, điều này tạo ra toàn bộ cộng đồng phụ thuộc vào sự siêng năng và sẵn sàng chia sẻ phát hiện của họ.\n\nChúng tôi đề xuất giới thiệu các ưu đãi thông qua mã thông báo Tea được mô tả trong phần mã thông báo Tea, khuyến khích các cộng đồng nguồn mở báo cáo phát hiện của họ một cách xây dựng, vì vậy các nhà bảo trì gói có thể giải quyết chúng trước khi chúng bị khai thác.\n\n[^13]: Nguồn: @medium\n\n## Người sử dụng gói\n\nNgười dùng gói là các nhà phát triển phần mềm tập trung vào việc giải quyết một vấn đề cụ thể.\nHọ thường tìm kiếm trong cộng đồng nguồn mở cho các công cụ họ cần thử nghiệm một cách nhanh chóng và lặp đi lặp lại với rất ít chi phí, được hưởng lợi trực tiếp từ công việc của người tạo và bảo trì gói.\nTheo truyền thống, một tập hợp con có thể đã chọn để hỗ trợ người bảo trì gói thông qua quyên góp hoặc các hình thức thù lao khác; Tuy nhiên, trường hợp này hiếm khi xảy ra.\n\nTài trợ có thể là một hệ thống hiệu quả để hỗ trợ phát triển nguồn mở; Tuy nhiên, thù lao thường không mở rộng cho tất cả các phụ thuộc.\nHạn chế này có lợi cho mục yêu thích và cản trở sự đổi mới và xây dựng phần mềm.\nĐể phấn đấu làm nền tảng phát triển phần mềm, nguồn mở phải trao quyền cho tất cả các nhà phát triển, cho dù là người mới bắt đầu hay chuyên gia, trên tất cả các lớp trong tháp.\n\ntea’s purpose is to maintain the core values of open-source software while providing a decentralized system to remunerate package maintainers for their work.\nTo deliver on this mission, tea intends to develop — and incentivize others to develop — mechanisms for package users to support package maintainers through unique use cases of the tea token, as described in the tea token and future work and potential community effort sections.\nMục đích của Tea là để duy trì các giá trị cốt lõi của phần mềm mã nguồn mở trong khi cung cấp một hệ thống phi tập trung cho các nhà bảo trì gói thù lao cho công việc của họ. Để thực hiện nhiệm vụ này, Tea dự định phát triển — và khuyến khích những người khác phát triển — các cơ chế cho người dùng gói để hỗ trợ người bảo trì gói thông qua các trường hợp sử dụng độc đáo của mã thông báo Tea, như được mô tả trong mã thông báo Tea và các phần nỗ lực cộng đồng tiềm năng và trong tương lai.\n\n## Những người ủng hộ và nhà tài trợ gói\n\nTrong Web 2.0 và Web3, những người ủng hộ gói thường được gọi là “nhà tài trợ”. Họ là các tổ chức hoặc người dùng gói sử dụng phần mềm nguồn mở để xây dựng các sản phẩm thương mại của họ, các nhà từ thiện tìm cách hỗ trợ hệ sinh thái hoặc các doanh nhân muốn tài trợ cho các nhóm để phát triển các thành phần của một hệ thống lớn hơn.\n\nTea đề xuất mở rộng cộng đồng của những người ủng hộ gói cho toàn bộ cộng đồng Tea, cho dù các tổ chức, nhà phát triển, người dùng hoặc những người đam mê công nghệ.\nMục tiêu của Tea là thực hiện các cơ chế khuyến khích phi tập trung thông qua các trường hợp sử dụng độc đáo của mã thông báo Tea cho bất kỳ thành viên nào của cộng đồng Tea để đóng góp cho sự bền vững vĩnh viễn và tăng trưởng liên tục của mã nguồn mở.\nNhững người ủng hộ và nhà tài trợ gói có thể tự do quyết định các gói hoặc người bảo trì gói mà họ muốn hỗ trợ dựa trên công việc, niềm tin hoặc bất kỳ tiêu chí và số liệu nào sẽ ảnh hưởng đến quyết định của họ.\nNgoài ra, sự hỗ trợ được cung cấp bởi những người ủng hộ và tài trợ của gói sẽ chảy vào từng phụ thuộc của gói, do đó hoàn toàn tin tưởng vào người bảo trì gói để đưa ra lựa chọn tốt về ngăn xếp của họ và sử dụng thông tin này để đóng góp cho danh tiếng của họ.\n\nVới điều kiện là người bảo trì gói cung cấp dịch vụ đó, người hỗ trợ và tài trợ gói có thể nhận lại được mức hỗ trợ cao cấp NFT, do đó được hưởng lợi từ SLAs được tăng tốc hoặc cấp phép linh hoạt hơn.\nNgoài ra, những người ủng hộ và tài trợ gói có thể quyết định hỗ trợ các gói hoặc người bảo trì gói và tự động chuyển hướng tất cả hoặc tỷ lệ phần trăm phần thưởng của họ để khuyến khích các nhóm xây dựng phần mềm nguồn mở mới. Nói cách khác, các gói don don cần tồn tại để Tea để bắt đầu đổ vào.\nCác dự án mới sinh có thể được hỗ trợ cũng như những dự án trưởng thành hơn, khuyến khích thêm một cảnh quan nguồn mở liên tục.\n\n## Người thử nghiệm Tea\n\nKhi các gói mới hoặc phiên bản mới của các gói hiện tại được phát hành, tính hợp lệ của công việc cần phải được chứng minh một cách chắc chắn.\nThông tin này rất quan trọng đối với người dùng gói để quyết định có tin tưởng cả gói và người bảo trì của nó hay không.\nVới giao thức Tea, chức năng này được cung cấp bởi người thử nghiệm Tea.\n\nNhững người thử nghiệm Tea, thông thường, là những nhà phát triển phần mềm có kinh nghiệm sẵn sàng dành một phần thời gian của họ để kiểm tra các khiếu nại liên quan đến gói (chức năng, bảo mật, phiên bản ngữ nghĩa[^14], độ chính xác của giấy phép, v.v.) \nvà đặt ra cả danh tiếng và giá trị kinh tế của họ để chứng minh kết quả nghiên cứu và phân tích của họ và hỗ trợ đánh giá của họ. \nNhững người thử nghiệm Tea nhận được phần thưởng cho sự siêng năng và nỗ lực của họ. \nTại Tea, chúng tôi gọi là “dựa vào Tea của bạn” hành động khóa các mã thông báo Tea để hỗ trợ đánh giá của bạn và nhận phần thưởng (hoặc hình phạt) dựa trên sự đồng thuận về tính hợp lệ của các đánh giá của bạn.\n\nGiống như những người ủng hộ gói, người thử nghiệm Tea có thể ảnh hưởng đến một gói và gói danh tiếng của người bảo trì gói; Tuy nhiên, tác động của chúng có ý nghĩa hơn với vai trò của họ trong việc xác nhận bảo mật, chức năng và chất lượng của gói. \nngười thử nghiệm Tea cũng sẽ cần xây dựng danh tiếng của họ để hỗ trợ cho các yêu cầu của họ. \nChất lượng công việc của họ và giá trị kinh tế mà họ gặp rủi ro khi họ nhấn mạnh các đánh giá của họ kết hợp với các nguồn dữ liệu bên ngoài khác sẽ xây dựng từng danh tiếng của mỗi người khai thác Tea, mang lại nhiều giá trị hơn cho công việc của họ. \nXem phần Danh tiếng của gói để biết thêm chi tiết về các cơ chế được sử dụng để ảnh hưởng đến một gói và danh tiếng của người bảo trì gói.\n\n[^14]: Xem thêm: @semver\n\n# Tổng quan về giao thức\n\nThiết kế của một giao thức để thưởng cho các đóng góp nguồn mở được sa lầy với những thách thức.\nPhần mềm nguồn mở theo định nghĩa mở cho tất cả mọi người và có thể, như kết quả, có thể phải chịu sự phân phối sai, chiếm đoạt hoặc giả mạo độc hại. \nTuy nhiên, cộng đồng nguồn mở đã liên tục thể hiện sự sẵn sàng làm nổi bật các diễn viên giỏi và phơi bày các diễn viên xấu. \nTrong lịch sử, năng lượng dành cho việc xem xét và bình luận về các nhà phát triển khác đóng góp của các nhà phát triển khác đã được tự nguyện hoàn toàn, mặc dù có thể báo cáo và bảo vệ quan trọng như thế nào.\n\nChúng tôi dự định tạo ra một nền tảng phân phối không đáng tin cậy cho các ứng dụng được bảo đảm bởi danh tiếng và ưu đãi tài chính, vì chúng tôi tin rằng phần thưởng đầy đủ cho các đóng góp nguồn mở không thể thành công mà không có cả hệ thống danh tiếng và khả năng của các thành viên trong cộng đồng để truyền đạt phát hiện và hỗ trợ của họ (hoặc bất đồng chính kiến) cho một gói hoặc công việc của một nhà phát triển.\n\nChúng tôi phải cung cấp cho các nhà phát triển các công cụ để truy cập và đóng góp cho hệ thống danh tiếng này. \nCác công cụ bao gồm quyền truy cập trực quan và lập trình đơn giản vào phiên bản và danh tiếng của tất cả các phụ thuộc trong các gói của họ. \nMột sự hiểu biết rõ ràng về những thành viên cộng đồng nào hỗ trợ từng gói và số lượng mã thông báo Tea họ sẽ đóng góp vào danh tiếng của mỗi gói, giống như một người bảo trì gói đang giảm bao nhiêu công việc của họ giao tiếp với công việc của họ bao nhiêu. \nNhững điểm dữ liệu kết hợp này sẽ giúp thông báo cho một hệ thống danh tiếng cho tất cả các thành viên cộng đồng và tạo điều kiện cho sự lựa chọn. Vì gói EventStream không được thực hiện thông qua chính gói, nhưng thông qua một trong những phụ thuộc của nó, khả năng hiển thị trên tất cả các lớp phụ thuộc sẽ rất quan trọng để xây dựng hệ thống không đáng tin cậy này. \nTuy nhiên, các cân nhắc như chi phí tính toán và giao dịch (“gas”) sẽ cần được ưu tiên vì hệ thống được thiết kế và xây dựng.\n\nMục tiêu của chúng tôi là thưởng cho cả các nhà phát triển Web 2.0 và Web3. \nSự phức tạp và chi tiết cụ thể của mỗi ngăn xếp làm cho nó để theo dõi các cài đặt và gỡ bỏ các gói có thể dễ dàng trở thành nạn nhân của một hoặc nhiều tác nhân xấu. \nĐiều đó bao gồm các cài đặt mua hàng của người Viking để làm tăng số lượng nhân tạo. \nMột kịch bản thậm chí còn tồi tệ hơn sẽ giới thiệu những thay đổi cơ bản về bản chất của phần mềm nguồn mở bằng cách tạo ra ma sát không cần thiết với các khóa cấp phép hoặc các cơ chế theo dõi triển khai khác. \nĐể cung cấp phạm vi bảo hiểm rộng nhất, chúng tôi tin rằng phần thưởng phải dựa vào một khái niệm đơn giản về việc theo dõi cài đặt hoặc gỡ cài đặt, mà là các cơ chế khuyến khích khuyến khích việc gửi các gói chất lượng và báo cáo các gói có rủi ro cao hoặc có rủi ro cao. \nCuối cùng, nhiều gói dựa vào các phụ thuộc chung. \nVí dụ, Lodash có 151.209 người phụ thuộc[^15] trong khi thật sự có 78.854 người phụ thuộc[^16] hoặc Log4js có 3.343 người phụ thuộc[^17]. \nKhi nhiều gói được tạo ra bằng cách sử dụng cùng một phụ thuộc, làm thế nào để chúng tôi đảm bảo rằng các ưu đãi được phân phối công bằng và công bằng? \nLàm thế nào để chúng tôi đảm bảo rằng các phụ thuộc được sử dụng nhiều nhất được thưởng mà không bỏ đói các gói và nhà phát triển mới hoặc mới nổi? \nLàm thế nào để chúng tôi đảm bảo rằng hệ thống khuyến khích không kết thúc các nhà phát triển lái ra khỏi các ngôn ngữ thích hợp để tập trung chúng nơi các ưu đãi tốt hơn? \nNhưng cũng là nhà phát triển, làm thế nào để chúng tôi xác định các gói có nhiều người phụ thuộc nhất để xây dựng các lựa chọn thay thế - các phiên bản được mã hóa tốt hơn, hiệu quả hơn, được mã hóa tốt hơn của các gói này? \nTại Tea, chúng tôi tin rằng việc thiếu khuyến khích đã cản trở sự phát triển của phần mềm nguồn mở. \nĐược hỗ trợ bởi các ưu đãi và phần thưởng kinh tế phù hợp, nhiều nhà phát triển sẽ ở vị trí để xây dựng, cải thiện và tăng cường phần mềm nguồn mở để cải thiện thế giới. \nChỉ sau đó, mã thông báo Tea mới có thể đại diện cho tổng giá trị của phần mềm nguồn mở.\n\n[^15]: Nguồn: @npmjsLodash\n[^16]: Nguồn: @npmjsChalk\n[^17]: Nguồn: @npmjsLogFourjs\n\n## Đóng gói\n\nViệc gửi bản phát hành gói đòi hỏi nhiều giao dịch độc quyền diễn ra. \nCụ thể, người bảo trì gói phải:\n\n* Đăng ký gói (và phiên bản ngữ nghĩa của nó) với sổ đăng ký phi tập trung.\n* Tải gói vào hệ thống lưu trữ phi tập trung để có khả năng phục hồi, kháng kiểm duyệt và dễ phân phối.\n* Đóng góp cho danh tiếng của gói và sự đáng tin cậy bằng cách *nhúng* token Tea.\n\nThất bại của bất kỳ một trong ba hoạt động sẽ dẫn đến giao thức trở lại trạng thái trước đó, do đó loại bỏ bất kỳ bằng chứng nào về việc xác nhận.\n\nKhi một gói được gửi thành công, người bảo trì gói sẽ nhận được NFT duy trì để chứng minh công việc và đóng góp của họ cho nguồn mở. \nNgười bảo trì gói có thể chuyển phần thưởng liên quan đến người bảo trì NFT sang bên thứ ba. \nTuy nhiên, danh tiếng liên quan đến việc tạo và bảo trì tài sản sẽ vẫn còn với người bảo trì gói, vì vậy danh tiếng của họ có thể bị ảnh hưởng theo thời gian. \nVì danh tiếng của bất kỳ thành viên nào của cộng đồng Tea đạt được các cột mốc quan trọng, họ có thể được cấp quyền truy cập vào các phần nâng cao của giao thức hoặc nhận phần thưởng được tăng tốc, theo quyết định của quản trị Tea. \nĐể biết thêm chi tiết về NFT bảo trì, hãy xem phần NFT duy trì.\n\n### Phân tích phụ thuộc\n\nGói phụ thuộc có thể chạy sâu, vì mỗi gói thường có cả người phụ thuộc và phần phụ thuộc. \nĐể cung cấp một phương pháp đơn giản thưởng cho tất cả các nhà phát triển đã đóng góp cho phần mềm nguồn mở trong khi vẫn giữ cho việc tạo ra cây phụ thuộc nhanh chóng và tính toán hiệu quả, chúng tôi đề xuất chỉ xác minh các phụ thuộc cấp một khi gửi gói.\n\nThiết kế này được thúc đẩy bởi giả thuyết rằng mỗi phụ thuộc là một gói được gửi độc lập cho cây Tea. \nKhi làm như vậy, mỗi phụ thuộc của nó có thể được ánh xạ và nếu chính phụ thuộc của nó có sự phụ thuộc, chúng sẽ được ánh xạ tại thời điểm gói phụ thuộc được gửi.\n\n![Sơ đồ phân tích phụ thuộc.](img/figure-3.svg){#fig:dep-analysis}\n\n\nIn @fig:dep-analysis, the submission of package A triggers an analysis of runtime dependencies 1 through n and build dependencies 1 through n, while runtime dependencies 1.1 through 1.n and build dependencies 1.1 through 1.n were analyzed when package B was submitted.\nWe will apply the same methodology for incentive distribution as the steeped tokens are distributed across all dependencies, thus recursively steeping the packages listed as dependencies (see @fig:steeping-rewards).\nTrong @fig:dep-analysis, việc gửi gói A kích hoạt phân tích các phụ thuộc thời gian chạy 1 đến N và xây dựng phụ thuộc 1 đến N, trong khi các phụ thuộc thời gian chạy 1.1 đến 1.n và xây dựng phụ thuộc 1.1 đến 1.n được phân tích khi gói B đã được gửi. \nChúng tôi sẽ áp dụng phương pháp tương tự cho phân phối khuyến khích khi các mã thông báo được phân phối trên tất cả các phụ thuộc, do đó đệ quy các gói được liệt kê là phụ thuộc (xem @fig:steeping-rewards).\n\n![Phân phối phần thưởng dốc trên các phụ thuộc.](img/figure-2.svg){#fig:steeping-rewards}\n\n\nPhiên bản và phụ thuộc mâu thuẫn là những thách thức đáng kể, và việc khắc phục chúng có thể biến thành cống lớn thời gian. \nĐể giải quyết vấn đề này, chúng tôi đề xuất mỗi gói phải tuân theo quét phụ thuộc toàn diện khi gửi để chúng tôi có thể đảm bảo rằng gói tuân thủ các quy tắc sau cho phạm vi phiên bản ngữ nghĩa.\n\n* Các gói chỉ có thể ràng buộc các phụ thuộc của chúng vào một phiên bản chính, mặc dù việc bắt đầu phạm vi có thể là bất kỳ phiên bản ngữ nghĩa hợp lệ nào (ví dụ, >= 5.2.1 <6).\n* Nếu một sự phụ thuộc được nâng cấp lên một phiên bản chính gần đây hơn, TEA có thể yêu cầu phiên bản chính của gói phải tăng lên.\n* Tương tự, nếu một phụ thuộc được nâng cấp lên một phiên bản nhỏ gần đây hơn, TEA có thể yêu cầu phiên bản nhỏ của gói được tăng lên.\n* Nếu một phụ thuộc mới được thêm vào, TEA có thể yêu cầu tăng phiên bản nhỏ của gói.\n\nXem xét nỗ lực không cần thiết áp đặt cho bất kỳ người dùng gói nào khi các quy tắc trên bị vi phạm, chúng tôi đề xuất rằng một phần của mã thông báo Tea bị cắt giảm bởi người bảo trì gói bị cắt để phản ánh sự thiếu siêng năng của họ. \nNếu một nhà phát triển buộc mọi người phải tung hứng cúp của họ, ai đó sẽ bỏ một ít Tea. Vì việc quét phụ thuộc dự kiến sẽ xảy ra khi nộp, chúng ta nên lưu ý rằng không có việc giảm giá từ những người ủng hộ và tài trợ gói hoặc người nếm Tea sẽ xảy ra.\n\n## Gói và gói danh tiếng của người đóng gói\n\nNgười duy trì gói phải đóng góp vào danh tiếng và sự đáng tin cậy của họ bằng cách giảm token Tea. \nTuy nhiên, một hệ thống danh tiếng chỉ dựa vào sự đóng góp kinh tế của tác giả không cung cấp đủ bảo vệ người dùng và có thể phải chịu các cuộc tấn công của Sybil, trong đó một cá nhân duy nhất tạo ra nhiều đại diện của chính họ để để lại một khối lượng lớn các đánh giá tích cực về công việc của họ, lừa người dùng tin rằng công việc của họ đã được nhiều người xem xét và phê duyệt.\n\nMột số phương pháp có sẵn để ngăn chặn các cuộc tấn công Sybil, một số trong đó được mô tả bởi Nitish Balachandran và Sugata Sanyal trong “một đánh giá về các kỹ thuật để giảm thiểu các cuộc tấn công của Sybil”[^18]. \nVì Tea là một giao thức phi tập trung, sử dụng hệ thống chứng nhận ủy thác dựa trên cơ quan cấp giấy chứng nhận tập trung sẽ trái với cốt lõi của nó. \nChúng tôi đề xuất tập trung vào các phương pháp phi tập trung để giảm thiểu tấn công SYBIL và cụ thể hơn là các phương pháp dựa vào một nhóm lớn những người tham gia mạng được khuyến khích đánh giá và đại diện công khai danh tiếng của từng gói và người bảo trì.\n\nTương tự như việc sản xuất các khối trên blockchain bằng chứng, trong đó các nút không sản xuất có thể xác nhận công việc của người khác và khi cần thiết, làm nổi bật sự vi phạm các quy tắc của mạng, dẫn đến việc phạt thông qua việc loại bỏ (phá hủy một phần cổ phần của họ), \nchúng tôi đề xuất một hệ thống theo đó các bên thứ ba (aka người thử nghiệm Tea) sẽ có thể xem xét các gói được sản xuất bởi người bảo trì gói và được khuyến khích kinh tế để hành xử vì lợi ích tốt nhất của nguồn mở của nguồn mở Cộng đồng phần mềm và người dùng cũng như nhận ra hành vi tốt và phạt hành vi xấu. \nHệ thống này phải có cả khả năng kháng Sybil và ngăn chặn các giá đỡ mã thông báo lớn ảnh hưởng đến giao thức hoặc danh tiếng của các gói cụ thể. \nChúng tôi tin rằng cách tiếp cận này phù hợp hơn với nguồn mở, cung cấp chất nền màu mỡ hơn để thúc đẩy việc áp dụng và tin tưởng, và cuối cùng tạo điều kiện cho sự phát triển của Tea.\n\n[^18]: Nguồn: @arxiv\n\n## Đánh giá gói của các bên thứ ba\n\nViệc xem xét các gói của các bên thứ ba là một thành phần thiết yếu của việc xây dựng danh tiếng, tuy nhiên, đánh giá của bên thứ ba có các mối đe dọa độc đáo của riêng mình bao gồm các cuộc tấn công SYBIL đã nói ở trên.\n\nCông nghệ blockchain, và đặt cược rõ ràng hơn, cung cấp một cơ hội duy nhất cho Tea để giải quyết thách thức này. \nMặc dù địa chỉ ví có thể có sẵn với số lượng vô hạn, nhưng đây không phải là trường hợp với mã thông báo Tea, có nguồn cung ban đầu dự kiến là 10 tỷ. \nNgoài ra, mỗi hành động được thực hiện bởi các nhà phát triển, chẳng hạn như gửi các gói, xác minh các gói hoặc dốc chúng, sẽ đóng góp cho danh tiếng của họ, do đó tạo ra một hồ sơ duy nhất mà mỗi nhà phát triển có thể sử dụng để cả đóng góp cho cộng đồng Tea và tham gia quản trị Tea.\n\nBằng cách yêu cầu các nhà đánh giá của bên thứ ba phải tăng mã thông báo Tea và chịu nguy cơ mất một phần mã thông báo dốc của họ nếu họ hành xử chống lại sự quan tâm của mạng hoặc là một diễn viên xấu, các bên thứ ba có thể cung cấp thêm sự tin cậy cho gói và Nhận một phần thưởng, dưới dạng mã thông báo Tea.\n\nChúng tôi cũng đề xuất mở rộng hệ thống danh tiếng cho các bên thứ ba thực hiện xác minh độc lập các gói - Những người thử nghiệm Tea. \nViệc hoàn thành đánh giá tích cực sẽ yêu cầu hai hoạt động xảy ra gồm:\n\n* Việc gửi đánh giá mã, được ký bởi người bán Tea và có thể truy cập công khai cho tất cả các thành viên của cộng đồng, cùng với đó\n* Hành động dốc “cho” các gói (so với gói “đối lập”), để chứng minh đánh giá của họ.\n\n\nViệc hoàn thành một đánh giá tiêu cực bao gồm một hoặc nhiều lỗ hổng quan trọng sẽ yêu cầu các máy chứa Tea trước tiên liên hệ với người bảo trì gói bằng giao thức nhắn tin để thông báo cho họ về lỗ hổng và cho phép họ giải quyết vấn đề một cách kịp thời. \nKhi hết thời hạn được phân bổ cho người bảo trì gói để giải quyết lỗ hổng của họ hoặc khi gói được sửa chữa, cùng một giao thức nhắn tin sẽ được sử dụng để thông báo cho tất cả người dùng và người thử nghiệm gói này (bao gồm cả người phụ thuộc) rằng lỗ hổng đã được được xác định và hy vọng được giải quyết, vì vậy họ biết để cập nhật ứng dụng hoặc phụ thuộc của họ. \nĐể không tôn trọng sự lãng phí của các nhà phát triển Thời gian, giao tiếp giữa các người thử Tea và người bảo trì gói sẽ yêu cầu các thử Tea để tăng mã thông báo Tea.\n\nSau khi hoàn thành cả hai hoạt động, Tasters Tea sẽ nhận được NFT làm bằng chứng về công việc của họ trên gói cụ thể và phiên bản gói. \nSự tích lũy của các NFT kết hợp với tỷ lệ của mỗi gói được xem xét và thông tin được trích xuất từ các hệ thống bên ngoài sẽ thông báo cho danh tiếng của Taster Taster. \nKhi danh tiếng của họ đạt đến các cột mốc quan trọng, những người thử nghiệm Tea có thể kiếm được quyền truy cập vào các phần nâng cao của giao thức hoặc phần thưởng tăng tốc, theo quyết định của quản trị Tea.\n\n## Các gói lỗi thời hoặc hư hỏng\n\nNhiệm vụ của Tea là thưởng cho những người đóng góp và người tham gia vào các cộng đồng nguồn mở; Tuy nhiên, phần thưởng phải tương xứng với những nỗ lực được triển khai bởi người bảo trì gói và thử nghiệm Tea. \nCác gói được duy trì, lỗi thời hoặc bị hỏng là dấu hiệu rõ ràng của những người bảo trì gói không sống theo mong đợi của cộng đồng hoặc không mang lại sự tin tưởng và hỗ trợ ấn tượng với họ thông qua việc nhúng các gói. \nMột biểu hiện khác của các gói lỗi thời có thể là việc tiếp tục sử dụng ngôn ngữ kế thừa hoặc phiên bản di sản của các ngôn ngữ đa phiên bản. Các gói còn lại lỗi thời hoặc tham nhũng trong quá dài cho thấy những người thử nghiệm Tea cần xem xét các gói bảo trì của gói làm việc thường xuyên và nhất quán.\n\nNhững người thử nghiệm Tea là thành viên quan trọng của các cộng đồng nguồn mở trong đó đánh giá và khiếu nại liên quan của họ có thể hướng người dùng gói hướng tới hoặc tránh xa các gói. \nĐể đảm bảo rằng các đánh giá có thể được tin cậy trên cơ sở liên tục, chúng tôi đề xuất một cơ chế theo đó các gói lỗi thời hoặc bị hỏng có thể thấy một phần của các token dốc của họ được gửi đến các người thử nghiệm Tea trước tiên để nhận ra việc thiếu bảo trì bất kỳ gói nào.\n\nBất kỳ đánh giá tiêu cực nào phác thảo một lỗ hổng như lỗ hổng không ngày hoặc sử dụng sự phụ thuộc lỗi thời và vẫn mở qua thời kỳ ân sủng được xác định bởi quản trị nên được coi là thất bại của người bảo trì gói.\nHọ đã không hoàn thành nhiệm vụ mà họ được giao phó và thưởng cho. \nĐiều tương tự cũng có thể nói đối với những người ủng hộ và tài trợ gói hàng đã đặt ra danh tiếng của họ về công việc của những người bảo trì gói quá hạn và nhận được phần thưởng cho nó, nhưng không xác định được việc thiếu bảo trì hoặc được bầu để tiếp tục hỗ trợ gói bất kể.\n\nKhi các gói trở nên phổ biến và sử dụng, với nhiều ứng dụng và hệ thống quan trọng có khả năng phụ thuộc vào chúng, chúng tôi phải khuyến khích các nhà phát triển báo cáo lại các lỗ hổng cho người bảo trì gói và bảo trì gói để giải quyết các lỗ hổng đó trước khi chúng có thể bị khai thác. \nDo đó, chúng tôi đề xuất rằng bất kỳ gói lỗi thời hoặc bị hỏng nào phải tuân theo một hoặc nhiều đánh giá tiêu cực được chứng minh và vẫn ở trạng thái đó trong thời kỳ ân sủng do quản trị xác định Những người ủng hộ, và các nhà tài trợ hoặc người thử nghiệm Tea trước đó), trong khi một phần khác được gửi đến Tasters Tea đã gửi các đánh giá tiêu cực. \nPhân phối cho tất cả các nhà thử nghiệm Tea có thể dựa trên tuổi của đánh giá của họ và số lượng mã thông báo Tead mà họ đã đưa ra để xem xét.\n\n## Người duy trì NFT\n\nSau khi gửi thành công một gói, người bảo trì gói sẽ nhận được NFT để chứng minh công việc và đóng góp của họ. \nChủ sở hữu của NFT này sẽ tự động nhận tất cả các phần thưởng được liên kết với gói. \nNgười bảo trì gói có thể chuyển quyền sở hữu bảo trì qua một gói cho người bảo trì gói khác bằng cách chuyển gói NFT gói. Chuyển thành công NFT sẽ dẫn đến chủ sở hữu mới tự động nhận phần thưởng gói trong tương lai.\n\nMột phần quan trọng của việc xây dựng danh tiếng phụ thuộc vào tần suất và số lượng bài nộp gói chất lượng. \nNFT được giao cho các nhà bảo trì gói làm bằng chứng về công việc của họ có thể được sử dụng bởi hệ thống danh tiếng để cập nhật danh tiếng của người bảo trì gói và cho phép họ truy cập vào các phần nâng cao của giao thức, theo quyết định của quản trị Tea. \nTuy nhiên, để ngăn chặn các vectơ tấn công, chẳng hạn như các thành viên cộng đồng mua danh tiếng của họ, việc chuyển giao NFT bảo trì sẽ không dẫn đến việc chuyển giao danh tiếng. Danh tiếng phải duy trì liên kết trực tiếp với một công việc của nhà phát triển cụ thể và không được chuyển nhượng.\n\n# Mã thông bá Tea\n\n## Bảo hiểm mạng lưới\n\nMặc dù nhiều blockchain có thể xuất hiện dưới dạng các giải pháp cơ sở hạ tầng hiệu quả và an toàn để hỗ trợ các mục tiêu của Tea, nhưng chúng tôi tin rằng phải xem xét cẩn thận cho ngăn xếp công nghệ mà hệ thống Tea được xây dựng.\n\nKhả năng mở rộng, hiệu quả chi phí, ESG và khả năng mở rộng của bên thứ ba là những cân nhắc thiết kế quan trọng mà một hệ thống chứng minh cổ phần có chủ quyền của Tea có thể phục vụ tốt hơn. \nĐể có bằng chứng, các nhà khai thác nút và những người tham gia mạng đã đóng góp giá trị kinh tế dưới dạng mã thông báo gốc chuỗi để tăng bảo mật hệ thống. \nCác nhà khai thác nút và người tham gia mạng nhận được phần thưởng cho việc sản xuất thành công các khối tuân thủ các quy tắc của mạng và bao gồm thông tin giao dịch chính xác. \nKhông hoạt động (AKA Node Down) hoặc hoạt động độc hại/không chính xác bị phạt bằng cách phá hủy một phần của các mã thông báo đặt cược thông qua việc loại bỏ.\n\nMột hệ thống PoS cung cấp bởi mã thông báo Tea sẽ cho phép những người giữ mã thông báo Tea đóng góp vào hệ thống bảo mật bằng cách đặt *staking* Tea và hỗ trợ các nhà phát triển nguồn mở bằng cách *nhúng* Tea. \nChúng tôi nhận thức đầy đủ các yếu tố kinh tế có thể ngăn chặn một số nhà phát triển stake hoặc nhúng Tea; Như vậy, việc đặt cược và dốc sẽ có sẵn ít như một chiếc lá, mệnh giá nhỏ nhất của Tea đại diện cho một trăm triệu ($10^{-8}$) của một loại Tea.\n\nCả hai ứng dụng của mã thông báo Tea đều phục vụ các chức năng quan trọng trong sự hỗ trợ và tăng trưởng của hệ sinh thái nguồn mở. \nTea Staking sẽ đảm bảo rằng hệ thống Tea tiếp tục hoạt động an toàn, vì vậy tất cả những người tham gia mạng có thể gửi và truy cập các gói để xem xét chúng, tích hợp chúng vào ứng dụng của họ, v.v. \nNhững người tham gia mạng để hỗ trợ và sử dụng các gói đáp ứng các yêu cầu về chất lượng và độ tin cậy, như được xây dựng bởi cộng đồng Tea thông qua sự hỗ trợ và bất đồng của mỗi gói. \nSẽ được thực hiện khi xác định và thực hiện các tham số cổ phần và độ dốc để người ta không trở thành ký sinh ở bên kia.\n\n## Khuyến khích và Hình phạt\n\nNhư đã thảo luận trước đó, có thể có những khuyến khích mạnh mẽ cho những kẻ xấu thỏa hiệp phần mềm nguồn mở. \nPhần lớn cơ sở hạ tầng quan trọng của Internet đang chạy trên nguồn mở và cuộc đua tìm kiếm các lỗ hổng khai thác cũng như các lỗ hổng khác đang diễn ra. \nTại Tea, chúng tôi tin rằng những người duy trì gói không phải là những người đáng bị đổ lỗi (mặc dù họ thường như vậy).\n\nCác khuyến khích giao thức Tea khắc phục điều này thông qua phân phối khuyến khích công bằng và hợp lý. \nMột gói như Lodash với hơn 151 nghìn người phụ thuộc là trụ cột của sự phát triển nguồn mở và người bảo trì của nó xứng đáng được khen thưởng tương xứng. \nTuy nhiên, một hệ thống phần thưởng được xây dựng chỉ dựa trên số lượng người phụ thuộc sẽ ngăn cản các nhà đổi mới phá vỡ các thế độc quyền này trừ khi họ được các bên thứ ba cấp vốn đầy đủ hoặc đã tích lũy đủ nguồn lực để tự tài trợ. \nCách tiếp cận này có thể dẫn đến số lượng người đóng góp bị thu hẹp lại, dẫn đến kết quả ngược lại với ý nghĩa của Tea.\n\nMục tiêu của tea là đại diện cho giá trị của phần mềm mã nguồn mở và, khi làm như vậy, thúc đẩy sự phát triển của nó bằng cách trao quyền cho những người tham gia bằng các tài nguyên họ cần để theo đuổi niềm đam mê của mình mà không bị cản trở. \nHệ thống phân phối ưu đãi Tea cần xem xét cẩn thận tỷ lệ dốc của từng gói và điều chỉnh ưu đãi của từng gói cho phù hợp. \nĐể giảm rủi ro của một số lượng nhỏ các gói được sử dụng làm phụ thuộc trên nhiều ứng dụng thu phần lớn phần thưởng dốc, chúng tôi sẽ tận dụng nghiên cứu do nhà sáng lập[^19] web3 sản xuất cho cơ chế phần thưởng dựa trên bằng chứng cổ phần của Polkadot. \nChúng tôi có thể điều chỉnh thêm việc triển khai và các biến của nó dựa trên kết quả của các thử nghiệm thực tế.\n\nKhi một gói steep tiếp cận tỷ lệ dốc tối ưu do quản trị xác định, tỷ lệ phần thưởng dốc của nó sẽ giảm dần. \nKhi một gói vượt quá tỷ lệ dốc tối ưu của nó, tỷ lệ phần thưởng dốc sẽ giảm mạnh để không khuyến khích những người ủng hộ gói và những người thưởng thức tea từ các gói có độ dốc cao hơn nữa. \nThiết kế này có thể cho phép các gói ít dốc hơn trở nên hấp dẫn hơn đối với cả những người ủng hộ gói và những người thưởng thức tea. \nNó cũng có thể khuyến khích các nhà phát triển có kinh nghiệm xây dựng các giải pháp thay thế cho các gói có độ dốc cao, tạo cơ hội cho cộng đồng tea cân bằng giữa việc hỗ trợ phần mềm hiện có và thúc đẩy đổi mới. \nTỷ lệ dốc sẽ được tính toán bằng cách sử dụng nguồn cung cấp tuần hoàn trong thiết kế ban đầu của nó. \nCộng đồng tea có thể thay đổi thiết kế này để cải thiện khả năng mở rộng của hệ thống hơn nữa. \nHãy để $\\chi$ là tỷ lệ dốc trên tất cả các gói. \nNó đại diện cho tổng số mã thông báo tea được người bảo trì gói, người dùng gói, người ủng hộ gói và nhà tài trợ cũng như người nếm tea chia cho tổng nguồn cung cấp mã thông báo tea. \nDựa vào số lượng gói nguồn mở hiện có và mức tăng trưởng dự kiến của chúng,$\\chi$ sẽ luôn là một giá trị rất nhỏ giữa $0$ và $1$.\n\nĐặt $\\psi$ là tỷ lệ staking. \nNó đại diện cho tổng số mã thông báo Tea được đặt bởi bất kỳ người tham gia mạng nào để bảo mật mạng.\n\nĐặt $\\chi_{ideal}$ là tỷ lệ dốc mà chúng tôi muốn mỗi gói đạt được để phân phối phần thưởng công bằng trên tất cả các gói và phần phụ thuộc của chúng. \nGiá trị của $\\chi_{ideal}$ phải được cập nhật khi các gói mới được thêm vào sổ đăng ký phi tập trung và các phần phụ thuộc được tạo. \nĐể xác định giá trị tốt nhất cho $\\chi_{ideal}$, chúng tôi sẽ sử dụng đường cong hình chuông phổ biến được cập nhật khi bắt đầu mỗi chu kỳ phần thưởng.\n\nHãy để  $\\tau = \\tau(\\chi)$ lãi suất dốc hàng năm được phân phối cho tất cả các thành viên cộng đồng Tea, những người dốc mã thông báo Tea để hỗ trợ các nhà phát triển nguồn mở. \nNói cách khác, $\\tau(\\chi)$ tương ứng với phần thưởng dốc nhận được trong hơn một năm bởi một thành viên cộng đồng đã dốc mã thông báo Tea trong cả năm.\n\nĐặt $\\gamma = \\gamma(\\psi)$ là lãi suất đặt cược hàng năm được phân phối cho tất cả các nhà khai thác nút và những người tham gia mạng, những người đặt cược mã thông báo Tea để bảo mật mạng. \nNói cách khác, $\\gamma(\\psi)$ tương ứng với phần thưởng đặt cược nhận được trong hơn một năm bởi một thành viên cộng đồng đặt cược mã thông báo Tea trong cả năm.\n\nĐặt $\\delta$ là lạm phát hàng năm hướng vào kho bạc mạng lưới. \n$\\delta$ có thể thay đổi do các yếu tố bên ngoài ảnh hưởng đến việc cung cấp mã thông báo.\n\nChúng tôi coi tỷ lệ phần thưởng dốc hàng năm là một hàm của $\\chi$ và tỷ lệ phần thưởng đặt cược hàng năm là một hàm của $\\psi$.\n\n* $\\tau(\\chi)$ tương ứng với việc khuyến khích mọi người dốc một gói. Khi $\\chi$ tăng lên, cần ít phần thưởng $\\tau(\\chi)$ hơn.\n* $\\gamma(\\psi)$ tương ứng với động cơ khuyến khích mọi người đặt cược vào mạng. Khi $\\psi$ tăng lên, cần ít phần thưởng $\\gamma(\\psi)$ hơn để bảo mật mạng.\nLạm phát hàng năm $I$ sẽ tương đương $(\\tau + \\gamma + \\delta)$ và được tính như sau:\n\n$$\nI = \\frac{\\textrm{tổng cung của token cuối năm} - \\textrm{tổng cung của token đầu năm}}{\\textrm{tổng cung của token đầu năm}} = (\\tau + \\gamma + \\delta)\n$$\n\nĐóng góp vào lạm phát của $\\tau_{\\textsc{all}}$ (khuyến khích được phân phối cho tất cả các gói dốc) và $\\gamma_{\\textsc{all}}$ (khuyến khích được phân phối cho tất cả những người đóng góp cho an ninh mạng) phải được cân nhắc để đảm bảo rằng hệ thống khuyến khích tỷ lệ đặt cược/đặt cược tối ưu.\n\nKhi chúng tôi tập trung vào các ưu đãi được phân phối trên tất cả các gói dốc, chúng tôi xác định rằng\n$\\tau_{\\textsc{all}}$\nlà một hàm của tỷ lệ dốc $\\chi$ và do đó\n$\\tau_{\\textsc{all}}(\\chi) = \\chi \\cdot \\tau(\\chi)$.\nTừ phân tích trước đây của chúng tôi, chúng ta có thể thấy rằng\n$\\tau_{\\textsc{all}}(\\chi_{ideal}) = \\chi_{ideal} \\cdot \\tau_{ideal}$.\nVì mục tiêu là đạt đến một trạng thái mà\n$\\chi = \\chi_{ideal}$\n, phần thưởng\n$\\tau_{ideal}(\\chi)$\nCó thể đạt cực đại tại giá trị đó.\n\nĐặt $\\tau_{ideal} = \\tau(\\chi_{ideal})$\nlà tỷ lệ phần thưởng do mạng phân phối ở kịch bản lý tưởng trong đó\n$\\chi = \\chi_{ideal}$.\n\nĐặt $\\tau_{0}$ là giới hạn của $\\tau_{\\textsc{all}}(\\chi)$ vì $\\chi$ tiến tới 0 khi không có thành viên nào trong cộng đồng Tea dốc bất kỳ gói nào.\nGiá trị của $\\tau_{0}$ phải gần bằng 0 nhưng không bằng 0 để khuyến khích những người dùng sớm.\nTheo đề xuất từ nghiên cứu của nhà sáng lập web3, chúng tôi đề xuất rằng:\n\n* hàm lạm phát tăng tuyến tính giữa $\\chi = 0$ và $\\chi = \\chi_{ideal}$, và\n* nó phân rã theo cấp số nhân giữa $\\chi = \\chi_{ideal}$ và $\\chi = 1$.\n\nChúng tôi đã chọn mức giảm theo cấp số nhân tương tự cho $\\tau_{\\textsc{all}}(\\chi)$ vì nó hàm ý mức giảm theo cấp số nhân của $\\tau(\\chi)$ và chúng tôi muốn phần thưởng giảm mạnh hơn $\\chi_{ideal}$ để ngăn một gói duy nhất nhận được tất cả phần thưởng.\n\nSự phân rã được xác định sao cho tỷ lệ lạm phát giảm nhiều nhất là 50% khi $\\chi$ dịch chuyển $d$ đơn vị sang bên phải của $\\chi_{ideal}$ – tức là\n$\\tau_{\\textsc{all}}(\\chi_{ideal} + d) \\geq \\tau_{\\textsc{all}} \\cdot 0,5$.\n\n\nChúng tôi đề xuất các hàm tỷ lệ lãi suất và tỷ lệ lạm phát sau, các hàm này phụ thuộc vào các tham số $\\chi_{ideal}$, $\\tau_{ideal}$, $\\tau_{0}$ và $d$.\n\n\\begin{align*}\n&\\tau_{\\textsc{all}}(\\chi) = \\tau_{0} + (\\tau_{\\textsc{all}}(\\chi_{ideal}) - \\tau_{0})\\frac{\\chi}{\\chi_{ideal}}\\enspace\\textrm{for}\\;0 < \\chi \\leq \\chi_{ideal} \\\\\n&\\tau_{\\textsc{all}}(\\chi) = \\tau_{0} + (\\tau_{\\textsc{all}}(\\chi_{ideal}) - \\tau_{0}) \\cdot 2^{(\\chi_{ideal}-\\chi)/d}\\enspace\\textrm{for}\\;\\chi_{ideal} < \\chi \\leq 1\n\\end{align*}\n\nCũng như những diễn viên giỏi cần được khen thưởng; các tác nhân xấu cần phải được xác định và trừng phạt. \nPhần mềm nguồn mở cung cấp nhiều cơ hội cho những kẻ xấu tạo ra các điểm yếu và rủi ro về uy tín cho toàn bộ cộng đồng các nhà phát triển. \nTừ việc chiếm đoạt công việc đến thay đổi và phân phối lại các gói phần mềm, hoặc tiêm mã bất chính, cuộc chiến giữa những kẻ tốt và kẻ xấu vẫn tiếp diễn, thường là với những kẻ xấu được tài trợ tốt, những người coi việc làm ô nhiễm các gói nguồn mở là một cơ hội để hưởng lợi về mặt tài chính. \nNhược điểm là tương đối nhỏ, với các gói có khả năng bị cấm trên kệ kỹ thuật số hoặc bị mang tiếng xấu.\n\nChúng tôi đề xuất giới thiệu một cơ chế cắt giảm để thiết lập một nhược điểm quan trọng hơn ảnh hưởng trực tiếp đến giá trị kinh tế của các tác nhân xấu. \nKhi những người thử nghiệm Tea đánh giá và phân tích mã trong các gói mới được gửi, chúng tôi khuyên những người thử nghiệm Tea nhận được các công cụ và khuyến khích để xác định và làm nổi bật mã bất chính để người dùng gói có thể nhận thức được các rủi ro và những người duy trì gói, người hỗ trợ gói và nhà tài trợ sẽ bị phạt để gửi hoặc hỗ trợ mã bất chính. \nTrong phạm vi đó, đối với tất cả các đánh giá tiêu cực đã được chứng minh được thực hiện theo quy tắc mạng và đã được người duy trì gói giải quyết trong khoảng thời gian do quản trị xác định, người duy trì gói sẽ không phải chịu bất kỳ hình phạt nào trái với những người ủng hộ và tài trợ gói hoặc người thử nghiệm Tea đã cung cấp một đánh giá tích cực về gói trong câu hỏi. \nĐối với các đánh giá tiêu cực được thực hiện theo quy tắc mạng và người duy trì gói không giải quyết trong khoảng thời gian do quản trị xác định, một phần mã thông báo do người duy trì gói, người ủng hộ và tài trợ gói cũng như người thử nghiệm Tea trước đó nhận được sẽ bị cắt giảm. Một phần khác sẽ được khóa vào một nhóm bảo hiểm do ban quản lý Tea kiểm soát. \nBan quản lý tea sẽ thiết lập các chính sách và quy tắc phối hợp chặt chẽ với cộng đồng để phân phối nội dung của nhóm cho những người bị ảnh hưởng bởi các lỗ hổng. \nGiao thức sẽ phân phối một phần ba số mã thông báo đã giảm giá cho tất cả những người thử nghiệm Tea đã góp phần vào đánh giá tiêu cực và giảm giá đối với gói, dựa trên số lượng mã thông báo Tea mà họ đã giảm giá “chống lại” gói và khoảng thời gian mã thông báo của họ đã giảm giá. \nNói cách khác, một hoặc nhiều người thử nghiệm Tea xác định và báo cáo lỗ hổng theo các quy tắc của mạng càng sớm thì phần thưởng họ nhận được càng cao vì đã hỗ trợ phát triển mã nguồn mở an toàn và hiệu quả.\n\nĐể ngăn các thành viên cộng đồng bỏ phiếu ngẫu nhiên “chống lại” các gói có giá trị cao với hy vọng nhận được phần lớn hình phạt, tất cả các mã thông báo Tea được “chống lại” sẽ không được thưởng theo lạm phát và có thể phải tuân theo cơ chế phân rã, do đó làm giảm giá trị của chúng theo thời gian.\n\n[^19]: Nguồn: @web3\n\n\n# Quản trị\n\nQuản trị là rất quan trọng đối với sự phát triển, tính bền vững và việc áp dụng bất kỳ hệ thống phân tán nào.\n\nChúng tôi đề xuất rằng Tea bao gồm quản trị trên chuỗi nơi tất cả những người nắm giữ mã thông báo chè có thể đề xuất và bỏ phiếu về các thay đổi đối với các thông số quan trọng được đánh giá bằng quyền sở hữu mã thông báo và danh tiếng. \nCác thông số này có thể bao gồm lạm phát, phí giao dịch, phần thưởng đặt cược, phần thưởng dốc hoặc tỷ lệ dốc tối ưu. \nChức năng này sẽ đảm bảo rằng các thông số quan trọng có thể phát triển và được tối ưu hóa theo thời gian bởi các thành viên của cộng đồng Tea. \nChúng tôi dự đoán quản trị sẽ ra mắt với một cấu trúc đơn giản và dần dần mở rộng khi hệ thống Tea trưởng thành, tạo điều kiện thuận lợi cho việc áp dụng và đảm bảo phân cấp dần dần.\n\nMột số tham số hệ thống có thể không chịu sự quản trị hoặc hỗ trợ thay đổi tần suất cao để giảm bề mặt tấn công do quản trị thể hiện. \nQuá trình chuyển đổi dần dần các tham số sang quản trị mở, phi tập trung sẽ đảm bảo tính ổn định và khả năng dự đoán của hệ thống.\n\n# Khả năng mở rộng của bên thứ ba\n\nKhi chúng tôi xây dựng các công cụ ban đầu để thu hút sự hỗ trợ lâu dài của các cộng đồng nguồn mở, chúng tôi tin rằng một phần nhiệm vụ của chúng tôi là đảm bảo rằng các bên thứ ba có thể mở rộng bộ công cụ tổng thể. \nNgoài việc cung cấp cơ sở hạ tầng cho các nhà phát triển để xây dựng các tiện ích mở rộng cho giao thức, bao gồm các cách mới để đổi mới và hỗ trợ thêm cho các nhà phát triển nguồn mở, các kế hoạch của chúng tôi bao gồm tiềm năng cho các nhà quản lý gói khác đóng góp cho giao thức. \nƯớc mơ và nỗ lực của các nhà phát triển nguồn mở đã tạo nên sự đổi mới hỗ trợ cuộc sống hàng ngày của chúng ta. \nChúng tôi mong muốn được khám phá những cách sử dụng và mở rộng mới cho Tea do cộng đồng Tea đề xuất.\n\n\n# Công việc trong tương lai và những nỗ lực cộng đồng tiềm năng\n\nKhi hệ thống Tea trưởng thành, chúng tôi dự đoán cộng đồng sẽ quyết định và góp phần thay đổi và mở rộng hệ thống Tea thông qua quản trị. \nDưới đây là một số ý tưởng mà chúng tôi tin rằng có thể truyền cảm hứng cho một số người.\n\n## Người buôn bán Tea\n\nCác cộng đồng phần mềm nguồn mở rất sôi động và không ngừng tìm cách đổi mới và mang lại giá trị. \nSự cống hiến và lòng vị tha này dẫn đến việc liên tục xây dựng các phần mềm và gói mới, mỗi phần mềm đều kéo theo sự phụ thuộc. \nDo đó, chúng tôi dự đoán bản đồ phụ thuộc sẽ phát triển liên tục, dẫn đến những thay đổi thường xuyên đối với tỷ lệ dốc và phần thưởng. \nTrong tương lai, cộng đồng Tea có thể đề xuất phát triển một hệ thống được thiết kế để theo dõi linh hoạt tỷ lệ dốc cho từng gói và cân bằng lại cách những người ủng hộ gói dốc mã thông báo của họ dựa trên tiêu chí của riêng họ.\n\n## Bản quyền chuyển nhượng trọn gói\n\nChúng tôi nhận thấy rằng những người duy trì gói có thể quyết định chuyển luồng phần thưởng tăng vọt của họ cho một hoặc nhiều nhà phát triển. \nViệc quản lý việc chuyển giao như vậy phải là quyết định của người duy trì gói và các đối tác của họ, không có sự can thiệp từ Tea. \nCác công cụ sẽ cần được cung cấp để chuyển toàn bộ hoặc một phần như vậy (có lẽ thông qua chỉ một phần phần thưởng tăng dần được chuyển hướng đến một hoặc nhiều nhà phát triển, trong khi phần thưởng còn lại tiếp tục chuyển đến người duy trì gói ban đầu) \nvà cho phần thưởng tăng dần để chuyển qua một tài khoản được kiểm soát bởi một người tham gia mạng, nhiều người tham gia mạng hoặc được phân phối tự động trên nhiều tài khoản bằng cách sử dụng tỷ lệ tĩnh hoặc động.\n\n## Phân phối phần thưởng cho những người bảo trì\n\nViệc duy trì một gói có thể dựa vào công việc của một nhóm các nhà phát triển khác. \nTrước khi phần thưởng tăng đột biến bắt đầu chảy, các nhóm nên cân nhắc tự động hóa việc phân phối phần thưởng tăng đột biến giữa các nhóm với nhau. \nViệc phân phối xảy ra như thế nào phải do chính những người bảo trì quyết định, vì họ ở vị trí tốt nhất để đánh giá ai đã đóng góp và họ nên được khen thưởng như thế nào.\n\nĐể thực hiện điều đó, mỗi nhóm (hoặc các nhóm) có thể thành lập tổ chức tự trị phi tập trung (DAO) của riêng họ và tự động phân phối phần thưởng hoặc triển khai các hệ thống phức tạp hơn để xác định phân phối phần thưởng phù hợp dựa trên các yếu tố bên ngoài, chẳng hạn như phiếu bầu từ tất cả các DAO thành viên, \nhoặc phân phối theo thời gian dựa trên đóng góp liên tục, hoàn thành thành công tiền thưởng, v.v.\n\n## Xử lý gói “phân nhánh phần mềm”\n\nChúng tôi tin rằng các nhánh là cần thiết và phần lớn không được sử dụng đúng mức. \nCác nhánh có thể là một công cụ hiệu quả để phát triển các gói cạnh tranh về chức năng, hiệu suất, bảo mật và thậm chí cả sự chú ý. \nHữu ích nhất có thể, các nhánh phải công nhận những nỗ lực ban đầu. Thông qua công việc trong tương lai hoặc những đóng góp tiềm năng, cộng đồng Tea có thể nâng cao hệ thống để yêu cầu các nhánh được khai báo, thậm chí có thể được phát hiện khi một gói được gửi. \nNhững phân nhánh phần mềm không được khai báo do những người thử nghiệm Tea tiết lộ có thể dẫn đến việc một phần mã thông báo đã ngâm bị cắt giảm, được chuyển cho người bảo trì gói ban đầu và được gửi đến những người thử nghiệm Tea đã tiết lộ phân nhánh phần mềm.\n\n## Thời gian chạy so với Phụ thuộc bản dựng\n\nTea có thể không phân biệt được phần phụ thuộc bản dựng với phần phụ thuộc thời gian chạy khi phân phối phần thưởng dốc khi khởi chạy. \nTuy nhiên, với điều kiện cộng đồng Tea cảm thấy mạnh mẽ về việc tạo ra sự khác biệt như vậy, cộng đồng Tea có thể đề xuất các cải tiến đối với thuật toán phân phối phần thưởng tăng dần để tính đến mức độ quan trọng của từng phụ thuộc và đóng góp của chúng vào giá trị của các gói phụ thuộc vào chúng. \nNhững đề xuất này sẽ được bỏ phiếu và thực hiện dựa trên quyết định của cộng đồng.\n\n## Thù lao dựa trên việc sử dụng\n\nKhi nhiều ứng dụng được xây dựng bằng cách sử dụng các gói đã đăng ký với Tea, cộng đồng có thể tăng cường thuật toán phần thưởng để việc phân bổ có thể bị ảnh hưởng bởi các bộ dữ liệu được chứng thực bên ngoài, chẳng hạn như mức sử dụng. \nBản cập nhật này đối với cơ chế phần thưởng có thể cho phép phân bổ phần thưởng mã thông báo Tea cao hơn cho các gói có mức sử dụng cao nhất trong khi vẫn tôn trọng các ràng buộc của tỷ lệ dốc được mô tả trong phần mã thông báo Tea. \nNhững người bảo trì gói có thể sử dụng một cách tiếp cận tương tự để phân phối phần thưởng dốc trên các phần phụ thuộc của họ dựa trên logic minh bạch mà họ lựa chọn. \nLưu ý rằng tất cả thông tin được sử dụng để ảnh hưởng đến việc phân phối phần thưởng trên các gói và phần phụ thuộc trong hệ thống Tea sẽ cần phải đáng tin cậy.\n\n\n# Lời kết\n\nSách trắng này sẽ không tồn tại nếu không có sự hỗ trợ và cống hiến của nhiều người yêu Tea. \nCác tác giả Josh Kruger, Jadid Khan và Jacob Heider vì những đóng góp của họ cho hệ thống mã thông báo và nhiều cá nhân kín đáo đã tình nguyện dành thời gian để cung cấp phản hồi về nội dung của tài liệu này.\n\n$\\parskip=0pt plus 1pt$\n\n# Bảng thuật ngữ\n\n| Tựa đề | Định nghĩa |\n|------|------------|\n| Leaf | Mệnh giá nhỏ nhất của mã thông báo Tea. Một chiếc lá tương ứng với một phần trăm triệu ($10^{-8}$) của một loại Tea. |\n| Slashing | Hành động trừng phạt những người đặt cược hoặc người đặt cược để đáp lại hành vi trái với các quy tắc của mạng. |\n| Staking | Hành động khóa mã thông báo Tea để bảo mật mạng bằng chứng cổ phần mà hệ thống Tea được xây dựng. |\n| Steeping | Hành động khóa mã thông báo Tea để hỗ trợ yêu cầu của bạn và nhận phần thưởng (hoặc hình phạt) dựa trên sự đồng thuận về tính hợp lệ của yêu cầu của bạn. |\n\n\n# Tài liệu tham khảo\n"
  },
  {
    "path": "metadata.yml",
    "content": "title: A Decentralized Protocol for Remunerating the Open-Source Ecosystem\nabstract: >\n  Creating an open, public and stable registry for all open-source software\n  would empower projects to publish releases independently rather than rely on\n  third parties who assemble this irregular data into hundreds of separate\n  (and duplicated) systems. Package maintainers will publish their releases to\n  a decentralized registry powered by a Byzantine fault-tolerant blockchain to\n  eliminate single sources of failure, provide immutable releases, and allow\n  communities to govern their regions of the open-source ecosystem,\n  independent of external agendas.\n  \n  tea incentivizes the maintenance of open-source by allowing network\n  participants to stake value against the packages they depend on and want to\n  secure. The tea protocol’s graph provides immutable package registration,\n  dependency requirements, package authenticity, and usage oracles to inform\n  the tea remuneration algorithm. Systematic inflation is distributed to all\n  packages based on that algorithm. If security or development issues are\n  found, developers can make claims supported by evidence against the package,\n  and slashing may occur. Members of the open-source community can review\n  packages for quality issues, and the protocol can respond to these reviews\n  by enacting proportional slashing events.\n\nauthor:\n- Max Howell\n- Timothy Lewis\n- Thomas Borrel\nreferences:\n- id: sources\n  url: https://github.com/teaxyz/white-paper\n- id: cc\n  url: https://creativecommons.org/licenses/by-sa/4.0/\n- id: nist\n  url: https://nvd.nist.gov/vuln/detail/CVE-2021-44228\n- id: reuters\n  url: https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA\n- id: twitter\n  url: https://twitter.com/yazicivo/status/1469349956880408583\n- id: w3\n  url: https://www.w3.org/TR/did-core/\n- id: theregister\n  url: https://www.theregister.com/2016/03/23/npm_left_pad_chaos/\n- id: fossa\n  url: https://fossa.com/blog/npm-packages-colors-faker-corrupted/\n- id: lunasec\n  url: https://www.lunasec.io/docs/blog/node-ipc-protestware/\n- id: github\n  url: https://github.com/dominictarr/event-stream/issues/116\n- id: zdnet\n  url: https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/\n- id: threatpost\n  url: https://threatpost.com/backdoor-found-in-utility-for-linux/147581/\n- id: fbi\n  url: https://www.fbi.gov/news/stories/phantom-secure-takedown-031618\n- id: europol\n  url: https://www.europol.europa.eu/media-press/newsroom/news/800-criminals-arrested-in-biggest-ever-law-enforcement-operation-against-encrypted-communication\n- id: medium\n  url: https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502\n- id: semver\n  url: https://semver.org/\n- id: npmjsCrossenv\n  url: https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry.html\n- id: npmjsLodash\n  url: https://www.npmjs.com/package/lodash\n- id: npmjsChalk\n  url: https://www.npmjs.com/package/chalk\n- id: npmjsLogFourjs\n  url: https://www.npmjs.com/package/log4js/\n- id: arxiv\n  url: https://arxiv.org/abs/1207.2617/\n- id: web3\n  url: https://research.web3.foundation/en/latest/polkadot/overview/2-token-economics.html\nheader-includes:\n- \\usepackage{fancyhdr,ragged2e}\n- \\lhead{\\parbox[t]{0.5\\textwidth}{\\RaggedRight\\rightmark\\strut}}\n- \\rhead{\\parbox[t]{0.5\\textwidth}{\\RaggedLeft\\leftmark\\strut}}\n- \\setlength{\\headheight}{5\\baselineskip}\n- \\pagestyle{fancy}\n- \\fancyfoot[LE,RO]{© 2022 tea.inc.}\n"
  },
  {
    "path": "tea.csl",
    "content": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<style xmlns=\"http://purl.org/net/xbiblio/csl\" version=\"1.0\" default-locale=\"en-US\">\n  <info>\n    <title>World Wide Web - Tea variant</title>\n    <title-short>World Wide Web - Tea</title-short>\n    <category citation-format=\"note\" />\n    <category field=\"generic-base\" />\n    <updated>2022-05-02T021:57:32+00:00</updated>\n    <rights license=\"http://creativecommons.org/licenses/by-sa/3.0/\">This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License</rights>\n  </info>\n  <citation>\n    <layout>\n      <text variable=\"url\" />\n    </layout>\n  </citation>\n  <bibliography>\n    <layout>\n      <text variable=\"citation-number\" suffix=\". \" />\n      <text variable=\"url\" />\n    </layout>\n  </bibliography>\n</style>\n"
  },
  {
    "path": "white-paper.md",
    "content": "---\ndescription: Version 1.9\n---\n\n# white-paper\n\n## **Tea Network White Paper: From dApp to OP Stack Layer 2**\n\n* Max Howell\n* Timothy Lewis\n\n### Abstract\n\nA system in which open-source developers could receive rewards commensurate with their contributions would enhance the sustainability and integrity of the software supply chain. A decentralized protocol secured by reputation and incentives could accomplish this by facilitating value accrual back to the developers that maintain open-source codebases as a public utility, thus promoting future innovation and growth within the open-source ecosystem. Package maintainers will register their projects with a registry powered by a Byzantine fault-tolerant blockchain. The tea Protocol’s unique “Proof of Contribution” algorithm will determine each project’s contribution and impact to the system’s utility and health. Registered projects will receive rewards from the tea Protocol commensurate with their contribution, be secured through staking, benefit from a reputation system that spans projects and contributors, and have the option to allow communities to govern their regions of the open-source ecosystem, independent of external agendas. The tea Protocol will incentivize the maintenance of open-source by allowing network participants who registered their projects and comply with the rules of the network to receive rewards and contribute to their reputation and their projects. If security or development issues are found, developers can make claims supported by evidence against the package, and slashing may occur. Members of the open-source community can review packages for quality issues, and the protocol can respond to these reviews by enacting proportional slashing events.\n\n### Disclaimer\n\nThe information set out in this white paper is of a preliminary nature. Consequently, neither the authors nor any of their respective affiliates assume any responsibility that the information set out herein is final or correct and each of the foregoing disclaims, to the fullest extent permitted by applicable law, any and all liability whether arising in tort, contract or otherwise in respect of this white paper. Neither this white paper nor anything contained herein shall form the basis of or be relied on in connection with or act as an inducement to enter into any contract or commitment whatsoever.\n\nNothing in this white paper constitutes an offer to sell or a solicitation to purchase any tokens discussed herein. In any event, were this white paper to be deemed to be such an offer or solicitation, no such offer or solicitation is intended or conveyed by this white paper in any jurisdiction where it is unlawful to do so, where such an offer or solicitation would require a license or registration, or where such an offer or solicitation is subject to restrictions. In particular, any tokens discussed herein have not been, and, as of the date of issuance of this white paper, are not intended to be, registered under the securities or similar laws of any jurisdiction, whether or not such jurisdiction considers such tokens to be a security or similar instrument and may not be offered or sold in any jurisdiction where to do so would constitute a violation of the relevant laws of such jurisdiction. Do not purchase any tokens unless you’re prepared to lose the entire purchase price. It is a high-risk purchase and you are unlikely to be protected if something goes wrong.\n\n\n\n### Introduction and Context\n\n\n\nThe tea Protocol was originally introduced as a decentralized application (dApp) aimed at rewarding open-source software (OSS) developers for their contributions. It operates by integrating with major package managers (e.g. Homebrew, npm, pkgx) and uses blockchain-based tokens (TEA) to remunerate maintainers and contributors. At its core is the Proof of Contribution algorithm that quantifies each project’s impact (teaRank) and distributes rewards accordingly. In the initial implementation, the tea Protocol was built as a smart contract system on an existing Ethereum Layer 2 (Base, Coinbase’s Optimistic Rollup), effectively functioning on the application layer of another network.\n\nRationale for Evolving to a Layer 2: As usage grew and the limitations of operating purely as a dApp became apparent, the tea team decided to transition the protocol into its own Layer 2 network on Ethereum. By leveraging the OP Stack (Optimism’s modular rollup framework), Tea Network can achieve significantly higher throughput and lower transaction costs while inheriting Ethereum’s robust security. Optimistic rollups like those built on the OP Stack can offer 10x–100x scalability improvements by moving execution off-chain and posting minimal data on-chain. Unlike sidechains, these rollups derive their security directly from Ethereum by publishing transaction data back to L1, meaning the new Tea Layer 2 (“Tea Network”) retains Ethereum-grade security guarantees.\n\nBenefits of Layer 2 Migration: By becoming an OP Stack-based Layer 2, the Tea Network gains:\n\n• Scalability: The network can process many more transactions per second than Ethereum mainnet, bundling them into rollup blocks. This reduces congestion and gas fees for users. For example, Arbitrum (an Optimistic Rollup) at times surpassed Ethereum in daily transaction volume (\\~1.1M vs. \\~1.08M) while maintaining much lower fees, demonstrating the capacity of L2s to handle mass usage.\n\n• Efficiency: Users of Tea Network will enjoy faster confirmation times and cheaper interactions when staking to projects, claiming rewards, or executing governance votes. Batch submission of transactions to L1 and compression techniques drastically cut the per-transaction gas cost.\n\n• Security: Tea Network’s security model is anchored to Ethereum. The rollup is “optimistic,” assuming transactions are valid and using Ethereum as the arbiter in case of fraud. This means as long as there is at least one honest validator watching the Tea Network, any invalid state can be challenged and corrected on Ethereum. In effect, a single honest participant is sufficient to uphold security because the rollup relies on Ethereum’s consensus to settle disputes. This is a stronger security assumption than a standalone sidechain or appchain.\n\nIn summary, evolving into a dedicated Layer 2 allows the Tea Protocol to scale to meet global OSS adoption, reduce user friction (through lower fees and faster UX), and integrate deeper into Ethereum’s ecosystem – all while maintaining trustlessness and decentralization. The following sections detail the technical architecture of this new Tea Network, its core components, tokenomics, and the implications for security, governance, and future growth.\n\n### Technical Architecture\n\nOverview of the OP Stack: The Tea Network is built on the OP Stack, Optimism’s open-source development stack for creating new Layer 2 rollup chains. The OP Stack provides a standardized set of components (execution client, consensus/rollup node, communication contracts, etc.) maintained by the Optimism Collective, making it easier to launch a new chain that is compatible with other Optimism-based chains. It is designed as a public good, allowing projects like Tea to avoid reinventing core L2 infrastructure and instead leverage a battle-tested framework. In essence, the OP Stack powers Tea Network in the same way it powers Optimism Mainnet, meaning Tea’s L2 chain benefits from features such as EVM equivalence, modularity, and future interoperability within Optimism’s envisioned “Superchain” of interconnected L2s.\n\nOP Stack Infrastructure: The Tea Network’s architecture mirrors that of an Optimistic Rollup:\n\n• Execution Layer: A modified go-ethereum (Geth) client (forked for Tea) runs the Ethereum Virtual Machine (EVM) for the Tea Network. This execution engine is almost fully EVM-equivalent (thanks to Optimism’s Bedrock upgrade), allowing smart contracts from Ethereum to be deployed on Tea with minimal changes. The key customization in Tea’s execution layer is the inclusion of a GPG address precompile (discussed below). Aside from that, the transaction format, gas mechanics, and opcode set align with Ethereum, simplifying development and enabling use of standard Ethereum tooling on Tea Network.\n\n• Consensus / Rollup Layer: Tea Network does not run a separate proof-of-stake or proof-of-work consensus. Instead, it relies on Ethereum’s consensus (proof-of-stake) for security. Transactions on Tea are sequenced by a designated sequencer node (initially run by Tea), which packages L2 transactions into batches (blocks) and periodically submits a transaction containing these batches to the Ethereum mainnet. In Optimism’s design, a single sequencer handles block production to provide instant confirmations and state updates on L2 . Tea inherits this approach: the sequencer offers users fast transaction inclusion on Tea Network and then posts the batched data to Ethereum.\n\n• Data Availability: Each Tea Network L2 block’s data is published on Ethereum, ensuring the L2 state can be reconstructed by anyone independently. In the current implementation, batched transactions are posted to Ethereum as call data. As Ethereum’s roadmap evolves, Tea Network stands to benefit from upgrades like EIP-4844 (Proto-Danksharding) which enables L2s to post data in cheap blob space. Under Optimism’s Bedrock architecture, L2 blocks can be submitted to a special L1 contract or address (e.g. 0xff..0010) using blobs, making data availability secure and cost-efficient . Tea will integrate these capabilities as they become available, further driving down costs.\n\n• Fraud Detection: The Tea Network is an Optimistic rollup, meaning it assumes L2 transactions are valid but allows fraud proofs to be submitted within a challenge window. An off-chain fault proof agent (sometimes called a verifier) monitors the L2 state updates Tea posts to L1. If an invalid state root or transaction is detected, a fault proof (formerly “fraud proof”) can be submitted to Ethereum to challenge it. Optimism currently sets a 7-day challenge period on mainnet , and Tea Network will use a similar window. During this time, funds withdrawn to L1 are locked, and finality is deferred until the window elapses. If a fraud proof succeeds, the invalid batch is rejected and Tea’s L1 published state is rolled back to the last valid point. This mechanism drastically differs from a simple dApp: in the dApp model, security relies solely on the correctness of smart contract code on a single chain, whereas Tea’s L2 design adds a layer of recourse – Ethereum itself – to correct any malicious or invalid L2 behavior. As noted, even a single honest validator or observer is enough to secure the rollup by submitting proofs of fraud.\n\nGPG Address Precompile: A standout feature of Tea’s technical architecture is the introduction of a precompiled contract for GPG (GNU Privacy Guard) key operations. Precompiles are built-in contracts at fixed addresses that perform complex computations more efficiently than regular smart contract code. Tea Network adds a new precompile at address 0x696 (an address chosen for the GPG feature) which verifies digital signatures made using GPG/PGP public keys. In practical terms, this GPG precompile takes as input a message hash, a GPG public key, and a signature, and returns a boolean indicating whether the signature is valid for that message and public key. This functionality is integrated at the protocol level, allowing smart contracts on Tea to leverage proven and widely-adopted PGP cryptography standards for authentication and identity verification, as well as giving developers access to new tools to build on-chain.\n\nThe role of the GPG precompile in the Tea Network is transformative: it bridges the world of PGP identity and Ethereum identity. Developers and users can register a GPG public key and effectively use that key to control a smart contract wallet on Tea. The Tea Network’s custom GPGRewardWallet (a smart contract wallet implementation) is designed to utilize this precompile. Each GPGRewardWallet contract is deployed deterministically for a given GPG key (using a create2 factory), and contains the GPG key’s identifier in its bytecode. This wallet can then verify instructions signed off-chain with the corresponding GPG private key. For example, a developer can sign a transaction or an authorization message with their GPG key, and the GPGRewardWallet on Tea will confirm its validity via the precompile before executing the intended action .&#x20;\n\nWhy GPG? PGP/GPG has long been used by developers for code signing, secure communications, and identity (e.g., signing Git commits and verifying software releases). By supporting GPG at the chain level, Tea Network taps into an existing Web of Trust. Developers may use their well-established GPG identities to interact with the blockchain, effectively linking their open-source contributions to on-chain actions in a verifiable way. This enhances security (since GPG private keys are usually kept offline or on hardware devices and are difficult to forge) and also user experience for developers, who can reuse familiar tools. The Ethereum community has discussed the idea of leveraging PGP on-chain to build decentralized identity services or keyservers. Tea Network’s implementation is a concrete step in that direction: it enables a cryptographic identity layer where actions on Tea can be tied to a real-world persona’s key (if they so choose), boosting trust in the provenance of contributions and votes without relying on centralized platforms, in a fully opt-in manner.\n\nAccount Abstraction and EIP-7702: Another technical enhancement in the Tea Network is its forward-looking support for account abstraction features. Account abstraction refers to allowing smart contract wallets to mimic externally owned accounts (EOAs) or otherwise letting users define custom verification logic for transactions. Ethereum’s recent EIP-7702 is highly relevant – it introduces a new transaction type enabling EOAs to temporarily execute smart contract code (essentially assigning them smart contract capabilities for a single transaction). In other words, EIP-7702 aims to let normal accounts enjoy the flexibility of contract accounts, paving the way for features like sponsored transactions, multi-sig approvals, or alternative signature schemes natively. Tea Network’s architecture, with the GPGRewardWallet and precompile, is aligned with this vision. By having contract-based accounts that can be controlled by arbitrary signature schemes (GPG or ECDSA), Tea is embracing account abstraction at Layer 2. Moreover, when EIP-7702 (and related proposals like ERC-4337) roll out on Ethereum, Tea’s design will be ready to integrate or support those capabilities. For instance, if Ethereum L1 allows EOAs to delegate to a “smart contract wallet template” for a transaction, Tea Network users could similarly benefit from unified account abstractions between L1 and L2. In summary, Tea Network bakes in account abstraction through its GPGRewardWallet system and is built to be forward-compatible with Ethereum’s AA roadmap, such as EIP-7702 which enables EOAs to use smart-contract features in a trust-minimized way .\n\nEnhancements Over the Original dApp: Compared to the original tea dApp deployment, the new Layer 2 architecture introduces notable improvements:\n\n• Scalability: In the dApp model, every user action (staking TEA, registering a project, claiming a reward) was an Ethereum transaction (on Base or mainnet), competing with all other network traffic. Now, those actions occur on Tea’s own chain with abundant capacity, then settle to L1 in aggregated form. This means far greater throughput and negligible marginal cost per action, removing bottlenecks for adoption.\n\n• Transaction Efficiency: Tea Network transactions consume gas on the L2, which is orders of magnitude cheaper than L1 gas. Users can interact with the protocol with minimal fees (fractions of cents), whereas previously certain complex interactions on Ethereum could be prohibitively expensive during peak congestion. We can see a real-world analogue in Arbitrum: on a day when both Arbitrum and Ethereum processed \\~1 million transactions, Arbitrum users paid only \\~2.3% of the fees that Ethereum users did – illustrating the cost savings a rollup achieves by batching and offloading work.\n\n• Security Model: The shift to a rollup introduces the security backstop of Ethereum’s validation. In the prior implementation, security relied on the correctness of tea’s smart contracts and the security of the host chain (Base/Ethereum). In the new model, even if a bug or exploit were to occur in Tea’s Layer 2 logic, Ethereum’s fraud proof mechanism provides a chance to challenge and undo malicious transactions, significantly mitigating worst-case scenarios. The requirement that a single honest actor can prevent fraud is a powerful guarantee not present in a standalone dApp environment.\n\n• Extensibility: As a full-fledged chain, Tea Network can incorporate Ethereum Improvement Proposals (EIPs) at the protocol level. The Geth fork can be upgraded with new precompiles, opcodes, or gas adjustments as needed for Tea’s use cases, without waiting on all of Ethereum. This flexibility was not available when Tea was just a contract. For example, Tea implemented the GPG precompile directly, something that would be impossible to achieve via a normal smart contract on mainnet.\n\n• Interoperability: Through the OP Stack, Tea Network can natively interoperate with other Layer 2 networks in the Optimism ecosystem. Future plans for the Optimism Superchain mean multiple L2s will communicate trustlessly. As Tea joins that ecosystem, it could allow cross-chain messaging between Tea and chains like Optimism or Base (e.g., recognizing reputation or assets across chains), broadening the reach of the tea Protocol beyond a single chain.\n\nIn conclusion, the Tea Network’s technical architecture is a robust Layer 2 rollup design that combines the strengths of Optimism’s OP Stack (scalability and Ethereum alignment) with Tea’s unique innovations (GPG identity precompile and advanced account abstraction features). This foundation sets the stage for the specialized components of the Tea Network described next.\n\n### Tea Network Components\n\nThis section delves into the major components of the Tea Network’s Layer 2 architecture and how they work together to support the protocol’s mission.\n\n### Layer 2 Core Components:\n\n• Sequencer and Nodes: The Tea Network initially utilizes a single sequencer model (common in early rollups) to produce blocks. The sequencer node receives L2 transactions (from users or dApps on Tea), orders and executes them using the Tea execution engine, then submits the resulting transaction data and state root to Ethereum. Community full nodes can run the same software to independently verify blocks. The sequencer provides rapid confirmations (often within \\~2 seconds per block, as in Optimism’s network) so users experience near-instant transaction finality on L2. In the future, the sequencer role can be decentralized – multiple validators or block producers might compete or rotate via a consensus mechanism, potentially using TEA staking (as discussed in the Tokenomics section) to secure block production. This evolution would make Tea Network permissionless at the block production level, akin to a decentralized validator set.\n\n• Bridge Contracts: Bridging between Ethereum (Layer 1) and the Tea Network (Layer 2) is handled by a set of contracts largely inherited from Optimism’s design. On Ethereum, the L1StandardBridge contract holds custody of tokens (like TEA or ETH) that are deposited into L2, and the L1CrossDomainMessenger passes arbitrary messages to the L2. Corresponding contracts on Tea Network (L2 side) release tokens to users and deliver messages to contracts based on L1 inputs. When a user deposits assets, the flow is: user sends tokens to the L1 StandardBridge -> event is read by the Tea sequencer -> equivalent tokens are minted or released to the user’s address on Tea L2 . This typically completes within one Tea block, meaning deposits finalize on L2 within minutes of the L1 transaction. Conversely, withdrawals initiate an L2 transaction (locking tokens on Tea and informing L1 of intent), then require the challenge period to pass. After that, the user can execute a finalize step on L1 to unlock the tokens from the L1 bridge contract . The standard bridge design provides trust-minimized connectivity between Tea and Ethereum; no third-party custodians are needed – security is guaranteed by the rollup fault proof proof-of-fraud mechanism and Ethereum itself.\n\n• GPG Address Precompile & GPG Reward Wallet: The GPG address precompile (at address 0x696 on Tea Network) is a low-level component, but its presence has ripple effects throughout the stack. This precompile is essentially a native PGP signature verification engine. It takes four inputs: a 32-byte message digest, an 8-byte key ID, a binary-encoded public key, and a signature. Internally, it performs the cryptographic checks (RSA or ECC based on the PGP key type, parsing the signature structure, etc.) and returns true/false for validity . The precompile is optimized in native code, making these operations far cheaper than if implemented in Solidity. Built atop this is the GPGRewardWallet system – a smart contract wallet factory (GPGRewardWalletDeployer) and implementation that leverages the precompile. Each GPGRewardWallet contract is a minimal proxy that holds a specific GPG key’s ID in its code (for identification). The factory uses a create2 scheme to ensure a unique deterministic address for any given GPG key (so a particular key always maps to the same contract address). When a user wants to activate their GPG identity on Tea, they deploy a GPGRewardWallet via the factory, providing their public key. The result is a wallet contract that the user can control by presenting valid signatures from their GPG private key. The wallet contract also supports adding traditional EOA addresses as authorized signers (which themselves can be gated by requiring a GPG signature to add). This design means a developer could, for example, use their hardware GPG key to sign an AddSigner message that authorizes their MetaMask wallet address; thereafter, they can transact on Tea with either their GPG key or that Ethereum key, offering both convenience and security.\n\nUse Cases of GPG Identities: With this GPGRewardWallet mechanism, Tea Network introduces new possibilities for secure user identity and verification:\n\n• Verified Developer Identities: OSS maintainers often sign software releases or git commits with GPG. Tea can allow maintainers to link those same keys to on-chain actions. For instance, a maintainer could register their project on the Tea Network by signing the registration transaction with the same GPG key they use for their code. Users of the protocol (or automated systems) could verify on-chain that the person performing an action is indeed the owner of the PGP key associated with a popular open-source project, creating an authenticated link between version-control signatures (off-chain) and Tea (on-chain).\n\n• Decentralized Key Infrastructure: Over time, the Tea Network could become a decentralized key directory. With appropriate smart contracts, users might publish their GPG public keys on-chain (signed by the key itself or attested by others), turning the Tea Network into a decentralized PGP keyserver. This aligns with the Ethereum community’s motivation to improve key discovery and trust without centralized servers. In Tea’s context, an on-chain registry of GPG keys tied to Ethereum addresses and perhaps DID profiles could emerge, enhancing both security and reputation tracking.\n\n• Privacy-Preserving Login: Users could use their GPG keys as an alternative login method to dApps on Tea, as opposed to Metamask signatures. Since GPG keys can be kept completely offline (airgapped) and only produce a signature when needed, users might prefer this for certain interactions. (Additionally, because the GPG signature verification is done in a precompile, no one sees the actual public key on-chain unless needed – potentially allowing selective disclosure of identity.)\n\n• Project Registry and Package Manager Integration: While not a “layer 2 infrastructure” component per se, a key on-chain component of the Tea Network is the decentralized project registry inherited from the original protocol design. This registry is a smart contract (or set of contracts) on Tea that tracks all onboarded OSS projects, their metadata, maintainer addresses, and staking/reputation status. It is the on-chain source of truth for which packages are participating in the tea Protocol and their current scores (teaRank) or reputation. In the L2 context, this registry can be much more feature-rich than on L1 due to lower cost: it can store more detailed metadata, maintain complex structures of dependencies, and be updated frequently as project metrics change, all without prohibitive gas cost. This registry is complemented by off-chain package manager hooks – for example, integrations or plugins for npm, Homebrew, etc., that query Tea Network’s registry to fetch info (like “is this package verified or highly ranked on Tea?”). Thus, the Tea Network’s blockchain acts as a back-end for package managers, providing an immutable ledger of package trust and contribution data .\n\n• On Tea L2, one can imagine the registry being augmented with NFT representations of packages or contributor profiles, decentralized storage links for documentation, and more, since performing these operations is now feasible at scale. The Storage System for package data mentioned in the original white paper (perhaps involving IPFS or Arweave for storing tarballs, etc.) would also interface with Tea L2 for integrity checks. Content-addressed hashes of OSS releases could be logged on-chain to ensure immutability and traceability of the supply chain, with Tea’s consensus anchoring them periodically to Ethereum for ultimate security. This is a significant expansion beyond the original dApp, moving toward a decentralized package registry that the white paper envisioned – now implementable on a performant L2.\n\n• Cross-Chain Communication: The Tea Network, by virtue of being an Ethereum rollup, can also serve as a hub for cross-chain activity related to OSS incentives. Using the Optimism/OP Stack standard message passing, Tea can communicate with other chains. For instance, a smart contract on Ethereum or another L2 could send a message to Tea (via the Optimism-style CrossDomainMessenger) to trigger an action – such as updating a project’s score after a certain on-chain event. Likewise, Tea can output messages that are read by L1 or others (once the output is finalized on Ethereum). This enables scenarios like bounties or rewards that originate on Ethereum mainnet but are distributed on Tea, or conversely using Ethereum mainnet as an archive or backup for critical Tea data. Being part of the OP Stack ecosystem means down the line, Tea Network could participate in shared sequencing or bridging with networks like Base and Optimism, increasing reliability and potentially even atomic transactions across them (the Superchain concept). From a component standpoint, this means Tea’s node software includes a cross-domain message inbox and outbox, tracking L1->L2 and L2->L1 messages. The security of these is, again, rooted in Ethereum – messages from L1 to Tea are trusted after a few confirmations on Ethereum, while messages from Tea to L1 are subject to the challenge period (they only execute on L1 after Tea’s state is finalized).\n\nIn summary, the Tea Network comprises the blockchain core (sequencer, nodes, bridge contracts) and unique protocol-specific modules (GPG identity system, OSS registry). Together, these components create a Layer 2 platform tailored for the open-source ecosystem. The chain’s capabilities are generalized (anyone can deploy arbitrary smart contracts on Tea as on any EVM chain), but its value-added services (like the GPGRewardWallet and package registry) make it especially powerful for applications involving developer identities, software distribution, and decentralized trust for software. Bridging ensures Ethereum remains the settlement layer, anchoring Tea’s state and connecting Tea to the broader crypto economy. With the technical underpinnings described, we now turn to how the economic design (tokenomics) undergirds and incentivizes this new network.\n\n### Tokenomics and Incentives\n\nThe transition to a Layer 2 network entails a significant evolution of TEA tokenomics to support both the original OSS reward model and the new infrastructure and security needs of the chain. This section compares the new token economic design with the original dApp model, highlighting changes in token utility, distribution, and incentives for various participants (developers, users, and validators).\n\nTEA as the Native Layer 2 Token: In the original protocol, TEA was an ERC-20 token that users staked on projects and earned as rewards. Gas fees for interactions were paid in ETH (or the native token of the host chain, e.g. ETH on Base). With Tea Network becoming its own chain, TEA is now the native currency of the Layer 2. This means that transaction fees (gas) on the Tea Network are paid in TEA. The TEA token thus acquires a fundamental utility in the network’s operation: every transfer, contract execution, or stake operation on Tea requires TEA for gas. According to the team’s token overview, TEA is required to register and support software projects and pay gas fees for transfers and protocol activity . This marks a new demand driver for the token; as usage of the chain grows, developers and users must hold a balance of TEA to fuel their transactions. It aligns the token’s value with network utilization (similar to how ETH is valuable partly because it’s needed for gas on Ethereum).\n\nStaking and Support Mechanisms: The original model of “staking your tea” to support OSS projects remains central. Users can lock TEA tokens on the Tea Network’s smart contracts to endorse particular open-source projects. By doing so, they signal trust and share in the project’s future reward flow (the protocol would distribute TEA rewards to both maintainers and those who staked on them, proportional to teaRank and stake contributions). This mechanism continues on Tea L2, but with improvements in efficiency. Staking to a project is just an L2 contract call (cheaper and faster than L1). Projects can have many micro-stakes added or removed dynamically without incurring high gas, enabling more granular and frequent support from the community. Additionally, staking is used in new ways:\n\n• Vulnerability Bounties: Tea Network implements an on-chain vulnerability reporting and bounty system. Ethical hackers or users who find bugs in registered OSS packages can report them through the protocol. To prevent spam and low-quality reports, reporters must put up a stake of TEA as a bond. Vulnerability reporters must stake TEA to submit a report and earn bounties . If the report is valid (confirmed by maintainers or adjudicators), they get a TEA reward (and their stake back, possibly with a bonus); if not, their stake might be slashed or forfeited. This use of TEA for security incentives encourages the community to actively police package quality and security, a crucial aspect of securing the software supply chain.\n\n• Node/Validator Staking: Although the initial rollout of Tea Network will have a centralized sequencer, the roadmap likely includes decentralizing validators. In an Optimistic Rollup, validators (entities submitting state roots to L1 and potentially challenging fraud) might be required to put up a bond in TEA to participate. This is analogous to the concept of a fault prover bond – to submit a fault proof, one may need to bond some amount that gets slashed if the proof is invalid. Moreover, if and when multiple sequencers are allowed (perhaps via a round-robin or auction mechanism like some rollups plan), those sequencers could be chosen or weighted based on TEA stake (similar to a Proof-of-Stake system). The TEA token thus could play a role in Sybil-resistance and economic security of L2 consensus. For example, if Tea implements a sequencer set, bidders would burn or lock TEA for the right to produce blocks for a period. While details are to be determined, the Layer 2 setup opens the door for TEA to secure the network itself, beyond securing just the application logic.\n\nReward Distribution and Token Emission: The core purpose of TEA remains to reward open-source contributions. Tea Network will continue to calculate rewards for projects (using the off-chain metrics and on-chain stakes) and distribute TEA tokens periodically to those projects and their supporters. In the original model, these rewards might come from a token inflation or a treasury. On Tea L2, this process can be more transparent and community-governed. The protocol can charge fees or take a small percentage of staking rewards to fund a protocol treasury (a DAO fund in TEA). Indeed, the tokenomics are designed such that fees from various OSS activities on the network accrue back to TEA token holders engaged with the network . Concretely, this could mean:\n\n• A portion of transaction fees on the network are funneled into a treasury or reward pool (rather than all being burned or given to miners as on Ethereum). This pool then redistributes tokens to active contributors in OSS.\n\n• When new projects onboard, they might pay a listing fee in TEA (to prevent spam). Those TEA could be redistributed as rewards.\n\n• If a project’s package is widely downloaded or depended upon, the protocol might levy a tiny TEA fee from dependent projects (as per the value flow envisioned in Proof of Contribution). These fees go into the reward algorithm, ultimately paying out to maintainers. Because we are in a full blockchain environment, implementing such micro-fees and recursive distribution is more tractable.\n\nThe TEA token may have an inflation schedule to continuously incentivize participation. For example, an annual issuance allocated to maintainers and stakers (similar to how some PoS networks or mining networks issue new coins to reward participants). This must be balanced against the desire for token value stability. Governance (see next sections) will likely oversee any inflation parameters or use of treasury tokens.\n\nComparison with Original Model: In the original tea protocol, TEA’s utility was focused on governance and staking in the context of OSS rewards. As a dApp, it did not need to facilitate gas or infrastructure. Now, TEA has a broader utility set:\n\n• Gas Token: Perhaps the biggest change – TEA is consumed for gas on every transaction on Tea Network . This creates a direct link between network activity and token demand (similar to ETH for Ethereum, or MATIC for Polygon, etc.), which did not exist previously.\n\n• Incentive Alignment: TEA is still staked to signal support for projects, but the feedback loop is stronger. Stakers potentially earn a portion of not just inflationary rewards but also fee revenue from the network. The documentation suggests that a portion of fees from OSS activities will accrue back to engaged TEA holders . This implies if you stake and actively participate, you might receive dividends or yield in TEA drawn from network usage. Originally, rewards came from new issuance or an overall pool – now it could be partially funded by actual usage fees, making the model more sustainable.\n\n• Governance Power: Previously, holding TEA allowed one to participate in governance votes about protocol parameters. This remains, but with the network upgrade, governance might extend to chain-level decisions (like upgrading the rollup software, managing the sequencer, etc.). The value of governance rights may thus increase. The TEA token’s role in governance is discussed in detail in the Governance section, but tokenomics-wise: TEA is an ERC-20 on Ethereum mainnet (for broad accessibility and distribution) but effectively functions as the native coin on Tea L2. Bridging ensures that the same token can move between L1 and L2 – users may hold TEA on Ethereum (for custody or trading) and then bridge it to Tea L2 when they want to use it for gas or staking.\n\nStaking Mechanisms, Validator Incentives, and User Benefits:\n\n• Staking & Slashing: Various protocol roles will involve staking TEA. Project maintainers might be required to stake a small amount of TEA when registering a project (to discourage low-quality submissions and slash if the project turns malicious). Validators (if permissionless) will stake TEA and be slashed for malicious behavior (like submitting invalid state roots that get proven fraudulent). Community reviewers who stake on a project’s quality are effectively putting skin in the game and can be slashed if they vouched for a project that then is found to be malicious (creating a disincentive for blindly staking on every project, and an incentive to do due diligence). These slashing conditions secure the network and the integrity of the OSS registry.\n\n• Validator/Sequencer Incentives: In the near term, the Tea Association or core team runs the sequencer and can be subsidized by a portion of L2 gas fees. In the long term, if multiple sequencers are run, they will need incentives to participate honestly. One model is sequencer auctions where candidates bid TEA for the right to produce blocks (the highest bidder gets to be sequencer for a fixed interval, and their bid is burned or given to the treasury – this mechanism, used by networks like SUAVE proposals, could be considered). Another is round-robin with slashing: each validator takes turns proposing blocks but must stake TEA and gets slashed if they attempt to censor or post invalid state. They would earn the gas fees from the blocks they produce, making it profitable to behave correctly. Because Tea’s throughput and usage could be high (given many OSS transactions), the fees themselves could be a significant incentive.\n\n• User Benefits: Regular users (developers, project supporters, etc.) benefit from the new tokenomics in several ways:\n\n• Lower Fees: Paying gas in TEA on the Tea Network will generally be much cheaper than paying ETH on mainnet for equivalent actions. Users can support more projects or make smaller contributions that wouldn’t have been economical before. Essentially, their TEA goes farther on L2.\n\n• Earn by Participating: Users can earn TEA rewards by actively using the network – e.g. by staking to projects that do well, by reporting bugs, by curating packages, or simply by providing liquidity if there are DEXs on Tea. The tokenomics could include liquidity mining or usage mining programs (for instance, early users of the Tea Network could get bonus TEA rewards or NFT badges).\n\n• Alignment with OSS success: Since TEA value is tied to network success and network success is tied to OSS adoption, users holding TEA essentially hold a stake in the growth of the open-source ecosystem’s reward system. This could galvanize a community of token holders who advocate for more projects to join Tea, more developers to accept TEA, etc., driving a positive feedback loop.\n\nTo illustrate the token flow, consider an example: A developer publishes a new library and registers on Tea, staking some TEA. Over time, the library becomes widely used; the Proof of Contribution algorithm assigns it a high teaRank, and it starts earning TEA from the protocol’s reward pool (funded by maybe both inflation and a cut of fees from other projects using the library). Those TEA rewards are split between the maintainers of that project, delivered on Tea L2. The maintainer might bridge some rewards to Ethereum to cash out via a DEX or use some to engage with other projects on the tea Network. Meanwhile, all interactions (staking, reward claims, etc.) incurred small TEA gas fees, some of which went into the treasury. At quarter’s end, a certain amount of TEA in the treasury is distributed to incentivize new OSS communities, to active voters or burned to benefit all holders (governance decides). In this cycle, every action involves TEA: as gas, as stake, as reward, as governance power. This comprehensive integration of the token into the system’s functionality is a hallmark of the new tokenomics.\n\nIn comparison, originally TEA acted more like a pure governance and reward token. Now it is multi-dimensional: gas, governance, staking, and utility token. This should strengthen the token’s value proposition and incentive alignment. It means all stakeholders – maintainers, backers, validators, and regular users – have roles to play and incentives to hold and use TEA.\n\nThe tokenomics design also learns from other major Layer 2 implementations:\n\n• Optimism (OP token): Optimism introduced the OP token for governance and funding public goods, but notably not as a gas token (Optimism still uses ETH for gas) . Tea diverges here by using TEA for gas, which more closely resembles chains like BNB Chain or Avalanche. However, Tea can still adopt Optimism’s idea of an ecosystem fund – a portion of TEA (from initial allocation or ongoing fees) could be allocated to a grants program to fund open-source tooling (which directly aligns with Tea’s mission of supporting OSS).\n\n• Arbitrum (ARB token): Arbitrum’s ARB is purely a governance token for the Arbitrum DAO and does not have a role in gas or validation. Tea’s TEA token stands to be more utilitarian. But Tea can emulate Arbitrum by establishing a DAO treasury and Security Council. Arbitrum set aside a large treasury controlled by its DAO for protocol upgrades and ecosystem support . Tea could do similarly, meaning token holders control funds to, say, incentivize certain package ecosystems or sponsor hackathons. Additionally, Tea might implement a Security Council (multisig of trusted community members elected by TEA holders) that can act quickly to patch security issues or halt the protocol in an extreme emergency, with later ratification by a vote (Arbitrum DAO has such a council for fast intervention ). If so, council members could receive a TEA stipend for their duties.\n\nIn conclusion, the Tea Network’s tokenomics reinforce its technical architecture: TEA is the lifeblood of the new Layer 2. It provides economic security and incentives at the chain level (through gas and potential validator staking) and continues to drive the unique value proposition of the tea Protocol (through staking to OSS projects, distributing rewards, and enabling governance). These changes are designed to ensure a sustainable, self-reinforcing ecosystem where contributors are rewarded, token holders have a say in the protocol’s direction, and the network remains secure and useful long-term. The next section will explore the application layer and use cases unlocked by this new Layer 2 design, showing how these technical and economic pieces come together in practice.\n\n### Use Cases and Application Layer\n\nMigrating to an OP Stack Layer 2 significantly broadens the horizon of what can be built and supported on the Tea Network. Beyond simply replicating the original protocol’s features on a faster chain, the new architecture enables expanded use cases and richer applications that were previously impractical. In this section, we explore the new and enhanced use cases facilitated by Tea’s Layer 2, and how they demonstrate the network’s utility beyond the initial dApp’s functionality.\n\n1\\. Scalable OSS Rewards and Interactions: The primary use case – rewarding open-source contributions – is supercharged on the Tea Network. In the dApp version, users could stake to projects and earn rewards, but high gas fees limited how often and how many projects a typical user might support. Now on Tea L2, a user can stake small amounts of TEA to dozens of libraries, upvote or review projects, and claim micro-rewards frequently, since each action costs pennies or less in gas. This granularity means Tea can capture a far more detailed graph of contributions and endorsements. Maintainers can update their project info, publish releases, or send thank-you NFT badges to contributors via on-chain transactions without worrying about cost. This creates a much more interactive and engaging platform for OSS, akin to a social network of code, but secured on-chain. The result is a richer dataset for Proof of Contribution and an always up-to-date reputation system for developers and packages. Essentially, the core use case of tea – incentivizing and analyzing OSS usage – can now operate in real-time at scale.\n\n2\\. Real-Time Incentivized Testnets and Developer Sandboxes: The Tea Network itself can host incentivized campaigns to bootstrap activity. In fact, the team launched the Assam testnet as an “incentivized testnet” showcasing some of these possibilities. Participants in Assam were encouraged to build and play on the network: deploying smart contracts, sharing test tokens, and even playing classic blockchain games . This was not directly related to OSS rewards, but it served to stress-test the network and reward ecosystem engagement. The testnet environment introduced gamified tasks – for example, rewards for top token holders, top token distributors (to encourage transactions), and top smart contracts by activity . These kinds of campaigns demonstrate Tea Network’s flexibility as a general-purpose blockchain platform. They also help attract a community of Web3 enthusiasts and developers, beyond just open-source maintainers. By hosting such applications (like nostalgic games or trading competitions) in parallel, Tea Network gains activity and attention that ultimately spills over to the core OSS mission (some of those engaged users can be funneled into contributing to or using the OSS reward features).\n\n3\\. Decentralized Package Infrastructure: One of the envisioned real-world applications is a decentralized package registry and package manager integration. On Tea Network, every package (project) registered can be represented on-chain with a unique ID. Using Tea’s open APIs or subgraph, a package manager (like a decentralized version of npm or Homebrew) can query the blockchain to resolve package information. This opens use cases such as:\n\n• Verified Downloads: A user installing a package could automatically check Tea Network to see if the package is verified, what its teaRank is, and whether any vulnerability reports are pending for it. If something is amiss (say the package was flagged on Tea with a vulnerability and slashed), the package manager could warn the user or fetch an earlier safe version. This brings blockchain-backed security to everyday software installation.\n\n• Automatic Rewards Distribution: When a company or individual wants to financially support the open-source projects their software depends on, they could use Tea Network as the rails. For example, a company could allocate a budget of TEA and have a script that scans their dependency tree, then automatically stakes TEA to those dependencies’ addresses on Tea Network proportional to usage. This process could even be implemented as a smart contract or DAO on Tea, taking corporate donations and streaming them to OSS maintainers trustlessly. Because Tea can handle many micro-transactions cheaply, even a large graph of dependencies with tiny allocations is feasible.\n\n• Persistent Developer Profiles: Developers can have on-chain profiles (perhaps tied to their GPG identity or an ENS name) listing all their projects and contributions. This can serve as a portable resume. When applying for a job or a grant, a developer could point to their Tea Network profile, which shows verifiable data: number of projects maintained, total TEA earned through Proof of Contribution, endorsements from other devs (if others stake on them or leave on-chain reviews), etc. This is a use case bridging professional networking and blockchain.\n\n• Donations and Patronage: Tea Network can facilitate direct donations to projects. The Donating to OSS Projects flow (advertised in the tea docs) becomes straightforward – a donor can send TEA (or even other bridged tokens) to a project’s address on Tea, which could trigger a contract that stakes it or distributes it among maintainers. Unlike traditional platforms, this can be non-custodial and automated. Donors could also receive NFT badges or a reputational score on Tea for supporting many projects, creating an on-chain record of patronage.\n\n4\\. Expanded Gaming and Experimental Apps: Outside the strict OSS scope, the Tea Network’s low fees and Ethereum compatibility make it suitable for various dApps. The Assam testnet already hinted at gaming by running classics like Satoshi Dice and Fomo3D . On mainnet, one can imagine hackathons where developers deploy innovative dApps on Tea to demonstrate the network’s capability. Some possible applications:\n\n• DAO Governance Tools: Tea Network’s governance features (with GPG integration) could be offered as a service to other communities. For example, an open-source project community could run their elections or votes on Tea Network using TEA or a project-specific token. Since Tea has account abstraction, one could set up voting where participants sign votes with GPG keys (proving one-person-one-vote if keys are verified identities), adding integrity to DAO votes. The low cost ensures even DAOs with many voters can operate cheaply.\n\n• Micropayments and Tipping: With TEA as currency and negligible fees, Tea Network could support tipping systems for content creators or developers. A browser extension could allow anyone to tip a GitHub repository author with TEA via the Tea Network, sending a small amount (like $0.10 in TEA) for a helpful answer or useful code snippet. Ethereum mainnet micropayments are not practical, but on Tea they are. Such tipping could integrate with existing platforms (via oracles or APIs) or through native web3 platforms.\n\n• Education and Quests: To onboard more developers, Tea can host interactive quests – smart contract puzzles, testnet challenges (like “find an exploit in a deliberately insecure contract for a reward”), or coding challenges where solving them triggers on-chain validation and reward distribution. This leverages Tea’s cheap transactions for rapid iteration and feedback. It also ties into open-source by encouraging learning and improvement in smart contract security and development.\n\n5\\. Use Cases Leveraging Account Abstraction (AA): Because Tea Network supports advanced AA, some novel applications become possible:\n\n• Meta-transactions and Sponsorship: A dApp on Tea could pay gas on behalf of users (by using contract wallets and paymaster mechanisms). For example, an OSS maintainer could ensure that new contributors don’t need to buy TEA to submit their first contribution. The maintainer can sponsor those transactions by funding a paymaster that covers gas for any transaction involving their project contract, making onboarding seamless. This is enabled by account abstraction where a contract (the paymaster) can handle gas logic. EIP-4337 style user operations could be implemented on Tea for an even smoother user experience.\n\n• Multi-Key Authentication: Using Tea’s GPGRewardWallet, apps can require dual signatures for critical actions (one with the user’s Ethereum key and one with their GPG key). An example use case is managing high-value treasury moves in a project: the maintainer could configure that any treasury withdrawal from the project’s funds requires confirmation with their GPG key (likely stored offline) in addition to their regular on-chain key. This significantly reduces risk of hacks (an attacker would need to compromise both keys). It’s a two-factor auth scheme natively on-chain.\n\n• Login with Ethereum/GPG: Outside the blockchain itself, Tea’s AA could integrate with web2. For instance, “Login with tea Network” could be an OAuth-like service where, instead of a password, a user signs a message with their GPG or Ethereum key and a Tea Network service verifies it via the precompile and logs them in. Since GPG keys can attach to an email, this can provide an identity that web2 services accept (with the blockchain acting as the verifier of the signature). It’s like a decentralized single sign-on. This use case intersects with decentralized identity (DID) systems and could make Tea Network a player in the self-sovereign identity space.\n\n6\\. Real-World Impact and Adoption Scenarios: Ultimately, the Tea Network’s expanded functionality aims to make open-source development more sustainable and integrated with the blockchain ecosystem. Real-world applications envisioned include:\n\n• Enterprise Open-Source Support: Large enterprises using open-source could interact with Tea Network to automate their compliance and support. For example, an enterprise DevOps system might query Tea to ensure none of the open-source components they use are marked as insecure (leveraging Tea’s registry and vulnerability reports) – essentially a decentralized “security feed”. If a new zero-day in a library is reported on Tea, an enterprise could be alerted immediately on-chain rather than via slower traditional channels.\n\n• Government and Institutional Funding: Governments or NGOs that grant funds to open-source projects can do so through Tea Network, for transparency and impact tracking. A grant can be disbursed in TEA with conditions encoded in a smart contract (e.g., milestones that trigger payouts). The public can see the grant’s distribution and the outcomes (did the project improve its rank? did it attract more stakers?), providing accountability. This can encourage more funding sources to go on-chain where results are measurable via Tea’s metrics.\n\n• Marketplace for OSS Services: Tea Network could host a marketplace where developers offer services (like support contracts, custom feature development) and get paid in TEA or other tokens. By having their reputation and prior contributions visible on-chain, it’s easier for customers to choose credible developers. Smart contracts could escrow payments and release upon completion, leveraging the network’s trust mechanisms.\n\nIn summary, moving to Layer 2 not only accelerates the existing tea Protocol workflows but also opens entirely new avenues. The Tea Network can serve as a multi-purpose platform centered on open-source: part decentralized app store, part social network for developers, part identity system, and part DeFi-like economy for software collaboration. It retains all general capabilities of an EVM chain, meaning it can host DeFi, NFT, and gaming dApps as well – which can enrich the ecosystem and draw more users who might then engage with the OSS aspects. The key differentiation is that all these uses benefit from or feed into the open-source mission, either by bringing more activity (hence fees and attention) or by directly integrating with the OSS reward system.\n\nThe original dApp scratched the surface of financially empowering developers. The new Tea Network, with its broader use cases, aims to create a vibrant, self-sustaining environment where open-source technology and blockchain technology co-evolve. In the next section, we turn to how such an ecosystem is governed, as decentralized governance will be crucial to guide the Tea Network’s growth and maintain alignment with community interests.\n\n### Governance Model\n\nWith the Tea Network’s transition to a Layer 2, governance becomes a multi-faceted domain encompassing both the on-chain protocol governance (deciding rules of the reward mechanism, token parameters, etc.) and the network governance (upgrades to the chain, sequencer configuration, etc.). A robust decentralized governance model is critical to ensure that no single entity controls the network’s evolution and that the community of TEA token holders, OSS developers, and users have a voice. This section outlines the updated governance framework, its mechanisms, and how it draws from best practices in Ethereum and other DAO ecosystems.\n\nDecentralized Decision-Making: In the spirit of open-source collaboration, the Tea Network embraces decentralized governance via a DAO (Decentralized Autonomous Organization). TEA token holders are the core stakeholders of the DAO. By staking or locking their TEA for governance (to prevent transient speculation from influencing votes), holders can propose and vote on changes to the protocol. This aligns with the original use of TEA for governance of the OSS reward parameters , but now extends to governing the Layer 2 network itself. For example, decisions that the Tea DAO would handle include:\n\n• Upgrading the Tea Network protocol (e.g., adopting a new version of the OP Stack, adding a new precompile or EVM extension, changing sequencer decentralization parameters).\n\n• Adjusting economic parameters (inflation rate of TEA, reward distribution formulas, fee allocation between treasury vs. sequencer vs. stakers).\n\n• Managing the community treasury (funding grants for development tools, sponsoring security audits, or even funding public goods in the broader Ethereum ecosystem in line with Tea’s mission).\n\n• Onboarding new package manager integrations or partnerships (for instance, deciding to officially support a new language’s package ecosystem which might require some on-chain schema or oracles).\n\n• Any changes to the rules around staking, slashing, and rewards that directly impact the OSS contributors.\n\nThe governance process will likely involve a proposal stage (where ideas are discussed, perhaps off-chain on forums or Commonwealth/Discord), followed by an on-chain vote using TEA. The voting power is typically proportional to the amount of TEA locked in governance by a user (similar to the token-weighted voting model used by many DAOs) . To ensure broad participation and prevent whales from unilaterally controlling outcomes, the Tea DAO might implement delegation – token holders can delegate their voting power to representatives or experts in the community who actively participate in governance debates . This has precedent in many DAOs and helps create a meritocratic layer of governance (where delegates build reputation by voting wisely and communicating with the community).\n\nGovernance Structure – Inspiration from Optimism and Arbitrum: Tea’s governance model takes cues from established L2 governance structures while tailoring them to the OSS context:\n\n• Optimism’s Two-House Governance: Optimism introduced an innovative two-chamber governance: a Token House (OP token holders) and a Citizens’ House (non-transferrable “citizen” NFTs for public goods governance) . The Token House governs technical and economic decisions, while the Citizens’ House allocates retroactive public goods funding. Tea Network could adopt a similar bicameral approach. The Tea Token House (TEA holders) would make decisions about protocol upgrades, tokenomics, etc. Meanwhile, a Contributor House could be formed – comprised not of token balance but by reputation or contribution scores (or perhaps elected OSS community leaders). This Contributor House might have veto power or advisory power on decisions that directly impact OSS developers, ensuring that governance doesn’t skew solely to token-weighted interests if those ever diverge from the interests of active developers. For example, if TEA holders (some could be pure investors) proposed to divert all rewards to token staking instead of maintainers, a Contributor House representing developers could push back. This structure draws on the idea that tokenholders are one constituency, but not the only stakeholders . Balancing economic incentives with the ethos of OSS is important; a two-house model could help avoid governance capture by purely economic actors.\n\n• Arbitrum’s On-Chain DAO: Arbitrum launched a fully on-chain DAO where ARB token holders vote on proposals (AIPs) that can directly execute on-chain if passed . They have a Constitution and a Security Council for emergencies . Tea Network can mirror a lot of this: having a Tea Improvement Proposal (TIP) system for formal changes, an on-chain voting portal, and a community-elected Security Council. The Security Council, perhaps 5-7 reputable community members or multi-sig holders, would have the mandate to act quickly in case of critical issues – for instance, if a severe bug is found being exploited, the Council could, via a special governance mechanism, pause the sequencer or upgrade the contract to fix it, subject to later review by the broader DAO. This is similar to Arbitrum’s council which can bypass the normal proposal timeframes to secure the network . The existence of this body is an acknowledgment that on-chain voting can be slow or ill-suited to emergency response, so a safeguard exists. Council members would be periodically elected by TEA holders (say every 6 months) , ensuring accountability.\n\n• Treasury and Public Goods: Both Optimism and Arbitrum put emphasis on funding public goods – Optimism with its RetroPGF (Retroactive Public Goods Funding) and Arbitrum with a large token allocation to a DAO treasury for development. Tea Network, given its focus on OSS (a public good), will likely allocate a substantial portion of TEA (either from genesis or ongoing fees) to a tea Treasury controlled by the DAO. Governance will decide how to spend this treasury. Obvious uses are funding improvements to the Tea protocol itself (grants for building better tooling, documentation, perhaps even funding developers to integrate Tea with more package managers), and rewarding contributions that don’t directly earn token rewards otherwise (for instance, someone who evangelizes and brings 100 new projects onto Tea might get a special grant). The governance model should incorporate a transparent process for treasury proposals and disbursements, taking inspiration from how Ethereum’s DAOs (like Uniswap’s or others) manage grant programs.\n\nParticipation and Inclusivity: To make governance accessible to both technical architects and non-technical stakeholders (such as open-source advocates who may not be blockchain experts), the Tea Network will invest in off-chain tools and processes:\n\n• A governance forum where proposals are presented in understandable terms, with pros/cons, and ample time for discussion. In these discussions, both technical details (perhaps provided by core devs or technical working groups) and broader implications (provided by community members, possibly with OSS background) are hashed out.\n\n• Voting interfaces that are user-friendly, possibly integrated into the Tea dApp, so that even maintainers who only casually use crypto can cast votes with a few clicks (for example, signing a vote transaction via their GPGWallet or MetaMask).\n\n• Education and transparency are key. All proposals can be tracked on-chain, and results are visible. The governance smart contracts would likely be an upgraded version of OpenZeppelin’s Governor contracts or Compound’s governance, customized for layer 2 deployment. These contracts ensure on-chain tallying of votes and execution of proposals that pass.\n\nDAO Integrations: The Tea Network DAO doesn’t exist in isolation. It can integrate with the wider DAO ecosystem:\n\n• It could use Snapshot (off-chain voting) for low-stakes signaling and use on-chain voting for binding decisions, to save gas and complexity.\n\n• It might partner with platforms like Tally or Boardroom which provide dashboards for DAO analytics, so anyone can see voting turnout, proposal history, and delegate performance.\n\n• Given the technical nature of some decisions, Tea DAO might form working groups or subcommittees. For instance, a “Protocol Upgrade Group” of volunteer experts can draft technical proposals (like adopting EIP-4844 when Ethereum is ready) and present them to the DAO. A “Community Committee” might vet community grant applications and make recommendations.\n\n• Cross-DAO collaboration: Tea’s mission overlaps with public goods funding. The Tea DAO could coordinate with entities like Gitcoin, Optimism’s Collective, or Ethereum’s community funds. For example, Tea might co-sponsor Gitcoin rounds for OSS devs, paying in TEA. Conversely, if Optimism’s Citizens’ House is funding public goods, the Tea Network’s success in rewarding OSS could be seen as a model – potentially Optimism’s governance might even direct funds to Tea’s treasury to amplify OSS funding (speculative, but shows how integration could occur). Having a governance model that is open and respected can invite such collaboration.\n\nGovernance of Layer 2 Upgrades: One important aspect is how upgrades to the L2 (which might be technically executed by the team initially) become governed. Optimistic rollups generally have an upgrade mechanism often controlled by a multisig during beta, then intended to be handed to a governance contract. Tea will likely follow a path: at launch, the core team or foundation manages upgrades for security and speed, but with a clear plan to decentralize. The governance model should include:\n\n• A timeline or milestones for decentralization: e.g., “After 6 months or after X mainnet transactions, the upgrade multisig will add community members or be replaced by the DAO entirely.”\n\n• When the DAO takes over, an on-chain Timelock contract can be used such that any protocol upgrade (contracts on L1 or critical config in the sequencer) must be queued via a governance timelock for, say, 7 days. This gives time for the community to react if a malicious proposal somehow passed or was implemented incorrectly.\n\n• Emergency brake: Possibly the Security Council or some quorum of core devs can delay an upgrade if it’s known to be harmful, even if the DAO passed it – but this is a contentious area and ideally avoided by thorough review during the governance process.\n\nLeveraging OSS Community Governance Practices: Many open-source communities have governance processes (though usually informal or off-chain). Tea Network can incorporate those to make OSS folks comfortable:\n\n• Use familiar norms like RFCs (Request for Comments) that mirror how Python or Rust communities propose changes. A TIP (Tea Improvement Proposal) could be formatted like an RFC, with rationale, backward compatibility analysis, etc., making it legible to developers.\n\n• Encourage maintainers of top OSS projects on Tea to become delegates or hold special advisory roles. This way, decisions always consider the view of actual OSS maintainers.\n\nEnsuring a Healthy Governance Ecosystem: Drawing from academic research on decentralized governance, a few principles are observed:\n\n• Governance Minimization: Don’t put every trivial thing to a vote. The Optimism governance principles mention keeping on-chain governance to the minimum necessary . Tea should similarly automate what it can and only govern what humans need to decide (e.g., algorithmic distribution of rewards is not voted on each round – the formula might be set by governance and then it runs).\n\n• Transparency and Accountability: Every governance decision should be recorded and outcomes measured. For instance, if the DAO funds a certain initiative, track its success (did it bring X new developers? Y new projects?). This can feed into retroactive rewards for governance participants if their decisions lead to positive outcomes (though this is experimental).\n\n• Inclusive Governance: Unlike some DeFi projects where governance is dominated by a few large funds, Tea’s community includes many developers who might not be “whales.” It’s crucial to avoid plutocracy. Techniques like quadratic voting (favoring wider distribution of tokens) or adding non-financial weight (like giving active contributors a slight extra boost in voting weight via soulbound tokens) could be considered to ensure governance is not just by the rich but by the active. For example, someone who maintained a project that achieved top 10 teaRank could be given a “Reputation NFT” that confers additional voting weight in certain decisions related to OSS incentives, balancing out pure token weight. This idea aligns with governance research that suggests incorporating reputation or identity to mitigate the weaknesses of token voting.\n\nIn practice, the Tea Network governance will likely evolve iteratively. Early on, more off-chain discussion and foundation guidance; later, more on-chain formalism and community control . By learning from Ethereum’s own governance (which is off-chain but rough consensus driven) and on-chain DAOs, Tea aims to create a governance model that stands the test of time, maintaining security (no abrupt risky changes), adaptability (can upgrade as tech and needs change), and community trust.\n\n### DAO Governance Comparisons:\n\n• The Arbitrum DAO is fully on-chain and one of the largest live DAOs, demonstrating that thousands of token holders can coordinate to govern a live L2 . It also showed some challenges (like initial controversies around how the foundation handled its first proposals). Tea’s governance will need to be extra transparent and communicative to avoid misunderstandings. Regular community calls, published minutes, and even votes on testnet (to practice) could help.\n\n• The Optimism Collective’s approach acknowledges that purely token-based systems have pitfalls (like short-termism or governance attacks) . By having multiple incentive-aligned groups (token holders, reputation holders), they aim for more robust decisions. Tea might not replicate the Citizens’ House exactly, but the concept of multi-faceted governance is valuable.\n\nIn summary, the updated governance model for Tea Network is one where TEA token holders via a DAO hold ultimate power over protocol directions, tempered by the input of the OSS community and safeguarded by special mechanisms for emergencies. It is a decentralized, transparent system that draws on the knowledge of Ethereum’s own governance experiments and the structures of leading Layer 2s. Over time, as the network grows, this governance will ensure Tea Network remains community-driven and aligned with its mission to empower developers, thereby preventing centralization of control or deviation from the values of open-source.\n\nHaving covered governance, we next consider how the network addresses security and privacy concerns, and meets regulatory challenges, to ensure long-term viability and trust.\n\n### Security, Privacy, and Regulatory Considerations\n\nOperating a new Layer 2 blockchain with a bespoke feature set (like Tea Network) requires careful attention to security and privacy, as well as awareness of the evolving regulatory landscape. This section discusses how the migration to Layer 2 improves security, what privacy features or implications arise (especially with GPG-based identity), and the regulatory considerations relevant to Tea Network.\n\n### Security Enhancements from the New Architecture:\n\n• Inherited Security from Ethereum: As highlighted earlier, Tea Network benefits from Ethereum’s battle-tested security. All L2 state transitions are eventually anchored on Ethereum, meaning an attacker would need to beat Ethereum’s consensus (highly improbable) or sneak through a fraudulent state without anyone noticing (also unlikely given decentralized scrutiny) to “hack” the L2’s ledger. This is a major improvement over being a standalone sidechain or even a dApp (where a vulnerability in the contract could be fatal). In essence, Ethereum is the security backbone. The optimistic rollup design ensures that if an invalid transaction were included on Tea, it can be challenged within 7 days and removed . Thus, user funds on Tea have strong safety guarantees – they can always withdraw back to Ethereum after the challenge period, assuming at least one honest watcher exists .\n\n• One-Honest-Validator Assumption: Unlike a normal blockchain where you might need >50% honest miners/validators, Tea’s security relies on the “one honest validator” model . This dramatically lowers the threshold for security. In practice, many parties (the Tea team, major token holders, independent observers, perhaps even Ethereum validators running verification nodes) will be monitoring Tea Network’s submissions to Ethereum. Any discrepancy would be quickly broadcast and a fraud proof submitted . This ensures the network state cannot be maliciously altered without detection. It also means users can feel confident using Tea Network with faster “soft” finality – although the challenge window is 1 week for finality, in practice fraudulent states would be reported within minutes and users would be alerted by community channels to stop trusting new L2 transactions until resolved .\n\n• Audits and Formal Verification: The Tea Network will undergo rigorous security audits, both of the custom smart contracts (bridges, GPGWallet, registry, etc.) and of the modified Geth client (especially the GPG precompile implementation). By building on the OP Stack, Tea can also inherit the security audits and improvements from Optimism’s codebase. Optimism’s code, including the Bedrock release, has been audited and tested by the community. Additionally, key components like the fraud proof system and cross-domain messaging have been scrutinized . Tea’s custom addition – the GPG precompile – will be isolated and carefully tested (including fuzzing with various PGP inputs). The complexity of PGP parsing suggests the team must be cautious; any bug there could be an exploit vector. However, by implementing it in Go at the client level, they can use mature PGP libraries and avoid the limitations of EVM code.\n\n• Smart Contract Security: For Tea’s on-chain contracts (like the OSS registry and staking contracts), established security patterns are followed. For instance, the staking logic might use time locks on withdrawals to prevent sudden exits, and the reward distribution might be governed by a well-tested algorithm. Where feasible, the contracts might use upgradable proxies at the start (under multi-sig control) to allow quick fixes if bugs are found, transitioning to fully immutable/governance-controlled once confidence is high. Community members skilled in security (possibly those who participate in the vulnerability bounty program) will no doubt review these as well. The bug bounty program itself is part of security: by incentivizing white-hat hackers to find vulnerabilities in the protocol and even in popular OSS packages, Tea Network creates a virtuous cycle of improving security for the ecosystem.\n\n• Sequencer Trust and Censorship Resistance: In the initial phase with a centralized sequencer, users do have to trust the sequencer for liveness (it could theoretically stop or censor transactions). To mitigate this, the Tea Network will likely have a policy or SLA for the sequencer (e.g., run by the foundation with high uptime). If the sequencer misbehaves, users can always withdraw via L1 directly after the timeout. On the roadmap is decentralizing this sequencer, which will eliminate single-party censorship risk. Even with one sequencer, however, it cannot steal funds due to the fraud proof mechanism. The worst it can do is delay inclusion of some transactions. The Tea Network could also explore integrating with emerging decentralized sequencer networks that some projects (like Astria or Espresso) are developing, to hand off block production to a third-party decentralized layer in the future.\n\n• MEV and Fairness: Miner Extractable Value (MEV) is a concern on any blockchain – sequencers could reorder transactions for profit. Optimism addresses this by having a private sequencer mempool . Tea can adopt the same: the sequencer does not expose a public mempool to prevent external frontrunning bots. Additionally, Tea could implement soft commitment to ordering (like using some fairness protocol or at least a first-come-first-serve policy with timestamps). As the network evolves, if multiple sequencers exist, an auction or rotation might inadvertently introduce MEV opportunities; governance could consider mechanisms like MEV smoothing or ordering constraints to ensure fairness and that MEV is captured for the community’s benefit (e.g., redirected to treasury).\n\n• Infrastructure Security: Running an L2 also involves node security, RPC endpoints, etc. The Tea team will likely partner with infrastructure providers (Alchemy, Infura, etc.) to provide robust public RPCs for users, and encourage folks to run their own nodes. The GPG feature might require some custom RPC (to create and sign transactions in a user-friendly way), but overall, standard Ethereum clients can be pointed to Tea’s chain ID and RPC to validate the chain.\n\n### Privacy Considerations and Improvements:\n\n• PGP-Based Identity and Privacy: At first glance, tying PGP identities to blockchain accounts could decrease anonymity. If a developer chooses to link their real-world identity (often an email or name attached to a GPG key) with their Tea Network address, they are making an intentional trade-off of privacy for reputation. Tea Network does not force this; it’s an opt-in feature. Many users may still use pseudonymous Ethereum accounts to interact. However, those who do link a GPG key might reveal personal information (like their email if someone looks up the key on public keyservers). The Tea Network should educate users: you can use a fresh GPG key (perhaps attested by others) if you want the security benefits without doxing yourself. In fact, Tea could collaborate with projects like Ethereum Name Service (ENS) or Gitcoin Passport to provide pseudo-anonymous but verified identities (e.g., an ENS name that has a proof of GitHub account control can serve similarly without exposing email).\n\n• Privacy of Transactions: Out of the box, optimistic rollups inherit the transparent nature of Ethereum – all transactions and balances on Tea L2 are public. For many OSS use cases, this is acceptable or even desired (public transparency of contributions and funding). However, there may be scenarios where privacy is beneficial (say a company wants to support a project anonymously, or a developer doesn’t want their income known). Tea Network could explore integration with privacy solutions:\n\n• Integrating a Layer 2 mixer contract for TEA (similar to Tornado Cash, but on L2 where fees are low, enabling even micro mixing). This would let users obscure the link between their deposit and withdrawal, if they value privacy.\n\n• Supporting account abstraction privacy – e.g., via stealth addresses or one-time meta-transactions. If EIP-4337 style bundlers are used, a user could have the option to send a transaction through a relayer that hides their address (though the relayer would see it). Research in this area (like Umbra protocol for stealth payments) could be brought into Tea’s AA wallets.\n\n• Zero-knowledge proofs: In the future, Tea might incorporate ZK-proof features for certain data. For example, a contributor could prove off-chain that they made a certain number of contributions (using a ZK proof from Git commits or so) and get a reward without revealing which exact commits were theirs. While speculative, this could allow recognition of work while preserving pseudonymity. The Tea Network’s modular nature (especially if it ever explores zk-rollup or hybrid models) could facilitate such advanced privacy-preserving reward mechanisms.\n\n• GPG Encryption: GPG isn’t just about signatures; it’s about encryption too. An intriguing possibility: the Tea Network could allow storing encrypted data on-chain that only a certain key can decrypt. For instance, a vulnerability report could be posted encrypted with the maintainer’s public key, so only they can read it (ensuring responsible disclosure). The precompile currently is for verification, not decryption (and decryption on-chain would be impractical, even with private keys, which remain in the custody of the key holder), but enabling a workflow of publishing encrypted data with on-chain pointers could be part of the DApp design (with off-chain tools). This uses PGP for confidentiality in conjunction with the blockchain for integrity and timestamping.\n\n• Personal Data and Compliance: The Tea Network largely deals with public code and pseudonymous identities, so it sidesteps many personal data issues (like GDPR) that a social network might face. However, if real identities are linked (e.g., an email in a GPG cert), one could argue that it becomes personal data. The Tea Network should likely advise users not to publish unnecessary personal info on-chain. In terms of privacy improvements, one could say Tea improves privacy relative to traditional funding models – OSS devs currently often rely on Patreon or GitHub Sponsors, where their earnings are known to those platforms and possibly governments. On Tea, a maintainer could receive funds to a pseudo-anonymous address with only a known alias. This is a double-edged sword: it gives maintainers financial privacy and autonomy, but also raises regulatory eyebrows perhaps (if large sums flow without KYC).\n\n### Regulatory and Compliance Challenges:\n\nBlockchain projects must navigate a complex regulatory environment:\n\n• Token Classification: The TEA token powers the network and is used for governance and utility. There is a risk regulators could view it as a security, especially in jurisdictions like the US, if it’s sold to raise funds or promises profit from others’ efforts. The team likely positioned TEA with a strong utility narrative (needed for gas, staking for network usage) to argue it is not an investment contract but a consumptive token. The governance decentralization also supports the case that it’s more like a governance token (which some regulators may still consider in security territory, but at least it’s decentralized). Tea’s focus on rewarding work (Proof of Contribution) also frames TEA as a work reward/token, somewhat analogous to mining rewards, which historically were less scrutinized than ICO tokens.\n\n• Compliance (AML/KYC): As a permissionless network, Tea cannot KYC every user or force AML checks on P2P transactions. However, if the foundation or company behind Tea works with enterprise or government funding, they may need to consider compliance solutions. For example, an enterprise using Tea treasury might want to ensure funds don’t go to sanctioned individuals. This could be handled off-chain (they choose which project to fund, presumably not one in a sanctioned region) or through analytics (monitoring addresses). The Tea Network could integrate with on-chain compliance services or encourage maintainers to identify themselves (optionally) if they want to attract corporate sponsors who need to report where money went.\n\n• IP and Content Regulations: The Tea Network’s on-chain registry might include links to software or metadata. There is a chance that someone could upload illegal content pointers (though actual code binaries likely stay off-chain). Governance and possibly automated filters would need to handle this (e.g., if someone registers a project on Tea that is actually malware or illegal, the community might vote to delist it and maybe slash the submitter). Being on a blockchain, content can’t be easily removed, but pointers or flags can be managed.\n\n• Operating a Layer 2: There might be legal questions about the entity running the sequencer. For instance, could a sequencer be seen as a money transmitter or operating a payment system? Generally, validators/sequencers in a decentralized network haven’t been classed as money transmitters because they do not take custody of user funds (they just order transactions). In Tea’s case, initially the foundation runs the sequencer, but funds are locked in smart contracts; the sequencer cannot misappropriate them due to the fraud proofs. Still, the foundation might seek legal advice to be sure operating the L2 is not considered a custodial activity. Over time, decentralizing this role also spreads out any regulatory risk.\n\n• Open-Source Software Legalities: One regulatory aspect aligned with Tea’s purpose is ensuring compliance with open-source licenses. Tea’s protocol possibly could be used to track licenses (e.g., you could imagine an enhancement where the registry notes a project’s license and if it’s copyleft, ensure that derivatives also register or something). While not a direct legal compliance issue, it’s a space where Tea might provide tooling (maybe an idea: a smart contract that can escrow funds until license compliance is verified? Probably outside scope, but interesting for future).\n\n• Taxation: Contributors earning TEA might wonder about tax implications. In many jurisdictions, getting tokens as reward is income (taxable). Tea Network could, as part of its off-chain services, provide users with data on their earnings to help with reporting. Perhaps a simple integration that shows fiat values at time of reward. While the network can’t handle taxes, being mindful of user needs (like documentation) improves compliance and user trust.\n\nSecurity and Compliance Balance: There is sometimes tension between privacy and compliance. Tea’s approach likely will be to maximize user privacy and autonomy (since developers may value that) but also provide options or features that allow voluntary compliance. For example, a project maintainer who wants to be transparent for funding purposes can verify their identity and perhaps get a badge “KYCed” or “Verified” that corporate donors might require. This could be done via a third-party (like OpenZeppelin’s Stamp or Gitcoin Passport) that issues an attestation on-chain about an identity. This way, those who need regulatory reassurance have it, while others can remain pseudonymous.\n\nAdditionally, by distributing decision-making via the DAO, Tea reduces centralized liability – it’s the community that governs, not an identified company making all decisions, which in theory decentralizes regulatory targets. However, the initial team will still be influential and likely a steward in early days, so they will comply with laws in jurisdictions they operate (e.g., if the foundation is in a certain country, they might geoblock sanctioned countries on their front-end, even though the protocol itself is accessible – a common compromise many projects do).\n\nIn terms of security assurances to users, Tea Network will publish a comprehensive security model (likely in this white paper or docs), which we’ve covered:\n\n• Emphasize that users always retain the ability to withdraw to L1 (though with a delay) – so they should feel safer putting value into Tea.\n\n• Recommend best practices like waiting for a block to be submitted to L1 before considering a large transaction final, if in doubt.\n\n• Possibly provide a tool or dashboard to monitor the status of L1 submissions and the challenge window countdown for peace of mind on large withdrawals.\n\nThe Tea Network can also engage third-party monitors (like independent orgs or hackerspaces) to audit in real-time. For instance, Trust, but verify: an independent service could run a full Tea node and tweet an alert if an invalid state is detected. Over time, as more users run nodes, this becomes decentralized.\n\nSumming up Security & Privacy: The Layer 2 architecture significantly strengthens security by leveraging Ethereum and by enabling new cryptographic authentication (GPG). The Tea Network’s design acknowledges that security is not just about code – it’s about processes (governance to respond to issues), incentives (bug bounties), and user empowerment (giving tools to manage their keys safely, e.g., contract wallets with social recovery perhaps). Privacy is improved in some senses (financial sovereignty for devs) but introduces new considerations (linking real identities). Tea provides optionality so users can choose their comfort level.\n\nBy addressing regulatory considerations proactively (decentralizing control, emphasizing the network’s public-good nature, and perhaps engaging with regulators through industry bodies), Tea Network aims to operate in compliance without sacrificing the permissionless nature that makes it valuable. This careful balance of security, privacy, and compliance will help ensure the Tea Network can grow widely and be seen as a legitimate, trustworthy backbone for the open-source ecosystem.\n\n### Performance, Scalability, and Trade-offs\n\nIn transitioning to an OP Stack-based Layer 2, the Tea Network achieves significant gains in performance and scalability. However, these come with certain trade-offs and design decisions. In this section, we detail the expected performance improvements (with any available benchmarks), the scaling characteristics of the Tea Network, and the trade-offs made between scalability, security, and decentralization.\n\n### Performance Benchmarks and Improvements:\n\n• Transactions Per Second (TPS): While exact TPS will depend on the complexity of transactions (gas used) and the hardware the sequencer runs, we can estimate based on Optimism’s benchmarks. Optimism and Arbitrum can handle on the order of hundreds of transactions per second under ideal conditions, compared to Ethereum’s \\~15 TPS limit . For Tea Network, many transactions will be relatively light (stakes, votes, simple transfers), so the TPS could be quite high. A realistic number might be 200–500 TPS of typical Tea interactions, which is a massive improvement over the dApp where everything was bottlenecked by L1 throughput.\n\n• Latency: Block time on Tea Network is configurable; Optimism’s is currently around 2 seconds. Tea could similarly target 2–4 second block times. This means that from the user’s perspective, an action like staking TEA to a project or claiming a reward would finalize on L2 within a few seconds, as opposed to waiting 12-15 seconds (one Ethereum block) or longer if congested. Faster confirmation improves user experience dramatically – it feels more like using a Web2 application.\n\n• Cost per Transaction: One of the most tangible improvements. On Ethereum mainnet, complex interactions (like multi-step staking) could cost dollars in gas. On Tea L2, the cost is a small fraction of that. For example, Optimism reports that its fees are typically 1/50th to 1/100th of L1 for simple transactions. Tea’s transactions, posted as calldata or blobs, benefit from those same savings . If Ethereum later enables data sharding, the costs drop even more. This means a user might pay, say, $0.05 in TEA for an operation that on L1 cost $5. Lower costs not only make existing operations cheaper but also enable new things (micro-distributions of rewards, continuous updates) that were infeasible when every on-chain update had a high price.\n\n• Throughput under load: The Tea Network can process bursts of activity without the spiky gas price behavior of Ethereum L1. For instance, if a very popular OSS project suddenly gets a huge token stake from thousands of supporters (say after a big announcement), the flurry of transactions will be handled in batches on L2. Users might see slightly slower inclusion if it exceeds immediate throughput, but the sequencer can include them in subsequent blocks rapidly. The gas price on L2 might increase if the sequencer is congested, but since the block space is much larger, this should be a gentler effect. Additionally, the sequencer can adjust block size (within constraints of what’s efficient to post to L1) to accommodate more transactions in one batch if needed. There is a cost trade-off (bigger batches cost more on L1), but if many users are sharing that cost, it remains economical.\n\n• Benchmark Comparison: We can refer to known stats: Arbitrum One, for example, has achieved over 2 million transactions in a day at peak , which averages \\~23 TPS sustained, but it wasn’t near its technical limit. Base (Coinbase’s L2) reportedly hit over 4 million daily transactions at one point , surpassing both Ethereum and other L2s. These numbers suggest that OP Stack chains can handle surges and large daily volumes. Tea Network aims for similar or better performance. If Tea were to handle all npm downloads as on-chain events (just a hypothetical huge load), it would likely need further scaling (L3s or sharding), but for now it can handle the foreseeable scale of direct user interactions in OSS funding, which are likely thousands to tens of thousands of transactions per day in early growth, scaling to maybe hundreds of thousands with widespread adoption – well within OP Stack capacity.\n\n• State Growth and Storage: With many transactions, the state (accounts, contracts, storage) will grow. Tea must manage this to keep nodes runnable. Luckily, Optimism’s design and Ethereum’s upcoming improvements (like Verkle trees) are focusing on state efficiency. Since Tea deals with lots of small accounts (many users staking, many projects), the state could grow in number of accounts. However, storage per account is small (balance, maybe a few records of stakes). Regular state rent or pruning might not be needed early, but this is something to monitor. If needed, Tea governance could implement measures like inactivity cleanup (e.g., if a project is unmaintained and has zero stake for a year, archive its state to a cheaper storage). These are long-term considerations to keep performance optimal.\n\n### Scalability Path:\n\n• Layer 2 and Beyond (Layer 3?): If Tea Network becomes extremely popular, one can imagine deploying Layer 3 instances for certain purposes. Optimism’s vision of a Superchain and even “Hyperchains” suggests that one rollup can sit atop another for specific use cases. Tea could spawn a L3 specifically for handling, say, continuous integration data or large-scale testing logs, while settling summaries to Tea L2. This is speculative, but the OP Stack’s modular nature could allow Tea to be both a rollup and a host for smaller rollups. For now, Tea L2 is sufficient, but it’s good to know the architecture can scale out if needed without overwhelming a single chain’s capacity.\n\n• Horizontal Scaling via Superchain: When the Superchain matures, Tea Network might interoperate with other chains such that load can be balanced or shared. For example, if some part of Tea’s functionality (like a DeFi app for TEA tokens) works better on another chain, cross-chain calls can happen. Or multiple sequencers in a Superchain alliance could share sequencing duty across chains. This is forward-looking, but essentially, Tea’s scalability is not capped by its own chain – it’s part of an ecosystem that is scaling collectively.\n\n• EIP-4844 and Data Scaling: We’ve mentioned EIP-4844 (Proto-Danksharding). Once that is live on Ethereum (expected 2024), Tea Network will move from posting L2 data as call data to posting in ephemeral blobs. This will cut fees by an order of magnitude for L2 data and increase throughput (because Ethereum will accept more blob data per block than it would call data). This directly boosts Tea’s capacity to scale user activity without higher costs. It’s basically a scaling bonus that Tea gets by virtue of being an L2 and staying up-to-date with Ethereum improvements .\n\n### Trade-offs:\n\nNo system is without trade-offs. Key trade-offs in Tea’s design include:\n\n• Decentralization vs. Performance: Initially, Tea opts for performance (single sequencer, centralized control) to deliver a smooth user experience. The trade-off is some centralization: users have to trust the sequencer not to censor and the team to not push bad upgrades. However, this is mitigated by the security model (they can’t steal funds) and is slated to be temporary until governance and possibly multiple sequencers take over. This is a conscious trade: a fully decentralized L2 from day one could be slower to adapt and harder to coordinate. By starting with a semi-centralized model, Tea can iterate quickly and ensure the system runs well, then gradually remove trust assumptions. This is the same approach Optimism and Arbitrum took (both began centralized and are decentralizing over time).\n\n• Optimistic Rollup Assumption (vs. ZK Rollup): Tea chose to use an optimistic rollup (fraud proofs) rather than a zero-knowledge rollup (validity proofs). The trade-off here is finality time vs. compatibility. Optimistic rollups like Tea’s are fully EVM-compatible and can leverage Ethereum’s existing tools easily, but they have the 7-day withdrawal period for security . ZK rollups have near-instant finality (no challenge period needed if proofs are valid) and potentially even better throughput, but EVM-compatible ZK rollups are still emerging and are more complex. Tea’s choice means that users withdrawing assets must wait or use liquidity providers to fast-exit (likely some third-party service can offer instant liquidity against a fee for those who can’t wait). It also means the protocol deals with the slight risk and inconvenience of fraud challenges. The benefit is that Tea could launch sooner and with full Ethereum compatibility. In the future, should ZK tech mature, Tea could consider migrating or incorporating ZK proofs (maybe to verify parts of the state like the correctness of reward calculations). But that’s a big undertaking; for now, optimistic was the pragmatic choice.\n\n• Data Availability vs. Cost: Tea, like all rollups, currently posts all transaction data to Ethereum for availability. This ensures the strong security but comes at a cost (L1 gas fees for that data). There’s a trade-off possibility: Validium or Alt-DA – not chosen here, but to note, some L2s consider not posting all data on-chain to save cost, at the expense of requiring trust for availability. Tea has not chosen that; it stays a true rollup with data on-chain (especially since trusting a third-party for data would undermine the trustless OSS reward principle). So Tea pays higher cost for better security. With Ethereum scaling (like data shards), this trade-off will become easier as data on-chain gets cheaper.\n\n• State Size vs. History Accessibility: To keep performance high for node runners, Tea might not indefinitely keep every historical transaction accessible in a fully synced node (similar to how Ethereum clients prune history or how Arbitrum compresses it). The full data is always in Ethereum logs, but an L2 node might prune older blocks. This trade-off between node efficiency and history can be managed by relying on services (like The Graph or archive nodes) for those who need history, while standard nodes keep state small for fast syncing. The OP Stack already supports different modes (full vs. archive). This is a minor trade-off, but relevant for developers: if you query a Tea node for a 2-year-old event, it might require an archive node or reconstruct from L1.\n\n• Complexity of Novel Features: The GPG precompile and account abstraction add complexity not present in a vanilla rollup. This is a trade-off: more functionality vs. potential new attack surface or performance overhead. For instance, verifying a GPG signature is more expensive in CPU terms than an ECDSA signature (which is baked into Ethereum already). If overused, could the GPG precompile slow block processing? The team likely benchmarked this; modern CPUs can verify many RSA or Ed25519 signatures per second, so unless every transaction uses a huge key, it should be fine. The trade-off was deemed worth it to get the identity functionality. But the team will monitor performance – if, say, GPG verification becomes a bottleneck, they might restrict how often it can be called in one block (like a gas cost tuning) or encourage batching of operations. It’s a conscious trade: adding that feature gives up some simplicity and raw speed, but provides a feature critical to Tea’s goals.\n\n• Economic Trade-offs: On tokenomics side, there’s a security trade-off: using TEA as gas vs. ETH as gas. Most L2s like Optimism/Arbitrum use ETH, meaning if ETH’s price is stable, security is inherited directly by economic value. Tea uses TEA for gas, which could be more volatile and initially less valuable than ETH. If TEA were ever to become too cheap, spamming the network might be easier (though there are still capacity limits). The team will calibrate gas price (which can be pegged in terms of TEA vs. cost to post on L1) to prevent that. Also, by requiring fees to be at least the L1 cost share, it inherently can’t be cheaper to spam than the cost on Ethereum. So, the trade-off of using the project’s own token for gas is gaining token utility but losing the direct link to ETH’s security budget. This is mitigated as described and by the fact that TEA will presumably correlate with network usage – if usage (and thus potential spam) rises, demand for TEA rises, possibly increasing its price and making spam expensive in fiat terms.\n\n### Summary of Improvements vs Original Implementation:\n\n• Throughput: from tens of tx/day (dApp limited by user willingness to pay fees) to potentially millions of tx/day.\n\n• User Cost: from dollars per interaction to cents or less.\n\n• Speed: from minutes (if waiting multiple block confirmations on L1) to seconds on L2.\n\n• Development Agility: from being constrained by Ethereum upgrades to being able to implement custom features (like GPG, new EIPs) on Tea’s own schedule.\n\n• Scaling Ceiling: previously bounded by Ethereum’s throughput, now bounded by a much higher threshold, and extensible via L3 or cross-chain if needed.\n\nTrade-offs Recap (Performance vs Security/Decentralization):\n\nTea Network carefully balances these:\n\n• It accepts the 7-day finality lag to get EVM compatibility (optimistic rollup).\n\n• It temporarily accepts centralization to get a workable network quickly, planning to remove that centralization in stages.\n\n• It adds new features at the cost of complexity, but ones that align with its mission (account abstraction with GPG).\n\n• It relies on Ethereum for ultimate security, meaning it cannot go beyond Ethereum’s base layer limits in some aspects (e.g., if Ethereum is congested, posting batches might get delayed or costlier; but Ethereum upgrades will alleviate that).\n\nUsers and developers should be aware of these trade-offs. For most, the benefits (vastly lower fees, faster UX) will far outweigh the downsides (waiting a week to withdraw, which can be handled via third-party bridges if urgent, or slight centralization in beta). The design choices were made to ensure the Tea Network can scale to support a global community of developers and millions of micro-transactions, all while maintaining the integrity and security that users expect from an Ethereum-aligned chain.\n\n### Conclusion and Strategic Vision\n\nThe evolution of the Tea Network from a dApp to an OP Stack-based Layer 2 marks a pivotal step toward fulfilling the project’s mission: to create a sustainable, incentive-aligned ecosystem for open-source software development. In this concluding section, we summarize the key improvements introduced by the Layer 2 transition, outline the long-term vision for the Tea Network, and present a roadmap for future development and expansion.\n\n### Key Improvements of Transitioning to Layer 2:\n\n• Scalability & Cost Efficiency: By moving to an Ethereum rollup, Tea Network achieves scalability on par with leading L2s, enabling high-volume usage at minimal cost. This directly addresses the pain points developers faced using the L1 dApp (high fees, limited throughput). Now, casual users can engage with the protocol (vote, tip, stake) without economic second thoughts, and large communities can use Tea for everyday coordination. The improved cost efficiency means more of the value stays with developers rather than being burned in fees, aligning with Tea’s goal to maximize rewards to OSS contributors .\n\n• Enhanced Security Model: The new architecture leverages Ethereum’s security guarantees and introduces cryptographic identity verification (GPG precompile) that was not possible in the original implementation. Security is now multi-layered – Ethereum secures the ledger, and PGP keys secure individual user actions, greatly reducing the risk of malicious activity either at the network level or user account level. The one-honest-validator security model provides strong assurances even under adverse conditions .\n\n• Richer Functionality (Account Abstraction): The integration of EIP-7702 concepts and account abstraction mechanisms mean the Tea Network can offer a modern user experience and flexible account management. The GPGWallet and the ability for EOAs to act like smart contract accounts for a transaction set Tea apart as a network innovating at the identity and UX layer. This will likely attract developers who want to build novel solutions (like custom login flows or multi-sig setups) on Tea, knowing the platform supports those natively.\n\n• Ecosystem Growth Potential: Running as an independent network gives Tea the freedom to nurture its own ecosystem of dApps and integrations. While the original tea Protocol was just one application, Tea Network can host many complementary applications—funding platforms, DAO governance tools, analytics dashboards for package health, marketplaces for services, etc. The migration thus transforms Tea from a single protocol into a platform for OSS-centric web3 activity. Comparisons can be drawn to how Base or Optimism are now home to many projects; we anticipate Tea Network will become the chain of choice for open-source communities, with network effects taking hold as more projects and users join.\n\n### Long-Term Vision:\n\nLooking ahead, the Tea Network aims to become the definitive blockchain hub for open-source software value exchange and reputation. In this vision:\n\n• Every meaningful open-source project, from a popular JavaScript library to a critical C library, would be registered on Tea Network, accruing a reputation score and financial support appropriate to its adoption through the protocol. The Tea Network would act as a global ledger of open-source contributions, where developers’ work is immutably recorded and rewarded. This could evolve into a new kind of professional profile for developers – a decentralized, verified record of one’s impact on software.\n\n• Tea Network’s governance will be largely in the hands of the community of developers and users, functioning as a digital cooperative or commons. Over time, as the network decentralizes, we envision a scenario where major decisions are made through broad consensus, and the network can even upgrade itself (through on-chain governance) to adapt to future needs of OSS or technology changes. This self-governing aspect ensures longevity; Tea can outlive its founders and become an institution of the open-source world, somewhat analogous to how Linux Foundation stewards Linux, but in a decentralized manner.\n\n• Integration with Web2 and Web3 ecosystems: The Tea Network will strive to blur the line between Web2 package ecosystems and Web3. For example, imagine package managers like npm or pip showing, in real-time, data from Tea: “this package is ranked #5 on Tea, has X TEA staked, last security audit 2 weeks ago, etc.” Moreover, web3 projects might preferentially use libraries that are Tea-verified for security (creating a sort of quality seal). Conversely, Tea might leverage web3 identity solutions (like SIWE – Sign-in with Ethereum, or Gitcoin Passport badges) to enrich its identity and trust system. The vision is an integrated loop: Web2 devs get introduced to web3 via Tea (to collect their rewards or stake on projects), and Web3 users get assurance about software via Tea’s data.\n\n• Global and Inclusive Participation: The Tea Network aims to be globally accessible. Many talented developers around the world contribute to OSS but have trouble getting financial support due to geographical or political barriers. Because Tea uses cryptocurrency and is decentralized, it can enable a global flow of value to contributors regardless of location. The long-term vision includes making the protocol easy to use even in regions with limited internet or hostile financial systems. Perhaps mobile-friendly light clients, multi-language support in interfaces, and educational efforts (teaching devs about crypto wallets, etc.) will be part of the journey to truly democratize open-source funding.\n\n• Catalyst for Open-Source Sustainability: If successful, the Tea Network could significantly change how open-source is funded. Instead of relying on donations or big companies’ benevolence, it creates a market-like mechanism where usage and dependency translate into tangible rewards . In the long run, this could encourage more people to work on open-source (knowing there’s an automated way to get rewarded) and improve software supply chain security (since well-maintained projects are incentivized). It aligns profit motive with community benefit in a novel way. The vision includes academic and industry recognition of Tea’s model, perhaps inspiring similar models in other creative domains (imagine something like Tea for scientific research or for open data – Tea itself may not do that, but it could be a template).\n\n### Future Roadmap:\n\nWhile exact timelines are subject to change, the development roadmap for Tea Network likely includes:\n\n• Mainnet Launch of Tea L2 (Phase 1): Following the incentivized testnets (Base ITN, Assam, Sepolia), the next step is the official mainnet launch of the Tea Network L2 (often code-named after another tea variety, perhaps). This includes deploying the bridge on Ethereum mainnet, launching the sequencer, and allowing users to bridge in their TEA tokens from Ethereum. In this phase, the core tea Protocol features (project registration, staking, rewards distribution) go live on L2.\n\n• Audit and Security Refinement: Early mainnet months will be closely observed. Bug bounty programs will continue to run. The team might impose conservative limits (like rate limits or lower cap on how much can be staked per project initially) as a safety measure, raising them as confidence grows.\n\n• Feature Completion (Phase 2): Some features might roll out shortly after mainnet:\n\n• The GPGWallet might be released after initial mainnet if it wasn’t ready on day 1 (ensuring wallets and tooling support it). Developer tools for using GPG keys (browser plugins or CLI tools) will be delivered so that it’s not just a backend feature but something devs actively use.\n\n• Account abstraction via ERC-4337 (UserOps) – if the team chooses to incorporate this – could be deployed to allow gassless meta transactions or smart contract wallets beyond GPGWallet. EIP-4337 compatibility would align Tea with broader Ethereum improvements in user experience.\n\n• Integration of EIP-4844 once Ethereum enables it (this could be a huge update for fee reduction).\n\n• Launch of Tea Explorer and Analytics – a custom block explorer highlighting not just raw transactions but protocol-level info (like showing project pages, ranks, etc.) would be on the roadmap to make the data accessible.\n\n• Ecosystem Development (Phase 3): Encourage third-party development on Tea:\n\n• Grants or hackathons to build things like: a decentralized front-end for browsing projects, analytical dashboards (which projects are growing fastest, etc.), cross-chain bridges specifically for TEA to various L2s or sidechains, integration plugins for GitHub or GitLab (e.g., a bot that comments on a pull request with a link to tip the contributor on Tea Network).\n\n• Work with major package managers to integrate Tea. For example, getting a mention or a badge on npm package pages linking to Tea Network data. This might require plugins or a bit of central cooperation, but even a browser extension could overlay Tea data on such pages as a start.\n\n• Possibly partner with existing funding platforms (OpenCollective, GitHub Sponsors) to see if they can use Tea as the backend or complementary platform (e.g., OpenCollective could mirror contributions on Tea or payout via TEA).\n\n• Decentralization & Governance (Phase 4): As the network stabilizes, focus on handing over control:\n\n• Set up the on-chain governance contracts, start holding votes on significant parameters or treasury allocations. This also includes launching the TEA token airdrop/distribution widely if not already (to ensure broad community ownership).\n\n• Gradually decentralize the sequencer: either by opening it up to whitelisted community-run sequencers or adopting a protocol for multiple sequencers. Possibly implement the fault prover mechanism for anyone to submit fraud proofs permissionlessly (initially it might have been limited to whitelisted addresses to avoid spam proofs; later open it fully as Arbitrum has done, albeit Arbitrum still has a whitelist currently ).\n\n• Expand the Security Council or similar multi-sig to include elected community members (if early on it was just core team members).\n\n• Interoperability (Phase 5): Once part of the Optimism Superchain (if Tea opts into that ecosystem formally), work on interoperability:\n\n• Enable shared sequencing or fast message passing between Tea and other OP Stack chains. For instance, allow a smart contract on Optimism or Base to directly query Tea for a project’s teaRank. This could lead to cross-chain applications (like a DeFi protocol on Optimism giving better terms to projects with high teaRank by reading from Tea).\n\n• Potentially explore a ZK-proof-of-contribution: This is speculative, but as ZK tech improves, Tea might implement zk-SNARKs to prove some statements (like proving a user has a certain reputation without revealing who they are). This would be cutting-edge and not necessary for functionality, but could enhance privacy and even allow interesting use cases like anonymous contributors still getting fair rewards (by proving work done without identity).\n\n• Global Outreach and Adoption (Phase 6): Non-technical but crucial: drive adoption in the global OSS community. This might involve:\n\n• Working with open-source foundations (Apache, Eclipse, etc.) to onboard their projects to Tea.\n\n• Outreach in emerging markets where devs could significantly benefit from earning in TEA.\n\n• Ensuring legal and accounting frameworks exist for organizations to interact with Tea (like companies writing off TEA donations as expenses).\n\n• Possibly integration with academia (imagine university open-source projects using Tea for students to get token rewards – bridging educational incentives with real-world ones).\n\nTo conclude, the transition to a Layer 2 has positioned the Tea Network as a scalable, secure, and feature-rich infrastructure ready to support a new paradigm for open-source development. It combines the strengths of Ethereum’s Layer 2 innovations (like Optimism’s OP Stack, EIP-4844, account abstraction) with a clear focus on solving real problems in the OSS world (developer incentives and software supply chain security). The white paper has outlined how each component – from the GPG address precompile to the tokenomics – serves the overarching goals of the network.\n\nThe journey ahead will involve executing on the vision, onboarding a vibrant community, and continuously improving the technology in tandem with Ethereum’s evolution. With the solid foundation laid out in this document, the Tea Network aspires to become the definitive reference and platform where open-source code meets open finance. Just as the introduction of Git revolutionized collaboration in code, we anticipate that the Tea Network can revolutionize collaboration in value – ensuring that those who create the tools powering the digital world are fairly recognized and rewarded.\n\nReferences and Comparative Implementations: Throughout this paper, we have referenced the designs of major Layer 2 networks like Optimism, Arbitrum, and Base, which provided valuable insights into scalability and governance best practices. We have cited relevant Ethereum Improvement Proposals (such as EIP-7702 for account abstraction ) and research on rollup security models to justify our architectural choices. These references underline that Tea Network is built on the cutting edge of blockchain technology, while also tailoring it in innovative ways for the open-source domain. The appended citations serve as a resource for those who wish to delve deeper into the technical or academic background of our design decisions.\n\nIn closing, the Tea Network’s transition to Layer 2 is not an end but the beginning of a new chapter. Armed with an authoritative architecture and a passionate community of developers, it is poised to scale new heights. The success of this endeavor could mean a future where open-source developers around the globe can sustainably build and maintain the software that everyone relies on, powered by a decentralized network that truly values their contributions.\n\n<br>\n\n## Tea Network Whitepaper (Expanded)\n\n### Technical Architecture – OP Stack Implementation\n\nTea Network’s protocol is deployed on an Optimism Stack (OP Stack) based Layer-2 blockchain. This architecture leverages Ethereum (Layer-1) for security and uses an Optimistic Rollup chain for Tea’s core operations. By building on the OP Stack, Tea gains high throughput and low-cost transactions while inheriting Ethereum’s security guarantees . In practice, the Tea Network functions as an application-specific rollup chain: Tea’s decentralized registry, staking mechanisms, and reward contracts run on a dedicated OP Stack chain, with state checkpoints and fraud proofs anchored to Ethereum. This design aligns Tea with the Optimism Superchain vision, where multiple L2 chains share a common development stack and interoperability standards .\n\nIn Tea’s OP Stack architecture, the Execution Layer (an EVM-equivalent client) processes Tea transactions and smart contracts (project registrations, treasuries, staking, etc.), while the Consensus Layer (the rollup client) orders transactions and submits batched proofs to Ethereum. A set of privileged L2 roles – notably a Sequencer, Batcher, and Proposer – initially operated by the Tea network maintainers, manage block production and state submission to L1 . Over time, these roles will decentralize to community-run nodes to increase trustlessness. User interactions (like project staking or bounty payouts) occur on the Tea L2 chain with near-instant finality, and periodic state roots are posted to Ethereum for security. If an invalid state is detected, the Optimistic Rollup fraud-proof system allows challengers to dispute it, ensuring Tea’s L2 remains honest.\n\nBridge mechanisms connect Tea’s L2 with Ethereum and other chains. An L1–L2 Token Bridge enables TEA tokens and other assets to move between Ethereum mainnet and the Tea network. This means participants can stake on Tea’s chain or receive rewards there, and later withdraw assets back to Ethereum via the standard Optimistic bridging process (with a challenge period for security). The OP Stack’s modular design also makes Tea’s chain inherently interoperable with other OP-based chains. As a result, Tea Network can eventually become part of the wider Optimism Superchain, allowing seamless interactions and shared liquidity with other Layer-2 networks. This interoperability and reliance on battle-tested Ethereum tech ensure the Tea Protocol’s infrastructure is robust and future-proof.\n\nOverall, using an OP Stack L2 gives Tea Network a reliable, Ethereum-aligned foundation. It preserves an immutable ledger of open-source contributions and rewards, with Ethereum finality, while enabling the custom logic (like Proof of Contribution and Tea-specific governance) to run efficiently at Layer-2. The architecture can evolve as Optimism’s stack matures – for instance, integrating upgrades like fault proofs or off-chain data availability – without compromising compatibility. In summary, Tea’s OP Stack implementation provides the scalability, security, and composability required to support a global ecosystem of open-source developers and their tokenized communities on the Tea Network.\n\n### Application Layer – Brew.fun Launchpad for Open-Source Projects\n\nBrew.fun is Tea Network’s decentralized launchpad platform designed to help open-source projects create and distribute their own tokens, using the reputational metric teaRank as a gatekeeper. In the Tea protocol, each registered project is assigned a dynamic score called teaRank based on its contribution to the open-source ecosystem. Brew.fun leverages this by allowing only repositories with sufficiently high teaRank (i.e. well-regarded, impactful projects) to conduct token launches on the platform. This eligibility criterion ensures that the launchpad hosts verified open-source projects with proven value, aligning tokenization with genuine software merit.\n\nOn Brew.fun, a project’s token launch follows a bonding curve mechanism to determine token price and distribution. During the launch phase, supporters can purchase the project’s tokens directly through a smart contract that implements a bonding curve. As more tokens are bought, the price automatically increases along the curve, preventing sudden large purchases from unfairly seizing supply. This approach creates a fair price discovery process and continuous token liquidity, as the bonding curve contract itself acts as an automated market maker . The launch concludes once a predefined point on the bonding curve is reached – for example, when a target raise amount or token supply threshold is met. At that moment, the bonding curve sale is considered complete (the project has “reached its bonding curve” target).\n\nFigure: A simple linear bonding curve example – token price increases as supply is bought. Brew.fun utilizes bonding curve mechanics to ensure fair token distribution and liquidity from the moment of launch .\n\nReaching the bonding curve target triggers Brew.fun’s automatic liquidity provisioning for the new token. Brew.fun is integrated with Velocitea, Tea Network’s on-chain exchange powered by Velodrome’s technology. Velodrome Finance is a next-generation AMM (automated market maker) known as the central liquidity hub of the Optimism network . Using a customized instance (nicknamed “Velocitea”), Brew.fun takes the funds raised and the remaining token supply and creates liquidity pools on the exchange immediately when the sale ends. In practice, Brew.fun contributes a portion of the raise (often in TEA or ETH stablecoins) and an equivalent value of the project’s new tokens into a liquidity pool on Velocitea. This automatic LP provisioning means that from day one, the project’s token has a market with deep initial liquidity, allowing supporters to trade the token with minimal slippage.\n\nBy acting as an on-chain market maker for supported projects, Brew.fun ensures a stable launch for community value tokens. Projects don’t need to worry about arranging exchange listings or liquidity – Brew.fun’s protocol smartly handles it, mitigating volatility and guarding against the extreme price swings often seen in new token launches. Brew.fun, through Velocitea (built on Velodrome’s proven AMM model), continuously supports the market for the token post-launch, facilitating healthy price discovery and trading activity. The new project token can also benefit from Velodrome’s liquidity incentive model (veVELO gauges), potentially attracting more liquidity providers over time.\n\nThe vision for Brew.fun is to onboard both well-known and emerging open-source projects – as long as they have high teaRank and a committed community – and assist them in building sustainable token economies. “Sustainable” in this context means that the token isn’t merely a speculative asset, but is integrated into the project’s growth (for example, used for governance or to reward contributors). Brew.fun provides tooling for project maintainers to design their tokenomics (such as setting aside a portion of tokens for future contributor rewards or treasury) and to equip their supporters. This includes features like vesting schedules for team tokens, community airdrops via the Tea protocol, and integration with Tea’s package registry (linking token holder governance with the project’s open-source package governance).\n\nBy prominently positioning Brew.fun in the Application Layer of the Tea ecosystem, the Tea Network expands beyond core protocol rewards into the realm of community-driven tokenization. Brew.fun serves as a bridge between the reputation earned via Tea’s Proof of Contribution and real economic opportunities for projects: once a maintainer has proven their project’s value (high teaRank), they can leverage Brew.fun to rally community funding and involvement through a token launch. This synergy ensures that financial value flows to projects that truly contribute to open-source, aligning incentives across developers, contributors, and users. Brew.fun’s launchpad ultimately strengthens the Tea Network by bringing in new participants, fostering project communities around tokens, and demonstrating a tangible pathway for open-source maintainers to be rewarded and supported by their user base.\n\n### GitHub Integration – Bountea Bounties and GPG Wallets\n\nThe Tea Network’s reward mechanisms extend into developer workflows via Bountea, a GitHub add-on that integrates Tea wallets for frictionless bounty payouts on code contributions. Bountea is designed to fund open-source development tasks (issues, bug fixes, feature implementations) by linking GitHub’s issue tracking with Tea’s value transfer capabilities. It provides a streamlined workflow for bounties: anyone can attach a TEA token reward to a GitHub issue or pull request, and when a developer resolves the task, the reward is automatically distributed through the Tea Network.\n\nHow Bountea Works: Open-source projects first register for the Bountea program by installing the Tea GitHub add-on in their repository and configuring a Tea payout address (which can be the project’s Tea treasury or maintainer’s wallet). Once enabled, project maintainers or community members can create bounties on any GitHub Issue by specifying an amount of TEA (or a project-specific token launched via Brew.fun) as a reward. This bounty offer is recorded on-chain or in a linked off-chain service escrowed by the Tea Network. Contributors discover these bounties while browsing issues – Bountea marks eligible issues with a badge indicating the reward.\n\nA developer who wants to claim the bounty will work on the issue and submit a Pull Request with the fix or feature. Crucially, Bountea uses GPG signature verification on commits to link contributors to their wallet identities. When the developer commits code, they sign their commits using their GPG key, which GitHub marks as a verified signature . The Tea GitHub add-on maps this GPG public key to the contributor’s Tea wallet (Bountea provides developers a tool to generate a Tea wallet linked to their GPG key – essentially a smart contract wallet controlled by that GPG identity ). This means that the act of signing the commit with GPG not only verifies authorship but also proves control of a corresponding Tea wallet.\n\nOnce the Pull Request is reviewed and merged by the maintainers, Bountea’s backend detects the merge event and the associated GPG signatures. The bounty reward is then automatically transferred: 85% of the bounty amount goes to the contributor’s Tea wallet, and 15% is routed to the project’s Tea treasury (or maintainer’s address) as a reward for maintaining the project and facilitating the contribution. This 85/15 split strikes a balance between incentivizing individual contributors and sustaining the overall project. By awarding 15% to maintainers, Bountea acknowledges the project’s ongoing stewardship – funds that can be used for further development or to reward other contributors.\n\nMany usage scenarios are supported without requiring extensive upfront setup. For instance, even if a project hasn’t formally registered with Bountea, a third-party (like an enthusiastic user) can still post a bounty on an issue of that project. In such cases, the Tea Network will escrow the offered tokens and hold the maintainer’s portion until the project opts into the system or a grace period elapses. This ensures funding can flow to any OSS project organically – developers can start fixing issues and earning bounties, motivating project owners to join Tea to claim their share and formally support their contributors. It lowers the barrier for projects to receive outside help, since anyone can propose a financial reward for solving a problem they care about.\n\n### Bountea Workflow (Task Funding and Payout):\n\n1\\. Bounty Creation: A sponsor (project maintainer or community member) creates a bounty by commenting on a GitHub issue (e.g. /bounty 100 TEA) or via the Bountea UI, specifying the reward amount. The bounty details are recorded and the funds (100 TEA in this example) are locked in the Tea Network’s bounty contract. The issue is labeled with the bounty offer for visibility.\n\n2\\. Contributor Claims and Resolves: A developer picks up the issue, signals intent (assigning themselves or commenting), and begins work. They write code to fix the issue. When ready, they open a Pull Request referencing the issue. The commits in the PR are GPG-signed by the developer, which GitHub shows as “Verified” . The add-on matches the GPG key to the developer’s Tea wallet (if the developer hasn’t linked one yet, Bountea guides them to generate a GPG-linked wallet). This step implicitly “claims” the bounty in the sense that the network knows which contributor will receive it upon completion.\n\n3\\. Review and Merge: Maintainers review the Pull Request. If the contribution meets the requirements, the PR is approved and merged into the codebase, thereby resolving the issue. When the issue is closed (or the PR merged), the Bountea smart contract is triggered to release the funds.\n\n4\\. Reward Distribution: Upon merge, the bounty payout is executed. The contributor automatically receives 85% of the reward (e.g. 85 TEA) directly to their GPG-linked Tea wallet. The remaining 15% (15 TEA) is sent to the project’s Tea treasury or maintainer’s wallet as configured. If the project has multiple maintainers, that 15% can later be split according to their own arrangements or governed by the project’s DAO. All transactions are on-chain, providing transparency – anyone can see that a given GitHub user (via their public key) received a reward for a specific contribution.\n\n5\\. Fallbacks and Unclaimed Bounties: If a bounty is not resolved within a certain time or if the project maintainers reject the contribution, the bounty poster can retract the funds or extend the deadline. If a project was not registered and a bounty was completed, the contributor still gets 85%. The 15% maintainer portion is held. Later, if the project maintainer joins Tea and claims it (proving ownership of the repo, possibly via a commit signature or repo verification), they receive those accrued maintainer rewards. Otherwise, after a long period, unclaimed maintainer portions might be recycled back to the bounty fund or DAO treasury to fund other public goods.\n\nThe Bountea system introduces a robust task-based funding workflow directly into developers’ existing tool (GitHub), turning issues into actionable, incentivized tasks. By using GitHub’s verified commit signatures as an identity layer, it avoids the need for contributors to switch contexts or create new accounts – their GitHub identity is their Tea Network identity (a concept enabled by cryptographic signatures). This secure linkage is made possible by GPG keys, which provide a cryptographic proof of authorship. Since the Tea Network can trust a GPG signature as confirmation that a specific GitHub user (and thus a specific Tea wallet) made a contribution, value transfer can be automated with confidence and without manual intervention.\n\nBountea not only provides a way for developers to earn immediate rewards for specific work but also creates an economy around open issues, encouraging faster problem resolution. Maintainers benefit by seeing their project improve and by receiving a fraction of each bounty, aligning incentives so that they welcome outside contributions. In cases of security fixes or critical bugs, external entities (companies relying on the project, for instance) could post sizable bounties, knowing the Tea Network will handle fair payout distribution once fixed.\n\nBy integrating Bountea into the Tea Network’s application layer, Tea extends its core philosophy (“rewarding open-source contributions”) into day-to-day development practice. It complements the base protocol’s automatic token rewards (from Proof of Contribution) with user-directed rewards for targeted tasks. This dual approach covers both broad, ongoing project value (via teaRank rewards) and granular, one-off improvements (via bounties). The result is a more complete ecosystem of incentives: maintainers earn through protocol rewards and bounty facilitation, while developers anywhere in the world can get paid in tokens for solving issues, all without leaving the familiar GitHub environment. Bountea transforms GitHub into a gateway for value transfer, empowering open-source developers to sustain their work through a decentralized, permissionless bounty marketplace.\n\n### Staking and Reward Distribution Mechanisms\n\nOne of Tea’s fundamental innovations is how it distributes rewards across the dependency graph of open-source projects, ensuring every contributor in the chain of software gets their fair share. In the Tea Network, token rewards flow from top-level projects down through all their dependencies, guided by the teaRank algorithm and staking by supporters. The overall mechanism works as follows:\n\n• Project Registration & Treasury: When a package maintainer registers an open-source project on the Tea Network, the protocol creates a unique on-chain treasury contract for that project . This treasury will receive that project’s allocated rewards over time. Upon successful registration, if the project’s teaRank exceeds a governance-defined threshold, the project becomes eligible for Proof of Contribution (PoC) rewards . The protocol begins distributing TEA tokens to the project’s treasury on a regular schedule, proportional to its teaRank and usage in the ecosystem.\n\n• Supporter Staking: Open-source project supporters (who may be end users, companies, or fans of the software) can stake their TEA tokens on projects they believe in. Staking is a way to vouch for a project’s quality and security – supporters “lock” TEA in the project’s contract, which yields them influence and a share of rewards. Every staked token yields a non-transferrable governance token (stTEA) for the supporter, representing voting power in Tea’s governance (and potentially in project-specific governance if applicable). Project supporters are incentivized because a portion of the Tea protocol’s emissions is allocated to stakers of projects, and by staking on a project, they receive a cut of that project’s reward flow.\n\n• Reward Cascades Through Dependencies: When a project (say a popular framework) receives TEA token rewards, it doesn’t keep all of it. Tea’s protocol uses the dependency graph to cascade rewards to the libraries and modules that project depends on. For example, if project A depends on library B and C, then B and C will receive a portion of A’s reward (in addition to their own direct rewards) commensurate with their impact (teaRank relationship) in A’s functionality. Those in turn pass a share down to their dependencies, and so on recursively . This creates a flow of value from the top of the dependency tree to the very bottom. Foundational projects that underlie many others accumulate rewards from all downstream usages. In essence, Tea’s token distribution algorithm ensures that all components of a software stack are rewarded for their contribution, not just the application at the top .\n\n• Steeping and Dynamic Adjustment: The process of distributing rewards down the dependency graph is sometimes referred to as “steeping” (an analogy to tea brewing). The algorithm dynamically adjusts how much each dependency gets based on factors like how critical the dependency is and how many other alternatives exist. If a dependency becomes outdated or replaced, its teaRank (and thus its reward share) will decay, and rewards will re-route to the new preferred dependencies. Supporters can also reallocate their staked tokens if projects fall out of favor. This dynamic system means reward distribution continually reflects the current state of the ecosystem’s usage and trust.\n\n• Treasury Utilization: Each project treasury receiving rewards can be managed by the maintainers. Maintainers are required to stake a portion of their project’s rewards back into the project as a signal of their commitment to its health. This increases their project’s security stake (and gives them more governance weight via stTEA) and aligns their interests with the network. Treasuries can also be used to pay for project needs: maintainers might use some funds to sponsor Bountea bounties for their project, fund development tools, or hold tokens for future staking rewards. If maintainers abandon a project, governance can vote to halt its rewards and potentially transfer the treasury to a new maintainer (or the project’s fork), to ensure continuity.\n\nThe outcome of these mechanisms is a more sustainable and fair reward system for open-source. Instead of only high-profile projects getting funding, even a small utility library maintained by a lone developer can earn continuous rewards if it is widely used (because larger projects channel a portion of value to it). This addresses the “tragedy of the commons” in software dependencies, where critical low-level components are often overlooked. Tea’s staking model also introduces accountability: supporters who stake on a project are financially invested in its security and quality, and tea tasters (expert reviewers) stake and risk their tokens to validate a project’s releases . If a project turns malicious or low-quality, those stakeholders lose reputation or funds, creating strong disincentives for bad actors.\n\nFrom a token flow perspective, the Tea protocol draws from a reserved pool of TEA (the Ecosystem & Governance allocation, which was about 21.851.4% of the supply ) to continuously emit rewards to projects and their supporters over time. The distribution curve is predefined and will span decades, gradually releasing tokens as the open-source ecosystem grows . This means early on, rewards per project might be small, but as more projects onboard and overall contributions increase, the system can scale up the incentives while adhering to the long-term emission schedule.\n\nIn summary, Tea Network’s staking and reward distribution mechanism ensures value flows to where value was created in the software supply chain. By combining algorithmic reward allocation, community staking, and dynamic adjustments, Tea creates a self-sustaining cycle: valuable projects attract supporters and rewards, which enables further development and security for those projects, which in turn benefits all dependents and the broader community. It’s a holistic approach to funding open-source, treating the ecosystem as an interconnected graph rather than isolated silos.\n\n### Governance Structure and Voting Process\n\nTea Network is governed as a decentralized protocol, with decisions influenced by those who contribute value and stake their tokens. The governance structure centers on the TEA token and its derivative, stTEA. When participants stake TEA, they receive stTEA (staked TEA) at a 1:1 ratio. stTEA cannot be transferred or traded; it represents one’s voting power in Tea’s governance system. In addition, the protocol may factor in a user’s reputation (built from contributions, successful reviews as a tea taster, etc.) to weight votes, so that active, proven contributors carry more influence .\n\nGovernance of Tea is conducted through a proposal and voting process, often likened to a DAO (Decentralized Autonomous Organization). Active contributors who hold stTEA can propose changes to the protocol’s parameters, upgrades, or other governance actions . For example, proposals might include adjusting the teaRank threshold for project rewards, changing the bonding curve parameters on Brew.fun, allocating treasury funds for grants, or electing community members to specific roles. Each proposal typically requires a certain minimum support (e.g., a proposer must have X stTEA or a group of supporters) to be formally submitted, ensuring the system isn’t spammed with low-quality proposals.\n\nOnce a proposal is submitted, it enters a voting period where all stTEA holders can vote for or against (or abstain). Votes are weighted by the amount of stTEA (and potentially modulated by reputation scores to encourage merit-based governance). The Tea governance smart contracts tally votes and determine the outcome based on predefined rules – for instance, a simple majority of votes cast, with a quorum requirement (minimum percentage of total supply voting) for validity. Because Tea’s community includes different stakeholders (maintainers, supporters, tasters, advisors), this on-chain voting ensures every faction with a stake has a say in the protocol’s evolution proportional to their contribution and investment in the system.\n\nIf a proposal passes, the changes are enacted. Many governance decisions are automated via smart contracts: for example, a vote to change a system parameter (like reward emission rate or bounty split ratio) can trigger the contract to update that parameter. More complex decisions, such as upgrading the Tea core protocol, might go through a timelock contract after a successful vote, giving a window for review or potential veto if a vulnerability is discovered. In all cases, transparency is paramount – proposals and votes are recorded on-chain, and discussion typically occurs in public forums (such as Tea’s community governance forums or Discord) before and during the voting period.\n\nThe governance structure starts relatively simple – the core Tea team might bootstrap it with an initial set of parameters and the community voting mainly on non-critical issues – and progressively decentralizes as the network matures. Early on, certain “guardrails” exist: some protocol parameters are not immediately subject to governance to avoid attacks or instability . For example, security-critical settings or emergency shutoff mechanisms might be under a multi-sig control or require a higher governance threshold. Over time, as the community grows and proves capable, these controls are handed over to full on-chain governance (a process sometimes called a “progressive decentralization”). The aim is to balance stability with open governance: the system gradually opens up more decision-making to token holders as confidence in the governance process solidifies.\n\nGovernance voting flow typically works like this (illustrative diagram of process): A community member drafts a proposal -> other members discuss and signal support (off-chain) -> the proposal is formally submitted on-chain (if it meets submission criteria) -> stTEA holders vote during an open window (e.g., 7 days) -> after voting, if quorum and majority are met, the proposal is queued for execution -> after any timelock, the proposal’s changes execute on-chain, updating the protocol. If the proposal fails (insufficient votes or voted down), it is dropped and has no effect.\n\nThe Tea Network’s governance also oversees the DAO Treasury (which accumulates fees or undistributed tokens). For instance, the 21.8% “Ecosystem & Governance” token allocation , which is used for rewards and community initiatives, is effectively managed by governance. The community could vote to use some treasury tokens for grants to important open-source projects, to fund hackathons, or to provide additional liquidity to Velocitea if needed. They can also vote on protocol upgrades – as Tea evolves, technical improvements or even migrations to new technology (say, integrating a ZK-rollup for faster finality in the future) would be subject to governance approval.\n\nTea’s governance model is designed to be inclusive of all contributors: package maintainers, through their staked rewards, have a voice; project supporters who stake on projects have a voice; tea tasters building reputation have a voice; and early backers and advisors (holding tokens) also participate. This mix ensures no single group monopolizes control. The weighting by stake and reputation aims to prevent purely monetary whales from overruling the expert community, while still requiring that voters have skin in the game (you must stake value to influence decisions).\n\nIn conclusion, the governance of Tea Network is a critical component that keeps the protocol adaptable and community-driven. By enabling token holders and contributors to propose and vote on changes, Tea ensures that the system can evolve in response to the community’s needs and the ever-changing landscape of open-source software. This on-chain governance, combined with the economic incentives and safeguards (like slashing for malicious actions, and rewarding positive contributions), creates a resilient structure. It puts the future of the open-source funding protocol in the hands of those who use and contribute to it, fulfilling the decentralized ethos at the heart of Tea Network.\n\n<br>\n\n### Acknowledgments\n\nThis white paper would not exist without the support and dedication of many teaophiles. The authors would like to acknowledge Jacob Heider, Jadid Khan, Josh Kruger, and Shane Molidor for their contribution to the tokenomics, Sanchit Ram for his contribution to the teaRank algorithm, and the many discrete individuals who volunteered their time to provide feedback on the contents of this document.\n\n### Glossary of Terms\n\n| Term     | Definition                                                                                                                                                                                        |\n| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Slashing | The action of penalizing stakers in response to behavior contrary to the protocol rules.                                                                                                          |\n| Staking  | The action of locking TEA tokens to support your claim and receive rewards (or penalties) based on the consensus on the validity of your claim.                                                   |\n| stTEA    | Non-transferrable “staked TEA” token or “stTEA” received by network participants for each token staked at a 1:1 ratio. stTEA can be utilised to participate in the governance of the tea Protocol |\n| teaRank  | Dynamic impact score assigned to each project by the protocol’s “Proof of Contribution” algorithm.                                                                                                |\n\n## References\n\n1. [https://creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/)\n2. [https://archive.org/details/historyofmodernc00ceru](https://archive.org/details/historyofmodernc00ceru)\n3. [https://nvd.nist.gov/vuln/detail/CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228)\n4. [https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA](https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA)\n5. [https://twitter.com/yazicivo/status/1469349956880408583](https://twitter.com/yazicivo/status/1469349956880408583)\n6. [https://www.thestack.technology/core-js-maintainer-denis-pusharev-license-broke-angry/](https://www.thestack.technology/core-js-maintainer-denis-pusharev-license-broke-angry/)\n7. [https://www.w3.org/TR/did-core/](https://www.w3.org/TR/did-core/)\n8. [https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/](https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/)\n9. [https://www.theregister.com/2016/03/23/npm\\_left\\_pad\\_chaos/](https://www.theregister.com/2016/03/23/npm_left_pad_chaos/)\n10. [https://fossa.com/blog/npm-packages-colors-faker-corrupted/](https://fossa.com/blog/npm-packages-colors-faker-corrupted/)\n11. [https://www.lunasec.io/docs/blog/node-ipc-protestware/](https://www.lunasec.io/docs/blog/node-ipc-protestware/)\n12. [https://github.com/dominictarr/event-stream/issues/116](https://github.com/dominictarr/event-stream/issues/116)\n13. [https://blog.npmjs.org/post/163723642530/crossenv-malware-on-thenpm-registry.html](https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry.html)\n14. [https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/](https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/)\n15. [https://threatpost.com/backdoor-found-in-utility-for-linux/147581/](https://threatpost.com/backdoor-found-in-utility-for-linux/147581/)\n16. [https://www.fbi.gov/news/stories/phantom-secure-takedown-031618](https://www.fbi.gov/news/stories/phantom-secure-takedown-031618)\n17. [https://www.europol.europa.eu/media-press/newsroom/news/800-criminalsarrested-in-biggest-ever-law-enforcement-operation-against-encryptedcommunication](https://www.europol.europa.eu/media-press/newsroom/news/800-criminals-arrested-in-biggest-ever-law-enforcement-operation-against-encrypted-communication)\n18. [https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502](https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502)\n19. [https://www.npmjs.com/package/lodash](https://www.npmjs.com/package/lodash)\n20. [https://www.npmjs.com/package/chalk](https://www.npmjs.com/package/chalk)\n21. [https://www.npmjs.com/package/log4js/](https://www.npmjs.com/package/log4js/)\n22. [https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/](https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/)\n23. [https://medium.com/intrinsic-blog/compromised-npm-package-eventstream-d47d08605502](https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502)\n24. [https://semver.org/](https://semver.org/)\n25. [https://arxiv.org/abs/1207.2617](https://arxiv.org/abs/1207.2617)\n26. [https://research.web3.foundation/Polkadot/overview/token-economics](https://research.web3.foundation/Polkadot/overview/token-economics)\n"
  }
]