Adding the Rewards Program docs

content/en/resources/rewards-program.mdx

@@ -0,0 +1,63 @@
+---
+title: Contributor Rewards
+description: "How BLOK Capital distributes $BLOKC rewards to contributors through a three-layer pipeline combining AI-driven scoring, multi-signer approval, and on-chain execution."
+position: 6
+---
+
+<img
+  src="/img/rewards.png"
+  alt="Contributor Rewards Program"
+  style={{
+    width: '100%',
+    maxWidth: '360px',
+    height: 'auto',
+    display: 'block',
+    margin: '0 auto 1.5rem'
+  }}
+/>
+
+BLOK Capital uses a structured, three-layer reward pipeline to distribute $BLOKC tokens to contributors, combining AI-driven scoring, human approval, and on-chain execution into a single trustless flow.
+
+---
+
+## Scoring and Proposal
+
+At the end of each reward epoch, an AI system evaluates contributor activity off-chain across the protocol's defined contribution categories. It then submits a distribution proposal on-chain: a list of contributor addresses paired with their $BLOKC reward amounts for that epoch.
+
+The proposal is validated by the distributor contract before being stored. If an error is detected before approval begins, the proposer can cancel and resubmit within the same epoch.
+
+---
+
+## Multi-Signer Approval
+
+AI scoring systems can hallucinate, misattributing contributions, inflating amounts, or omitting contributors entirely. The multi-signer approval layer exists specifically to catch this before any tokens move. Every designated signer independently reviews the proposed distribution and must approve it before execution can proceed.
+
+If a signer identifies an error, such as an incorrect amount, a missing contributor, or a batch that doesn't reflect the actual work done, they withhold approval. The proposal stalls, signers communicate their feedback to the AI proposer, and the proposer cancels the batch and submits a corrected one. This rejection and resubmission cycle continues until the distribution accurately reflects contributor output and all signers are satisfied.
+
+This is not a threshold multisig: every signer approves, or the distribution does not execute. The contract tracks approvals per signer and prevents double-approvals. No single entity, not the AI proposer, not any one signer, not the protocol team, can unilaterally move reward tokens. Contributors can be confident that the rewards they receive have passed a final human review, not just automated computation.
+
+---
+
+## Permissionless Execution
+
+Once every signer has approved, anyone can trigger execution. The contract performs a final validation (proposal exists, not already executed, approval count met), then transfers $BLOKC to each contributor's predicted account address in a single transaction.
+
+State is updated before transfers occur, following the checks-effects-interactions pattern to prevent reentrancy.
+
+---
+
+## Contributor Accounts
+
+Tokens go into individual contributor accounts, dedicated smart contracts deployed as ERC-1167 minimal proxy clones using CREATE2 deterministic addressing. ERC-1167 defines a minimal bytecode implementation that delegates all calls to a fixed implementation contract, making each clone cheap to deploy while sharing audited logic across all accounts.
+
+Because CREATE2 produces a predictable address from a fixed set of inputs (the implementation contract, the contributor's wallet address, and the factory address), the distributor sends tokens to that predicted address at execution time, even before the contributor has deployed their account.
+
+When the contributor later deploys their account by calling the factory, the tokens are already there. This eliminates any sequencing dependency between distribution and account setup, allowing the protocol to distribute to any number of contributors in a single transaction.
+
+---
+
+## Token Lock and Governance
+
+Tokens remain locked in the contributor account until a fixed unlock timestamp shared across all accounts. During the lock period, voting power is delegated to the contributor: locked $BLOKC counts toward governance from day one.
+
+After unlock, the contributor can withdraw a specific amount to any address, or sweep the full balance to their own wallet. No protocol involvement is required at withdrawal time.

content/es/resources/rewards-program.mdx

@@ -0,0 +1,63 @@
+---
+title: Recompensas para Colaboradores
+description: "Cómo BLOK Capital distribuye las recompensas en $BLOKC a los colaboradores mediante un proceso de tres capas que combina puntuación impulsada por IA, aprobación multi-firmante y ejecución on-chain."
+position: 6
+---
+
+<img
+  src="/img/rewards.png"
+  alt="Programa de Recompensas para Colaboradores"
+  style={{
+    width: '100%',
+    maxWidth: '360px',
+    height: 'auto',
+    display: 'block',
+    margin: '0 auto 1.5rem'
+  }}
+/>
+
+BLOK Capital utiliza un proceso de recompensas estructurado en tres capas para distribuir tokens $BLOKC a los colaboradores, combinando puntuación impulsada por IA, aprobación humana y ejecución on-chain en un solo flujo sin necesidad de confianza.
+
+---
+
+## Puntuación y Propuesta
+
+Al final de cada época de recompensas, un sistema de IA evalúa la actividad de los colaboradores fuera de la cadena (off-chain) en las categorías de contribución definidas por el protocolo. Luego envía una propuesta de distribución on-chain: una lista de direcciones de colaboradores junto con los montos de recompensa en $BLOKC correspondientes a esa época.
+
+La propuesta es validada por el contrato distribuidor antes de ser almacenada. Si se detecta un error antes de que comience la aprobación, quien propone puede cancelarla y volver a enviarla dentro de la misma época.
+
+---
+
+## Aprobación Multi-Firmante
+
+Los sistemas de puntuación por IA pueden alucinar, atribuyendo mal las contribuciones, inflando montos u omitiendo colaboradores por completo. La capa de aprobación multi-firmante existe específicamente para detectar esto antes de que se muevan los tokens. Cada firmante designado revisa de forma independiente la distribución propuesta y debe aprobarla antes de que pueda proceder la ejecución.
+
+Si un firmante identifica un error, como un monto incorrecto, un colaborador faltante o un lote que no refleja el trabajo realmente realizado, retiene su aprobación. La propuesta queda detenida, los firmantes comunican su retroalimentación al proponente de IA, y este cancela el lote y envía uno corregido. Este ciclo de rechazo y reenvío continúa hasta que la distribución refleje con precisión el resultado del trabajo de los colaboradores y todos los firmantes estén satisfechos.
+
+Esto no es un multisig por umbral: todos los firmantes deben aprobar, o la distribución no se ejecuta. El contrato registra las aprobaciones por firmante y evita las aprobaciones duplicadas. Ninguna entidad individual, ni el proponente de IA, ni un firmante en particular, ni el equipo del protocolo, puede mover los tokens de recompensa unilateralmente. Los colaboradores pueden confiar en que las recompensas que reciben han pasado una revisión humana final, no solo un cálculo automatizado.
+
+---
+
+## Ejecución sin Permisos
+
+Una vez que todos los firmantes han aprobado, cualquiera puede activar la ejecución. El contrato realiza una validación final (la propuesta existe, no ha sido ejecutada previamente, se alcanzó el número de aprobaciones requerido) y luego transfiere $BLOKC a la dirección de cuenta prevista de cada colaborador en una sola transacción.
+
+El estado se actualiza antes de que ocurran las transferencias, siguiendo el patrón checks-effects-interactions para prevenir la reentrancia.
+
+---
+
+## Cuentas de Colaboradores
+
+Los tokens se depositan en cuentas individuales de colaboradores: contratos inteligentes dedicados, desplegados como clones proxy mínimos ERC-1167 mediante direccionamiento determinista CREATE2. El estándar ERC-1167 define una implementación de bytecode mínima que delega todas las llamadas a un contrato de implementación fijo, lo que hace que cada clon sea económico de desplegar mientras comparte una lógica auditada entre todas las cuentas.
+
+Debido a que CREATE2 genera una dirección predecible a partir de un conjunto fijo de datos de entrada (el contrato de implementación, la dirección de la billetera del colaborador y la dirección de la fábrica), el distribuidor envía los tokens a esa dirección prevista en el momento de la ejecución, incluso antes de que el colaborador haya desplegado su cuenta.
+
+Cuando el colaborador despliega posteriormente su cuenta llamando a la fábrica, los tokens ya están allí. Esto elimina cualquier dependencia de secuencia entre la distribución y la configuración de la cuenta, permitiendo que el protocolo distribuya a cualquier número de colaboradores en una sola transacción.
+
+---
+
+## Bloqueo de Tokens y Gobernanza
+
+Los tokens permanecen bloqueados en la cuenta del colaborador hasta una fecha de desbloqueo fija, compartida por todas las cuentas. Durante el período de bloqueo, el poder de voto se delega al colaborador: los $BLOKC bloqueados cuentan para la gobernanza desde el primer día.
+
+Después del desbloqueo, el colaborador puede retirar un monto específico a cualquier dirección, o transferir el saldo completo a su propia billetera. No se requiere ninguna intervención del protocolo al momento del retiro.

content/fr/resources/rewards-program.mdx

@@ -0,0 +1,63 @@
+---
+title: Récompenses des Contributeurs
+description: "Comment BLOK Capital distribue les récompenses en $BLOKC aux contributeurs via un pipeline en trois couches combinant notation par IA, approbation multi-signataires et exécution on-chain."
+position: 6
+---
+
+<img
+  src="/img/rewards.png"
+  alt="Programme de Récompenses des Contributeurs"
+  style={{
+    width: '100%',
+    maxWidth: '360px',
+    height: 'auto',
+    display: 'block',
+    margin: '0 auto 1.5rem'
+  }}
+/>
+
+BLOK Capital utilise un pipeline de récompenses structuré en trois couches pour distribuer des tokens $BLOKC aux contributeurs, combinant notation pilotée par IA, approbation humaine et exécution on-chain en un seul flux sans confiance (trustless).
+
+---
+
+## Notation et Proposition
+
+À la fin de chaque époque de récompenses, un système d'IA évalue l'activité des contributeurs hors chaîne (off-chain) selon les catégories de contribution définies par le protocole. Il soumet ensuite une proposition de distribution on-chain : une liste d'adresses de contributeurs associées à leurs montants de récompense en $BLOKC pour cette époque.
+
+La proposition est validée par le contrat distributeur avant d'être stockée. Si une erreur est détectée avant le début de l'approbation, le proposant peut l'annuler et la soumettre à nouveau au sein de la même époque.
+
+---
+
+## Approbation Multi-Signataires
+
+Les systèmes de notation par IA peuvent halluciner, en attribuant mal des contributions, en gonflant des montants ou en omettant complètement des contributeurs. La couche d'approbation multi-signataires existe précisément pour détecter cela avant que des tokens ne bougent. Chaque signataire désigné examine indépendamment la distribution proposée et doit l'approuver avant que l'exécution puisse avoir lieu.
+
+Si un signataire identifie une erreur, comme un montant incorrect, un contributeur manquant ou un lot qui ne reflète pas le travail réellement effectué, il refuse son approbation. La proposition est alors bloquée, les signataires communiquent leurs retours au proposant IA, et celui-ci annule le lot et en soumet un corrigé. Ce cycle de rejet et de nouvelle soumission se poursuit jusqu'à ce que la distribution reflète fidèlement le travail des contributeurs et que tous les signataires soient satisfaits.
+
+Il ne s'agit pas d'un multisig à seuil : chaque signataire doit approuver, sinon la distribution ne s'exécute pas. Le contrat suit les approbations par signataire et empêche les doubles approbations. Aucune entité seule, ni le proposant IA, ni un signataire en particulier, ni l'équipe du protocole, ne peut déplacer unilatéralement les tokens de récompense. Les contributeurs peuvent avoir confiance que les récompenses qu'ils reçoivent ont fait l'objet d'une révision humaine finale, et pas seulement d'un calcul automatisé.
+
+---
+
+## Exécution Permissionless
+
+Une fois que tous les signataires ont approuvé, n'importe qui peut déclencher l'exécution. Le contrat effectue une validation finale (la proposition existe, elle n'a pas déjà été exécutée, le nombre d'approbations requis est atteint), puis transfère les $BLOKC à l'adresse de compte prévue de chaque contributeur en une seule transaction.
+
+L'état est mis à jour avant que les transferts n'aient lieu, en suivant le modèle checks-effects-interactions afin de prévenir la réentrance.
+
+---
+
+## Comptes des Contributeurs
+
+Les tokens sont déposés dans des comptes individuels de contributeurs : des smart contracts dédiés, déployés comme des clones proxy minimaux ERC-1167 via un adressage déterministe CREATE2. La norme ERC-1167 définit une implémentation en bytecode minimal qui délègue tous les appels à un contrat d'implémentation fixe, ce qui rend chaque clone peu coûteux à déployer tout en partageant une logique auditée entre tous les comptes.
+
+Comme CREATE2 génère une adresse prévisible à partir d'un ensemble fixe d'entrées (le contrat d'implémentation, l'adresse du portefeuille du contributeur et l'adresse de la factory), le distributeur envoie les tokens à cette adresse prévue au moment de l'exécution, même avant que le contributeur n'ait déployé son compte.
+
+Lorsque le contributeur déploie ensuite son compte en appelant la factory, les tokens s'y trouvent déjà. Cela élimine toute dépendance de séquencement entre la distribution et la mise en place du compte, permettant au protocole de distribuer à un nombre quelconque de contributeurs en une seule transaction.
+
+---
+
+## Verrouillage des Tokens et Gouvernance
+
+Les tokens restent verrouillés dans le compte du contributeur jusqu'à un horodatage de déverrouillage fixe, partagé par tous les comptes. Pendant la période de verrouillage, le pouvoir de vote est délégué au contributeur : les $BLOKC verrouillés comptent pour la gouvernance dès le premier jour.
+
+Après le déverrouillage, le contributeur peut retirer un montant spécifique vers n'importe quelle adresse, ou transférer la totalité du solde vers son propre portefeuille. Aucune intervention du protocole n'est requise au moment du retrait.