[ BLOG DA REDE PLEGMA ]

O monitor de pagamentos Polygon foi actualizado para utilizar o contrato USDC nativo (0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359), substituindo o contrato bridged anteriormente configurado. Esta correcção garante que todas as transferências USDC realizadas pelos utilizadores através da MetaMask e carteiras compatíveis são detectadas e processadas correctamente. O endereço da pool de liquidez (0xD8422d...) foi igualmente validado e confirmado como destino correcto dos 90% de cada operação Genesis.

Auditoria automatizada via orquestrador interno identificou e corrigiu uma violação da Lei de Determinismo: um gerador de identificadores não-determinístico foi substituído por derivação via BLAKE3 com âncora de estado, mantendo o protocolo 100% determinístico e pós-quântico.

Os registos de aquisição PLG-G foram reconciliados com a realidade on-chain da Polygon. Dados de desenvolvimento foram removidos do ambiente de produção. Contadores de emissão actualizados para reflectir exclusivamente transacções confirmadas: 20.0 PLG-G emitidos para 2 detentores reais.

O orquestrador identificou 6 módulos Python sem referências activas (nunca importados por nenhum ponto de entrada da rede). Os módulos foram isolados em quarentena nos 4 nós do cluster. Após 48h de operação sem alertas, serão eliminados definitivamente. Score da auditoria: CRITICAL 0 · HIGH 3 · MEDIUM 20.

O orquestrador PLEGMA foi actualizado com um motor de consenso local (validation + security + coder) que opera de forma autónoma sem dependências externas. O ritual de encerramento de sessão passa agora a correr este consenso como primeira etapa, bloqueando qualquer acção se forem encontradas violações críticas de protocolo.

A rede passa a servir exclusivamente HTTPS. Certificado TLS emitido com renovação automática para plegmadag.com, api.plegmadag.com e www.plegmadag.com. Todo o tráfego HTTP é redirecionado automaticamente para HTTPS.

Corrigido o link de navegação em três páginas da Mesh Social que exibiam "REDE" em vez de "MESH SOCIAL".

Bug na função de publicação: ao tentar publicar sem sessão activa, o modal de autenticação abria correctamente mas após o login era necessário clicar Publicar novamente. O fluxo foi corrigido — após autenticar, o post pendente é submetido automaticamente sem interação adicional.

Identificado e corrigido o bug que impedia o app de conectar à rede: o serviço de armazenamento local retornava um endereço IP interno como fallback, sobrepondo a configuração correcta do domínio HTTPS. O fallback foi corrigido para apontar directamente ao domínio da API, resolvendo o erro "rede offline" tanto em instalações novas quanto em actualizações.

Build de release compilado e validado: 75.4 MB. APK disponível em /download/plegma-v1.9.2.apk. Conectividade HTTPS via domínio confirmada — stack criptográfico 100% pós-quântico.

Todas as páginas web (landing, blog, admin, console, testnet) e o APK foram deployed ao servidor EU. API TESTNET confirmada online: 4 nós activos, 0 transacções, fase TESTNET com faucet habilitado. Directórios de download e blog criados no servidor.

Terceiro servidor (BR) identificado e acessível. Python 3.10 presente, dependências e módulos core pendentes de instalação. Próximo passo: deploy completo do PLEGMA_CORE e integração no cluster de peers.

Todas as 17 páginas do site receberam um GC Ticker — barra fixa laranja no topo com texto corrente: "⬡ FASE TESTNET ATIVA · REDE EM AMBIENTE DE TESTES · T-PLG NÃO TEM VALOR REAL · DADOS E TRANSAÇÕES SÃO FICTÍCIOS". A barra é position:fixed; top:0; z-index:99999; pointer-events:none e só activa após 09/04/2026 às 18:00 Madrid (CEST = UTC+2) — o JS verifica a hora localmente a cada minuto antes de exibir.

O link <a href="/testnet/">TESTNET</a> com badge laranja pulsante (animation: pulse-orange 1.8s ease-in-out infinite) foi adicionado ao nav de todas as páginas que possuem barra de navegação pública. Nos navs com botão DASHBOARD (index, genesis, podcast, serviços), a aba TESTNET posiciona-se imediatamente antes do botão, separada e fora do seu elemento — corrigindo um bug anterior em que o <a> havia sido injectado dentro do <button>, tornando o HTML inválido e quebrando o onclick do Dashboard em certos browsers.

Os dois cards de activação (PC e Mobile) na página /servicos/ foram substituídos por um único botão verde ATIVAR posicionado abaixo do bloco de preço. O botão usa Anime.js 3.2.1 para animação de pulso contínuo (boxShadow + scale em loop de 2,2s) e squeeze no clique. A função ativarLatticeShield() detecta o dispositivo via navigator.userAgent: em mobile tenta o deep link plegma://shield/activate e redireciona para /download/ após 1,8s caso o app não esteja instalado; em PC verifica PlegmaAuth.isConnected() e abre o modal de auth ou vai directo para /dashboard/?tab=lattice-shield.

O fluxo de autenticação offline foi reescrito. Anteriormente, quando o servidor api.plegmadag.com estava inacessível, o _startChallenge() tentava carregar a biblioteca QR do cdnjs.cloudflare.com — que também falha em ambiente completamente offline — deixando o modal travado em "GERANDO..." sem feedback utilizável. Agora o bloco catch renderiza directamente um input de texto onde o utilizador insere o endereço PLG (43 chars, prefixo PLG). O novo método público PlegmaAuth.loginOffline(plgAddress) valida o endereço e chama _onSuccess() internamente, activando a sessão, actualizando o botão Dashboard e disparando todos os callbacks onLogin — sem qualquer dependência de rede.

A função carregarSocios() no Console Mestre foi corrigida: _categoriaLabel() agora usa genesis_balance (saldo com DNA Genesis) para determinar MASTER / SENTINELA / APOIADOR — e não mais o saldo total PLG-G. Compras via P2P secundário não alteram a categoria Genesis do sócio. A simulação local de 13 sócios fictícios (usada durante desenvolvimento) foi removida — o console agora exibe apenas dados reais da API.

A seção Estado da Rede do Console Mestre recebeu 4 novos stat-card: Nós Ativos (statNosAtivos), Nós Âncora (statNosAncoras), Mineradores (statMineradores) e Validadores (statValidadores). Todos alimentados pelo endpoint GET /api/status já existente — sem nova requisição. Os dados de rede ficam atualizados no mesmo ciclo de polling do painel.

⚠️ Issue pendente: plegma_db.get_node_counts() — nos_mineradores conta VALIDATOR+PROVER juntos (deveria ser só PROVER). Card "Mineradores" exibe o total combinado até correção no backend.

Implementado o conceito de DNA do PLG-G Genesis: ao confirmar uma compra na Genesis Reserve, o sistema calcula dna = SHA3-256(plg_address) e registra o genesis_balance separado do saldo total na tabela plgg_balances (nova coluna via migration automática). O genesis_balance representa exclusivamente os PLG-G comprados diretamente na Genesis — é ele que determina o título Sócio Genesis e o estado da medalha. Ao transferir PLG-G para outra carteira, o remetente perde o genesis_balance proporcional: os tokens saem com o DNA e deixam de conferir título no destino.

O boost de mineração (1,0× / 1,5× / 2,0×) e o peso de voto continuam sendo calculados pelo saldo total de PLG-G — inclui compras no mercado P2P secundário. Esta é a principal utilidade do PLG-G para compradores do secundário.

• genesis_balance > 0 + is_genesis → medalha dourada girando · título ativo
• genesis_balance = 0 + is_genesis → medalha cinza estática · título perdido (irrecuperável)
• saldo_plgg > 0 + !is_genesis → medalha branca girando · boost ativo · sem título

Funções novas em plegma_db.py: salvar_saldo_plgg_genesis() / carregar_saldo_plgg_genesis(). check_priority() em sentinela.py agora retorna genesis_balance e saldo_plgg como campos distintos.

A deflação 1:1 por mine_tokens() (burn = min(reward, genesis_reserve)) foi identificada como erro de implementação e removida. A regra correta sempre foi: ao encerrar os 30 dias da Genesis Reserve, todo PLG-G não vendido é queimado instantaneamente via queimar_plgg_nao_vendido() — função idempotente (flag no DB impede reexecução). Simultaneamente, os campos genesis_reserve e burned_reserve foram eliminados do AerariumProtocol: não existe reserva de $PLG separada no Aerarium — o supply total vai diretamente para os pools Validator (60%) e Prover (40%). Referências removidas de aerarium.py, wallet_server.py e wallet_dashboard.py.

O gate do /console/ (senha + campo PLG manual) foi substituído pelo sistema unificado de autenticação da rede: PlegmaAuth.init({ onLogin, onLogout }). Ao abrir a página sem sessão ativa, a tela #authLock cobre o conteúdo e exibe o botão CONECTAR CARTEIRA — que abre o modal QR/Dilithium3 padrão. Ao autenticar, onLogin(plgAddress) libera o console e popula _plgAddr com o endereço da sessão. O botão ▸ acesso admin (discreto, quase invisível) permite acesso por senha local via SHA-256 — para uso sem carteira.

Logo oficial logo.gif adicionada ao header do Console Mestre ao lado do título. A seção GUIA VPS (passo a passo Azure trial + tabela comparativa de provedores) e o painel Script de Instalação do Nó foram removidos — conteúdo operacional que não pertence ao console de monitoramento.

A tabela Lista de Sócios no Console Mestre foi reestruturada: endereço PLG, saldo PLG-G e coluna "Sócio Genesis" (sim/não) removidos. A tabela agora exibe Categoria (badge MASTER / SENTINELA / APOIADOR), Título (medalha com emoji: 🥇 Sócio Genesis · Master, 🥈 Sentinela, 🥉 Apoiador, 🔵 Detentor · X) e Quantidade — agrupados. A ordem é Genesis primeiro, depois Detentores por categoria decrescente. Quando a API está offline, uma simulação local de 13 sócios é exibida automaticamente para validação visual.

O arquivo blog/index.html estava truncado (terminava no meio do CVE-007/008 sem fechar nenhuma tag HTML). Adicionado fechamento completo + footer padrão. A função switchTab(), chamada pelos botões das 3 abas, simplesmente não existia no arquivo — causando tela sem resposta ao clicar. Adicionada com suporte a navegação por URL hash (#timeline, #testes, #pilares).

O Console Mestre foi extraído para /admin/index.html como página autônoma, com gate de acesso diferenciado (tema vermelho, aviso de área restrita e link de retorno ao Console). O conteúdo é uma cópia completa do Console — as duas páginas evoluem independentemente a partir daqui, permitindo que o admin acumule funcionalidades exclusivas sem impactar a experiência do sócio.

A auditoria do aerarium.py identificou e corrigiu a regra de queima. A deflação 1:1 progressiva por mine_tokens() (burn = min(reward, genesis_reserve)) foi removida — o mecanismo estava errado. A regra correta: ao encerrar os 30 dias da Genesis Reserve, todo PLG-G não vendido é queimado instantaneamente em um único evento via queimar_plgg_nao_vendido(). A função é idempotente (flag no DB — não reexecuta). O botão "Queimar PLG-G Não Vendidos" e a função confirmarBurn() foram removidos do Console Mestre.

A rota /socio-fundador/ foi renomeada para /console/ — nome mais direto e coerente com a função da página. Referências atualizadas em admin/index.html, dashboard/index.html e neste blog.

A lista coletiva de sócios foi removida do Console do sócio. Em seu lugar, o painel STATUS SÓCIO GENESIS exibe o status individual do usuário logado: saldo PLG-G, categoria com boost de mineração, e estado do Selo Sócio Genesis — tudo carregado via GET /api/priority?address=. O gate foi atualizado para aceitar chave + endereço PLG.

A identidade visual do status Genesis foi implementada com três estados de medalha animada (rotação 3D via Anime.js, rotateY 360° contínuo):

• Dourada girando — participou da Genesis Reserve, selo ativo (genesis_balance > 0 — PLG-G com DNA ainda nesta carteira)
• Apagada/cinza estática — participou da Genesis, mas transferiu todo o seu PLG-G original para fora — irrecuperável mesmo comprando de volta via P2P
• Branca girando — nunca participou da Genesis; adquiriu PLG-G via P2P — recebe boost e peso de voto normalmente, mas sem título Sócio Genesis

A categoria e o boost (MASTER 2,0× / SENTINELA 1,5× / APOIADOR 1,0×) são calculados pelo saldo total de PLG-G — inclui compras P2P secundárias. O título Sócio Genesis é determinado exclusivamente pelo genesis_balance (DNA vinculado à carteira compradora original): ao transferir PLG-G para fora, os tokens saem com o DNA e perdem o vínculo — quem recebe não herda o título. Regra implementada em genesis_contract.py via salvar_saldo_plgg_genesis() e marcar_status_genesis_perdido().

Todos os 10 fixes da auditoria BUILD 009 foram verificados diretamente no código-fonte e confirmados como implementados. A tabela de severidade da CAMADA 12 foi limpa: indicadores 🔴 CRÍTICO, 🟠 ALTA e 🟡 MODERADA substituídos por 🟢 RESOLVIDO em todos os itens.

O canal de notas privadas foi removido inteiramente do protocolo. Código eliminado de core_vm.py (bloco de variáveis, store, lock, função de verificação e 3 rotas GET/POST/limpar) e de console/index.html (painel, JS e CSS). A superfície de ataque foi eliminada na raiz.

libdilithium_plegma.so encontrado compilado para arm64-v8a, armeabi-v7a e x86_64 nas builds intermediárias do APK. dilithium_bridge.c e CMakeLists.txt presentes. DilithiumFfiService e CryptoService fazem bridge completo com fallback pure-Dart quando a .so não está disponível. Item movido de V2.0+ para ✅ IMPLEMENTADO.

O proxy reverso /shield/ → http://127.0.0.1:8085 já estava configurado no nginx. A rota GET /shield/subscription/<addr> está ativa em shield_server.py. Item removido do backlog.

Ambos os arquivos de roadmap (PROJECT_MEMORY/11_known_issues_roadmap.md e DOCS/ROADMAP_priorizacao.md) foram auditados e corrigidos: App Flutter atualizado para v1.9.1, B1 biométrica marcada como ✅, Shield Pack PC v0.9.0-beta adicionado, Dilithium3 FFI movido. Backlog V1.5 expandido com os 4 itens pendentes reais.

A aba Lattice Shield exibia dois elementos de cor sobrepostos: um card de status vermelho flutuante (_SaldoStatusCard) acima do container principal, e o _PaymentSelector dentro do card Lattice. O card avulso foi removido — o elemento correto é o seletor de método de pagamento dentro do hero card, que já muda de cor (verde → validador ativo, laranja → saldo OK, vermelho → insuficiente).

Adicionalmente, foi introduzido um fallback local de genesis: caso o shield_server.py esteja inacessível, o app verifica a data local. Se dentro do período de reserva Genesis, a opção "GRÁTIS — Fase Genesis" é exibida automaticamente, sem depender de resposta do servidor. Isso evita que o UI bloqueie o usuário durante instabilidades de rede.

As datas oficiais da Reserva Genesis foram definidas: início 09 de Maio de 2026, duração de 30 dias, término 08 de Junho de 2026. O shield_server.py foi atualizado com GENESIS_START_TS = 1746748800 (09 Mai 2026 00:00 UTC). Durante este período, a ativação do Lattice Shield é gratuita para todos os participantes da Reserva.

O fluxo de boot foi atualizado: quando nenhuma carteira é detectada no dispositivo, o app agora apresenta duas opções — CRIAR NOVA CARTEIRA e RECUPERAR CONTA. Anteriormente a geração era imediata e automática.

A nova RecoverAccountScreen permite que o usuário insira suas 12 palavras em uma grade 3×4. O hash SHA3-256 é calculado inteiramente no dispositivo ("plegma_seed_v1_" + frase) e apenas o hash trafega para a rede via GET /api/wallet/seed-backup?seed_hash=<hex64>. Se encontrado, exibe o endereço PLG associado, o ID da âncora ZK e a data de registro — confirmando identidade sem expor a frase. A recuperação completa da chave de assinatura aguarda o Pacto dos 5 Nós (Shamir Secret Sharing, V2.0).

O campo seed_hash estava sendo gerado com SHA-2 (256 bits, família Merkle-Damgård) no Flutter via pacote crypto, enquanto o restante do stack Python (auth_server.py) já usava hashlib.sha3_256 (Keccak, construção de esponja). O Flutter foi migrado para SHA3Digest(256) via pointycastle: ^3.9.1 — agora ambos os lados produzem o mesmo hex de 64 chars. Coerente com o posicionamento pós-quântico do protocolo.

O bloqueio por biometria, que estava desativado desde o MVP por um bug de loop no MIUI, foi reativado com uma abordagem revisada. O HomeScreen agora implementa WidgetsBindingObserver: quando o app vai para background (paused/inactive), dispara automaticamente o lock; quando retorna ao foreground (resumed), reabre o gate para o próximo ciclo.

O problema original do MIUI era o diálogo biométrico emitindo um AppLifecycleState.paused atrasado (3-5s após o unlock) — criando um loop infinito. A solução usa um gate duplo: grace period de 2000ms pós-unlock e um flag _resumedAfterUnlock que exige um resumed real antes de aceitar qualquer novo lock. O paused tardio do MIUI chega antes do resumed → gate fechado → sem loop.

A exibição usa um ValueListenableBuilder que sobrepõe a LockScreen sobre o IndexedStack do app — o estado de todas as abas é preservado durante o bloqueio.

No primeiro boot, após a geração do par de chaves Dilithium3, o app agora exibe uma tela dedicada de frase de recuperação antes de entrar no app. A tela é obrigatória — não pode ser fechada pelo botão voltar.

As 12 palavras são geradas com Random.secure() a partir de uma wordlist de 256 palavras BIP39-compatible (sem repetição por sessão). A grade 3×4 começa oculta — o usuário precisa tocar para revelar, prevenindo shoulder surfing. Há um botão de cópia para clipboard (com aviso para apagar depois) e um checkbox obrigatório de confirmação antes de prosseguir.

As palavras são armazenadas no Keystore Android / Keychain iOS via flutter_secure_storage. A frase em si nunca sai do dispositivo.

Ao confirmar a frase, o app ancora um payload de 22KB exatos na rede via POST /api/wallet/seed-backup. O payload contém apenas o SHA-256 da frase (com prefixo de domínio), o endereço PLG e um nonce — a frase em claro jamais trafega pela rede.

O servidor persiste o registro na tabela seed_backups do plegma_data.db e retorna um anchor_id único (zk_seed_xxxxxxxxxxxxxxxx). O backup fica disponível para consulta via GET /api/wallet/seed-backup?seed_hash=<hex64>. O endpoint é tolerante a falhas de rede: se offline, o anchor é registrado localmente e o fluxo continua normalmente.

A função _executar() da tela de negociação (compra e venda de PLG) agora exige confirmação biométrica antes de submeter qualquer ordem à pool Aerarium. As telas de envio de PLG e PLG-G já tinham biometria desde versões anteriores — agora a cobertura é total.

A aba VALIDADOR ganhou duas novas interações de UX:

• Ativar mineração: exibe um overlay animado (ScaleTransition + FadeTransition) com a mensagem "Parabéns! Você está ajudando a construir o futuro. A rede PLEGMA agradece." — desaparece após 2.6 segundos.
• Desativar mineração: abre um dialog de confirmação antes de parar — "Tem certeza que realmente precisa desativar?" com botões MANTER e DESATIVAR. Previne desativações acidentais e perda de uptime/recompensas do ciclo em curso.

Na aba PROVERS, o rodapé com referência ao "Estatuto §13" foi removido — a informação já estava no card de Justiça Computacional acima.

O topo da tela de ativação do Lattice Shield agora exibe um card de status que muda de cor conforme o estado da carteira:

• ● Vermelho: sem validador ativo e sem saldo PLG suficiente. Ao tocar: snackbar "Ative o validador ou adquira PLG para continuar."
• ● Laranja: sem validador, mas com saldo suficiente. Avisa que o valor será debitado da carteira ao ativar.
• ● Verde: validador ativo. Informa que o custo será descontado automaticamente das recompensas de mineração.

O botão ATIVAR PROTEÇÃO segue a mesma paleta — sua cor de borda e texto refletem o estado da transação em tempo real, tornando o estado do sistema imediatamente legível sem precisar ler o texto.

Quando o método de pagamento é a carteira PLG, um BottomSheet de confirmação é exibido antes de executar a transferência, mostrando: endereço do destinatário (treasury Aerarium), valor travado em PLG (equivalente a US$ 12), identificador único do serviço e uma nota explicando como o Aerarium distribui o valor entre os participantes da rede.

A aba PERMISSÕES corrigia erroneamente apps com câmera e microfone como risco ALTO, mesmo quando configurados como "apenas durante o uso". A causa raiz era o método AppOpsManager.unsafeCheckOpNoThrow() retornando MODE_ALLOWED (0) silenciosamente em vez de MODE_FOREGROUND (4).

O fix no MainActivity.kt aplica uma regra mais precisa: no Android 10+, câmera e microfone são inerentemente de uso em primeiro plano para apps comuns — o sistema operacional não permite acesso em background sem permissões especiais de sistema. Agora esses apps são classificados como MÉDIO risco, reservando o nível ALTO para SMS, leitura de chamadas e permissões genuinamente perigosas.

O plano Lattice Shield ($12/mês) agora tem três formas de pagamento integradas ao backend:

• Genesis Grátis — 30 dias sem custo durante a fase Genesis (09 Mai – 08 Jun 2026). Verificado via /api/genesis/status.
• Desconto da Carteira — transfere US$ 12 em PLG para o endereço treasury via POST /wallet/transferir com assinatura Dilithium3. O fluxo existente no aerarium foi reutilizado sem duplicar lógica.
• Desconto da Mineração — disponível para validadores ativos. Verificado via /shield/payment/check.

A ativação exibe uma animação estilo Xiaomi: 3 anéis concêntricos pulsantes + contador 0–100% enquanto executa o snapshot ZK e registra a assinatura no servidor.

As abas SCANNER e PERMISSÕES quando inativas agora usam uma máscara translúcida (opacity 0.55 + gradiente suave) — o conteúdo é visível mas inacessível. O usuário vê o que vai desbloquear antes de pagar.

Na aba PERMISSÕES, apps com câmera ou microfone configurados como "apenas quando em uso" são classificados como risco MÉDIO (não ALTO). Um botão de atalho abre diretamente as configurações do app no Android via ACTION_APPLICATION_DETAILS_SETTINGS.

O layout da aba PROVERS foi corrigido:

• Card 1 (Dispositivos Vinculados) e Card 2 (Ganhos Totais) ficam lado a lado com mesma altura via IntrinsicHeight.
• Card 3 (Justiça Computacional) agora ocupa a largura total da tela, em formato retangular horizontal com ícone à esquerda.
• O estado vazio foi substituído por uma tabela com cabeçalho (NODE ID / CATEGORIA / SCORE / GANHOS / STATUS) — consistente com o painel web do dashboard.

O deploy.ps1 foi reescrito para verificar via SSH (test -f) se cada APK já existe no servidor antes de fazer o upload — evitando re-transferir 75MB desnecessariamente. O servidor mantém sempre apenas 2 versões (atual + backup). Links HTML são atualizados automaticamente por regex. O arquivo deploy.ps1 nunca é enviado ao servidor.

O repositório PlegmaDag/plegma-espectro foi configurado com o protocolo Privacy Total: branch main, .gitignore bloqueando chaves, logs offline e dados pessoais. O frontend Espectro completo (38 arquivos — landing, dashboard, blog, forge, genesis, social) foi publicado. Arquivos sensíveis como deploy.ps1 e credenciais ficam exclusivamente locais.

Dois canais criados na categoria LABS do servidor: #build-logs (logs de commit e build) e #alertas (inconsistências de hash e eventos críticos). Webhooks configurados e URLs armazenadas no .env local — nunca no repositório público.

Skill /fechar-sessao criada para automatizar o ritual de encerramento: salva memória da sessão em DOCS/PROJECT_MEMORY/, atualiza o roadmap, publica entrada no blog e prepara o commit para o GitHub. Um comando encerra a sessão completamente.

A aba SHIELD passou por uma correção de UX fundamental: anteriormente, ao abrir com o plano inativo, o app exibia imediatamente o fluxo de compra — bloqueando todo o acesso. Isso era um erro de design, pois a funcionalidade de autenticação Dilithium3 (login no dashboard) não depende do plano de proteção pago.

A nova lógica separa claramente o que é gratuito do que é pago:

• Aba AUTENTICAR — sempre visível. Os três cards (Algoritmo Crystals-Dilithium3, Endereço PLG, Autenticar no Dashboard) funcionam independentemente do plano.
• Fluxo de ativação — exibido abaixo dos cards de autenticação quando o plano está inativo, como uma oferta contextual, não como um bloqueio.
• Abas SCANNER e PERMISSÕES — permanecem bloqueadas até o plano ser ativado (são proteções pagas). Exibem tela de bloqueio com instrução clara.
• Proteções Ativas — card exibido apenas quando o plano está ativo. A linha "Vínculo IMEI + Chave" foi removida (funcionalidade não implementada).

O badge ATIVO/INATIVO na AppBar e o botão DESATIVAR são dinâmicos — o botão aparece apenas quando o plano está ativo.

A aba PROVERS dentro do SENTINELA foi reformulada para refletir exatamente os mesmos elementos do painel PROVERS do Dashboard web:

• 3 cards de resumo no topo (antes eram 2): "Dispositivos Vinculados" mostra agora duas linhas separadas — PROVERS (cyan, total de hardware via API) e VAL (purple, validadores vinculados) — com divisor visual entre eles. "Ganhos Totais" com subtítulo "Todos os dispositivos ativos". "Justiça Computacional" com o texto do protocolo: potência de hardware não confere prioridade.
• Último ping — cada card de dispositivo na lista exibe agora o campo ultimoPing, equivalente ao campo UPTIME da tabela do dashboard web.
• Textos dos passos — alinhados ao web dashboard: passo 2 agora diz "O minerador detecta o hardware e classifica como Validator ou Prover".
• Rodapé — "Trabalho equitativo · cada dispositivo contribui de forma igual" adicionado acima da Cláusula 14ª.
• Formatação numérica — uso de fmtPlg() do plegma_card.dart (4 casas decimais) substituindo a função local privada de 2 casas, tornando consistente com o restante do app.

A aba REDE do app passou a exibir exclusivamente dados reais da infraestrutura, sem nenhuma simulação:

• Card "Status da Rede": Âncoras, Mineradores e Validadores — valores lidos diretamente de GET /api/status.
• Card "Dispositivos": Provers e Val vinculados à carteira — valores de GET /wallet/provers?address= (porta 8083).

O PLG-G (token de governança Genesis) ganhou seu fluxo de transação nativa entre Sócios. O processo é simples: o vendedor informa o endereço do comprador, a quantidade e define o preço em USDC por unidade. O app calcula o total em tempo real e envia a oferta assinada com Dilithium3.

Do lado do comprador, a carteira detecta automaticamente ofertas recebidas (polling a cada 5 segundos). Um card "OFERTA P2P RECEBIDA" aparece na aba Saldo com todos os detalhes — valor, preço unitário, total USDC — e dois botões: REJEITAR ou ACEITAR E PAGAR. A compra só é confirmada se o comprador tiver USDC suficiente; a operação é assinada e registrada na DAG de forma irreversível.

Filosofia: o preço do PLG-G é determinado exclusivamente pelo Sócio vendedor. Não há oráculo, não há market maker automático. É o mercado mais puro: dois Sócios, um acordo, uma assinatura Dilithium3.

A barra de navegação do app foi simplificada de 7 para 5 abas: REDE · WALLET · SENTINELA · SHIELD · GOVERN. O objetivo é reduzir a carga cognitiva e agrupar funcionalidades relacionadas de forma natural.

As antigas abas VALIDADOR e PROVERS foram fundidas em um único ícone SENTINELA (ícone de segurança). Internamente, a tela usa um TabController com duas abas: VALIDADOR (mineração, hashrate, uptime, status DAG, boost PLG-G) e PROVERS (vínculo de hardware via QR, lista de máquinas, ganhos por pool). O FAB de scanner QR e o botão na AppBar aparecem apenas quando a aba PROVERS está ativa.

A aba NEGOCIAR deixou de ser uma entrada independente na nav e passou a ser a 4ª aba da Wallet (SALDO · VESTING · EXTRATO · NEGOCIAR). A lógica é direta: negociar $PLG é uma operação financeira e pertence ao contexto da carteira. O componente NegociarBody foi extraído como widget embeddable sem Scaffold, preservando o estado via AutomaticKeepAliveClientMixin.

A tela Shield agora funciona como um gatekeeper: ao abrir, verifica se o usuário tem o serviço ativo (localmente e no backend). Se inativo, exibe o painel de ativação completo — hero com preço ($12/ano, trial Genesis gratuito), 6 cards de proteção, tabela de funcionalidades, modelo de cobrança e termo de contratação com scroll + checkbox obrigatório. O botão ATIVAR PROTEÇÃO só é habilitado após aceite.

Ao ativar: o app chama POST /shield/subscribe no backend, cria o snapshot ZK do dispositivo (SHA3-256 dos apps instalados ancorado na rede via ZkPressEngine) e libera as 3 abas funcionais — AUTENTICAR, SCANNER e PERMISSÕES. O fluxo espelha exatamente o painel Shield Usuário do Dashboard web.

Backend: novos endpoints no shield_server.py — POST /shield/subscribe, POST /shield/unsubscribe, GET /shield/subscription/<address> — com assinaturas persistidas em shield_subscriptions.json.

A etapa de configuração de servidor foi removida do onboarding. O app agora conecta automaticamente ao servidor padrão da rede logo após gerar a carteira. Para desenvolvedores ou usuários em ambiente local (Tailscale), o override de IP está disponível no Drawer → item "Servidor" — discreto, sem poluir o fluxo do usuário final.

A aba Lattice Shield do Dashboard foi completamente redesenhada. O card de Telemetria de Rede foi substituído por dois novos cards empilhados na coluna direita: Módulo Shield Global - REDE (escudo ciano animado, proteções da rede sempre ativas) e Módulo Shield - USUARIO (estado reativo ao serviço contratado). O card "Proteções Ativas" foi renomeado para Proteções Nativas Ativas e atualizado para exibir exclusivamente as proteções da rede: Crystals-Dilithium3, BLAKE3, ZK-SNARKs, Anti-Sybil, Geofencing Ético e Protocolo de Slashing — separando claramente o que é proteção da rede do que é proteção do usuário.

O novo Painel Shield Usuário é uma página completa de contratação de serviço, construída a partir das informações da página /serviços. Inclui: hero com preço ($12/ano por dispositivo, trial Genesis 30 dias), seis cards explicando o que o Lattice Shield protege, grid de funcionalidades com status atual e V2+, modelo de cobrança (pagamento via recompensas de mineração do Aerarium), instrução de instalação para PC — apenas Validador + Agente Sentinela com Shield embutido, pois o Minerador tem regras de acesso próprias.

O ponto central do painel é o fluxo de contratação: um termo de serviço completo em scroll (7 cláusulas cobrindo natureza, pagamento, trial Genesis, instalação, cancelamento, responsabilidade e propriedade intelectual) com checkbox de aceite obrigatório. O botão ATIVAR PROTEÇÃO só é habilitado após aceite.

Após clicar ATIVAR, o sistema entra no estado PENDENTE — laranja, aguardando a instalação do Pack. Uma vez instalado, o agente detecta automaticamente o endereço PLG da carteira autenticada e ativa a proteção — o estado muda para ATIVO — verde animado, com stats do agente e botão DESATIVAR. Desativar retorna ao estado INATIVO — vermelho estático com botão ATIVAR PROTEÇÃO.

Todos os elementos visuais do painel e da sidebar são reativos ao estado: ícone e texto da nav, título do painel, hero (borda, gradiente, SVG do escudo), label de protocolo, seis ícones dos cards de proteção e checkbox — além do card na aba Lattice Shield (escudo SVG com gradiente, EKG, halo e botão de ação). No estado ativo, o EKG usa a mesma animação moveEKG do card da rede; nos demais estados fica estático.

A rede PLEGMA DAG entra em Mainnet Fase Zero — Shadow Mainnet (TEST MAINNET) em 09 ABR 2026 · 18:00 Madrid (CEST). Nós podem conectar, sincronizar topologia e enviar heartbeats. Transações de valor permanecem bloqueadas (503) até o lançamento real em 09 MAI 2026 · 18:00 Madrid (CEST), quando o watchdog automático ativa o estado GENESIS_ATIVO e a Genesis Reserve abre.

O módulo network_phase.py implementa a máquina de estados: FASE_ZERO → GENESIS_ATIVO → MAINNET_PLENA. O protocolo de heartbeat aceita qualquer nó (TTL 5 min) e computa um hash de conectividade BLAKE3 determinístico em buckets de 5 segundos — base para o Consensus de Conectividade entre peers. Novos endpoints: GET /api/rede/fase, GET /api/node/map, POST /api/node/heartbeat.

O App v1.8.0 inclui três melhorias principais:

• Aba NEGOCIAR — interface completa do Aerarium Swap Pool com abas COMPRAR/VENDER, cotação ao vivo (P=L÷S), barra de status da pool e instrução de pagamento copiável.
• Dados reais no lançamento — o app sondeia GET /api/rede/fase a cada 30 segundos. Ao detectar GENESIS_ATIVO, substitui o preço simulado do PLG pelo preço real retornado por GET /pool/cotacao. Banner no dashboard muda de âmbar para verde.
• Fix auth Shield — if (!mounted) return; adicionado após todos os await nos fluxos de autenticação Dilithium3, prevenindo setState after dispose ao fechar a tela durante verificação em andamento.

• Novo módulo aerarium_swap.py: pool de liquidez PLG/USDC nativo com fluxo de compra automático via monitor Polygon e venda com processamento manual (Fase 1).
• Carteira da pool Aerarium (Polygon, auditável publicamente): 0xD8422d6936bE77179DC33C7C2ffceEF4c34FB183 — ↗ PolygonScan
• Novos endpoints em wallet_server.py: /pool/cotacao, /pool/comprar, /pool/vender, /pool/status, /pool/configurar.
• Painel "NEGOCIAR" adicionado ao Dashboard web com UX completo (compra com instrução Polygon, venda com endereço destino).
• Tabela swap_orders adicionada ao schema SQLite via plegma_db.py.

O preço inicial do $PLG é calculado automaticamente no encerramento da Genesis (Dia 30) pela função calcular_e_setar_preco_genesis(). A fórmula é:

P = L / S

Onde L é o USDC depositado na pool (90% do arrecadado na Genesis) e S é o total de $PLG emitido na rede no Dia 1 (mineirado pelos nós durante a Genesis).

A elegância matemática: se 100% dos holders tentarem vender ao preço P, a pool precisa de S × P = S × (L/S) = L USDC — exatamente o que ela tem. Insolvência estruturalmente impossível no preço de abertura.

Os 10% restantes da Genesis vão para o Aerarium (manutenção e Nós Âncoras Continentais), com teto de $1.000 e regra de transbordo: excedente reverte para a pool, aumentando o lastro.

• Cobertura completa dos vetores de ataque no app: injection de endereço PLG, CRLF/header injection, SSRF, path traversal, overflow de valores financeiros, brute force B2, concorrência, flood de deep links, replay attack, tamper de assinatura Dilithium3.
• Todos os 295 testes passando com zero falhas.

• 🔴 CRÍTICO — HASH-COL-01 (snapshot_service.dart): o separador : na fórmula de hash do ZK-Snapshot era ambíguo — o pacote com.a:b com cert c gerava payload idêntico ao pacote com.a com cert b:c. Colisão de hash confirmável sem quebrar SHA3-256. Fix: separador trocado por \x00 (null byte), que nunca aparece em nomes de pacote Android ou hashes hexadecimais. Fórmula agora: SHA3-256(sorted "pacote\x00cert_hash").
• 🟠 ALTO — SSRF-01 (api_service.dart · setHost()): o host era atribuído diretamente sem validação — CRLF injection, request smuggling e redirecionamento para IPs internos eram possíveis. Fix: regex RFC-3986 ^[a-zA-Z0-9]([a-zA-Z0-9\-.]*[a-zA-Z0-9])?$ rejeita qualquer host com controle chars, espaços, barras ou portas embutidas. Host anterior é preservado se o novo for inválido.
• 🟠 ALTO — SERIAL-01 (wallet_provider.dart): jsonEncode({'amount': double.infinity}) lançava JsonUnsupportedObjectError sem tratamento — crash silencioso na camada de transferência. Fix: guard if (!amount.isFinite || amount <= 0) return null; em transferir() e transferirPlgg() antes de qualquer chamada à API.

• Transferência para si mesmo não bloqueada no cliente — servidor deve validar de != para.
• Campo "de": "" em walletTransferir — identidade preenchida pelo servidor via sessão autenticada Dilithium3.
• Replay attack: body idêntico reenviado sem nonce/timestamp no cliente — servidor responsável pela proteção.
• Dart jsonEncode não escapa < para \u003c (diferente de JSON.stringify do JS) — risco apenas se JSON for injetado diretamente em HTML.

• A landing page /servicos (aba Lattice Shield) marcava 4 funcionalidades como ✅ ativo — nenhuma existia no app. A aba Shield era exclusivamente um autenticador QR.
• Decisão: implementar as 4 funcionalidades de forma que passem pelas políticas de App Store e Google Play, sem virar spyware.

• Problema de loja: apps que fazem scan contínuo de pacotes instalados são rejeitados por ambas as stores como comportamento de spyware.
• Solução: ao instalar, o usuário consente um snapshot único do dispositivo. O app lê os apps instalados uma vez, computa SHA3-256(sorted "pacote\x00cert_hash") localmente — a lista nunca sai do dispositivo. O separador \x00 (null byte) é inequívoco: evita colisão de hash que o separador : permitia.
• O hash é enviado ao shield_server.py (porta 8085), que gera uma prova ZK via ZkPressEngine (Lattice Ring-LWE) e ancora na rede. Retorna anchor_id + zk_proof.
• Monitoramento futuro: BroadcastReceiver Android registrado dinamicamente escuta ACTION_PACKAGE_ADDED/REMOVED/CHANGED. Zero polling. Zero permissão especial adicional.
• Em mudança: app recomputa o hash localmente, compara com o snapshot — se diferente, exibe o diff (quais pacotes mudaram) e oferece re-ancoragem em 1 tap.
• Hash usa hierarquia: SHA3-256 no Android 12+ (= fallback Python de lattice_shield.py), SHA-256 em versões anteriores. BLAKE3 seria ideal mas não tem biblioteca nativa Dart sem NDK customizado.

• Novo servidor shield_server.py com banco de ameaças seed: 20 pacotes maliciosos conhecidos + 24 domínios de phishing.
• POST /shield/scan/batch — verifica lote de apps por nome e hash de certificado (SHA-256 do APK signing cert).
• POST /shield/scan/url — 3 camadas: blocklist estática → ameaças da comunidade → análise de padrões regex (phishing patterns, URL shorteners, IP direto).
• POST /shield/anchor — recebe state_hash + plg_address, encadeia com anchor anterior do mesmo endereço (prova recursiva), persiste em shield_anchors.json.
• POST /shield/report — qualquer nó pode contribuir com uma nova ameaça. Persiste em shield_threats.json — inteligência coletiva distribuída.
• Nginx: /shield/ adicionado ao proxy api.plegmadag.com.

• Aba AUTENTICAR: fluxo QR + Dilithium3 existente intacto. Novo card mostra: hash do estado (truncado), anchor_id, ZK engine, data e contagem de apps monitorados. Alerta visual vermelho quando delta pendente com lista de pacotes adicionados/removidos/re-assinados.
• Aba SCANNER: botão "ESCANEAR TODOS OS APPS" — lê via MethodChannel, envia ao shield_server, exibe apps flagged com status MALWARE/SUSPEITO e motivo. Verificador de URL com input e resultado colorido. Ambos têm fallback offline com heurística local.
• Aba PERMISSÕES: lista apps de terceiros com permissões sensíveis efetivamente concedidas (não apenas declaradas). Câmera, microfone, GPS, SMS, contatos, histórico de chamadas. Expandível por app com chips coloridos por nível de risco.
• Qualquer ameaça detectada pode ser reportada à rede com um toque (ícone de report → POST /shield/report).

• MainActivity.kt implementa MethodChannel com.plegmadag.app/shield com 3 métodos: getInstalledApps (lista + cert SHA-256), getAppsWithSensitivePermissions, computeStateHash.
• EventChannel com.plegmadag.app/package_events: BroadcastReceiver dinâmico (sem entrada no AndroidManifest) emite {action, package} ao Flutter em tempo real.
• Permissão QUERY_ALL_PACKAGES adicionada ao manifest com justificativa de auditoria de segurança.

• Código SYS_SYNC atualizado em genesis.py: ALV_ZKDAG_BNG_GENESIS_2026_FAIRLAUNCH → ZKDAG_PLG_GENESIS_2026_FAIRLAUNCH
• Hash BLAKE3 do Vértice Gênese recalculado deterministicamente: 99bc58779e0830df47c2f65b193c587edb622fd8aa42709b61c6d3b86dfd7f1c
• Constante GENESIS_HASH em core_dag.py atualizada para refletir o novo hash.
• core_vm.py usa _genesis.hash dinamicamente — nenhuma alteração necessária.

• Criado tx_verifier.py — módulo central de verificação: valida chave pública (1952 bytes), vincula endereço PLG ao hash BLAKE3 da pubkey, verifica assinatura Dilithium3 real.
• CVE-001: POST /api/mine agora chama verificar_tx() obrigatoriamente. Vértices sem assinatura válida são rejeitados com HTTP 401 antes de tocar o DAG.
• CVE-005: POST /wallet/transferir exige Authorization: Bearer + assinatura Dilithium3 do campo FROM:DEST:AMOUNT. Transferências não autorizadas retornam 401.
• CVE-006: transferir_plgg() no Genesis Contract verifica ownership da chave antes de mover PLG-G. Atacante sem a chave privada não consegue transferir saldo de terceiros.

• CVE-002: POST /api/peer/vertex agora valida hash BLAKE3 + assinatura Dilithium3 de cada vértice de peer antes de inserir no DAG. Injeção de vértices fabricados bloqueada.
• CVE-003: Token de sessão substituído — PLG_TOKEN_{addr}_{ts} (determinístico, forjável) → secrets.token_hex(32) (256 bits de entropia). Sessões gravadas na tabela sessions do SQLite compartilhado.

• CVE-004: protocolo_slashing() agora chama plegma_db.salvar_ban() imediatamente — ban gravado em disco com checksum BLAKE3 (detecção de adulteração).
• Escudo.__init__() carrega todos os bans persistidos antes de abrir os sockets. Nós banidos não conseguem se reconectar após restart do servidor.
• SentinelaCore.processar_transacao() verifica ban no início do fluxo — rejeição imediata sem executar nenhuma outra camada.

• Criado dilithium_bridge.c — C bridge exportando API limpa: dilithium3_keygen, dilithium3_sign, dilithium3_verify, plegma_blake3_hash.
• Criado CMakeLists.txt — compila via Android NDK (arm64-v8a + x86_64) buscando PQClean/dilithium3/clean (NIST FIPS 204) e BLAKE3-team/BLAKE3/c automaticamente via FetchContent.
• Criado dilithium_ffi_service.dart — singleton dart:ffi que carrega libdilithium_plegma.so e expõe keygen(), sign(), verify(), blake3Hash() com gestão de memória via calloc.
• crypto_service.dart reescrito — gerarCarteira() gera chaves Dilithium3 reais (pk 1952b / sk 4000b), endereço derivado de BLAKE3(pk)[0:40]. assinarNonce() produz assinatura real de 3293 bytes em Base64 — paridade total com o nó Python (lattice_shield.py).
• Item PMR 2.4 ("Dilithium3 FFI mobile") desbloqueado — condição bloqueante para burn da Chave DEUS.

• Relatório de auditoria: SECURITY_AUDIT/RELATORIO_SEGURANCA_2026-03-29.md · Script: SECURITY_AUDIT/test_battery.py (90 testes)

• Bateria de 90 testes automatizados executada em análise estática + testes unitários sobre o código-fonte do projeto inteiro: Sentinela, Auth Server, Core VM, Wallet Server, Genesis Contract, App Flutter e testes de resistência (fuzzing, race conditions, edge cases).
• Score geral: 72% — 65 aprovados / 25 reprovados. Por severidade: CRITICAL 15✅ 8❌ · HIGH 19✅ 8❌ · MEDIUM 8✅ 8❌ · INFO 23✅ 1❌.
• O que está sólido: Geofencing (KP/IR/SY 100%), Anti-Smurfing (race condition thread-safe), Crivo overflow/underflow/reentrância, Slashing do Escudo, NonceStore (TTL + uso único + replay bloqueado), RateLimiter thread-safe, limite 64KB por request, honeypot Fundação, lock TOCTOU Genesis, FlutterSecureStorage com encryption.
• CVE-001 a CVE-008 identificados — ver post "PATCH BUILD 009" acima para detalhes e correções aplicadas.
• Relatório completo: SECURITY_AUDIT/RELATORIO_SEGURANCA_2026-03-29.md

• /servicos — sistema de abas: Página de serviços reestruturada com tab-bar idêntico ao Blog — [ Lattice Shield ] e [ Plegma Timestamp ]. URL hash (#lattice / #timestamp) para navegação direta.
• Plegma Timestamp — novo serviço: Serviço de Ancoragem de Estado completo. BLAKE3 local via WASM → ZK-Press 22KB → DAG. Fluxo 5 etapas, distribuição de receita (2% Royalties · 10% Aerarium · 88% Rede), verificação gratuita para qualquer pessoa, preço 2€/registro em $PLG.
• Protocolo de Propriedade de Serviço: Cada serviço agora tem secção "Propriedade do Serviço" com campo bloqueado pré-lançamento. Após lançamento da rede, a carteira do criador é revelada via /api/status (rede_ativa). Royalties distribuídos automaticamente pelo protocolo — sem custódia. Padrão obrigatório para todo serviço futuro.
• /labs — PROJETOS como aba: Botão PROJETOS removido do nav (era gaveta). Substituído por tab-bar padrão [ Ideias ] / [ Projetos ] abaixo do hero. Protocolo de serviços explicado no tab Projetos: ideia registrada no Labs com carteira → aprovada → serviço ativo com endereço PLG pré-atribuído.
• /labs — badge "Em Teste": Os 3 projetos do Arsenal (ZKM Forge, ZKM Viewer, ZKM Player) receberam badge âmbar ⚠ Em Teste indicando que ainda não funcionam 100%. Controlado por campo beta: true no array — remover quando estável.
• /genesis — contador regressivo: Countdown sempre visível na área "Status da Reserva Genesis". 3 estados visuais: pending (aguardando lançamento, dígitos `--`), active (contagem DD:HH:MM:SS com glow cyan), ended (dígitos vermelhos "00"). Dispara automaticamente quando API retorna dias_restantes > 0.

• ISS-04 [RESOLVIDO] — POST /api/mine: adicionada validação obrigatória dos campos sender, receiver, amount, signature, public_key. Body vazio retorna 400 com lista de campos ausentes. Body válido mantém 201.
• ISS-05 [RESOLVIDO] — Miner API na porta 8084 exposta via nginx (/miner/ → 127.0.0.1:8084). Novo daemon miner_daemon.py deployado no servidor validador com MinerEngine headless. GET /miner/status → 200 com hashrate, total_aceitas e recompensa em tempo real.
• ISS-06 [RESOLVIDO] — Rotas alias adicionadas em core_vm.py: /api/dag/status (alias de /api/status) e /api/sentinela/status (expõe estado dos agentes Vigia/Crivo/Escudo).

Ficheiros alterados: core_vm.py, _nginx_api.conf, novo miner_daemon.py. Nginx recarregado em produção. Score de testes: 28/28 — 100%.

Em conformidade matemática com a arquitetura de rede, os parâmetros de Governança, Destinação Genesis e Distribuição de Taxas foram atualizados e consolidados nos pilares do protocolo. A documentação on-chain agora espelha exatamente o comportamento programado no motor:

• Tiers Genesis ajustados para escalar em blocos mais coesos: APOIADOR (1.000 a 3.000 PLG-G | até 3 mineradores), SENTINELA (3.001 a 6.000 PLG-G | até 6 mineradores) e MASTER (6.001 a 10.000 PLG-G | até 10 mineradores).
• Destinação Genesis (90/10): Divisão exata do arrecadado: 90% para o Pool de Liquidez nativo e 10% direcionado ao fundo Aerarium (custeio do protocolo e implantação de Nós Âncoras Continentais).
• Distribuição de Taxas (Seção 6): Injeção contínua da rede obedece o corte: 10% Aerarium, 40% Provers e 50% Validadores. Aplicada regra rígida de transbordo: ao atingir o teto de $1.000 acumulado no Aerarium, o fluxo redireciona excedente para os Validadores, convertendo a taxa para 0% Aerarium / 40% Provers / 60% Validadores.

A fonte Syne foi substituída por Montserrat:wght@800 em todos os 21 arquivos HTML do site. Import do Google Fonts atualizado em cada página. Todos os seletores CSS que usavam font-family: 'Syne' — .nav-brand, h1, .hero h1, .page-title e equivalentes — passaram a usar 'Montserrat', sans-serif com peso 800 (ExtraBold). Peso mantido idêntico; apenas a família tipográfica foi alterada.

/servicos: página de infraestrutura como protocolo. Primeiro serviço listado: Protocolo Sentinela — camada de segurança autônoma em três estágios (Vigia, Crivo, Escudo) com anti-smurfing persistido, rate limiting adaptativo e slashing automático. Disponível como API REST agnóstica de stack.

/podcast: canal técnico da rede. Quatro episódios planejados: DAG explicado, Crystals-Dilithium3, ZK-Press e Q&A da comunidade. Perguntas submetidas via perfil @plegmadag na Rede PLEGMA Social.

Regra de consistência estabelecida: todas as páginas (exceto Dashboard) compartilham a mesma nav. Com /servicos e /podcast, a nav passou de 6 para 8 links: FINANÇAS · FUNDAÇÃO · REDE · BLOG · LABS · GENESIS · SERVIÇOS · PODCAST + botão DASHBOARD com autenticação Dilithium3. Nova página criada herda automaticamente a nav e o footer padrão.

Footer unificado: © 2026 PLEGMA DAG | The Architecture of Absolute Justice + links Termos de Uso · Privacidade · Cookies · Quem Somos. Corrigido em genesis, blog, ajuda, quem-somos e labs que tinham footer incompleto ou ausente. Dashboard mantém estrutura própria.

Com este patch, a Camada 12 do ROADMAP está completamente fechada. Todos os 10 itens identificados na auditoria de segurança de 23 de março de 2026 — 2 CRÍTICOS, 2 ALTOS, 4 MODERADOS, 2 BAIXOS — foram corrigidos e verificados em produção.

A lista de tips da DAG crescia sem limite. Um nó malicioso enviando transações inválidas repetidamente poderia inflar a lista até esgotar a memória do servidor.

• Constante MAX_TIPS = 1000 definida no topo do módulo.
• _atualizar_topologia() aplica descarte FIFO após cada inserção: remove os tips mais antigos ao ultrapassar o limite.
• O hash Gênese é sempre preservado — nunca descartado pelo FIFO.
• Comportamento determinístico: a lista nunca excede 1.000 entradas independente da taxa de transações.

O dicionário active_mobile_connections da classe Vigia era armazenado apenas em memória. Reinicializar o servidor zerava completamente o estado anti-smurfing, permitindo que um atacante contornasse o limite de 6 celulares por IP simplesmente aguardando uma reinicialização.

• Vigia.__init__ carrega o estado persistido via plegma_db.carregar_estado("vigia_connections", {}).
• verificar_borda() persiste imediatamente após cada nova conexão registrada.
• O mapa {ip: [hardware_hashes]} agora sobrevive a reinicializações, deploys e quedas do processo.

A fórmula de recompensa R = G ÷ N (Aerarium) usava N = len(transactions) + 1 — o número total de transações históricas. Isso distorcia progressivamente a recompensa: quanto mais transações na DAG, menor a recompensa por vértice, mesmo que o número real de nós ativos fosse constante.

• self._nos_unicos: set rastreia endereços miner_address únicos que já mineraram pelo menos um vértice.
• Persistido em plegma_db.salvar_estado("nos_unicos_list", list(self._nos_unicos)) após cada novo nó detectado.
• Carregado na inicialização: plegma_db.carregar_estado("nos_unicos_list", []) — estado sobrevive a reinicializações.
• nos_ativos = max(len(self._nos_unicos), 1) substitui o proxy incorreto.
• A fórmula R=G/N agora reflete com precisão o número de mineradores reais na rede — sem distorção acumulada.

A Camada 12 do ROADMAP está encerrada. Não há vulnerabilidades abertas. O protocolo está pronto para abertura pública da rede com toda a stack de segurança validada e funcional em produção.

Todas as vulnerabilidades identificadas na auditoria de segurança do BUILD 007 foram corrigidas neste patch. O protocolo está agora protegido contra os vetores de ataque identificados, liberando o caminho para abertura pública da rede.

• [CRÍTICO] gossip.py — _verificar_vertice() adicionada: verifica binding endereço↔pubkey Dilithium3, assinatura sobre payload reconstruído e zk_proof_size > 0 antes de aceitar vértice de peer.
• [CRÍTICO] auth_server.py — RuntimeError levantado imediatamente no import se dilithium-py ausente. Servidor recusa iniciar sem criptografia real. Branch de dev mode removida.
• [ALTA] aerarium.py — threading.Lock() protege pool de mineração. Read-check-write-persist atômico elimina race condition TOCTOU.
• [ALTA] genesis_contract.py — threading.Lock() protege supply PLG-G. registrar_intencao() e confirmar_compra() são agora thread-safe.
• [MODERADA] auth_server.py — Rate limiter sliding window (10 req/60s por IP) em /api/auth/challenge. HTTP 429 ao ultrapassar limite.
• [MODERADA] core_dag.py — Timestamp capturado uma única vez antes da assinatura (ts_assinatura). Garante T1=T2 entre assinatura e hash da transação sob qualquer carga.
• [MODERADA] plegma_db.py — PRAGMA journal_mode=WAL habilitado em inicializar_banco(). Leituras concorrentes sem bloqueio de escrita.

Novo endpoint no core_vm.py implementa um canal de notas em memória protegido por senha SHA256. GET/POST/limpar com autenticação por senha. Widget flutuante na homepage consome este canal.

• GET /api/notas?senha=X — lista mensagens, retorna 403 se senha incorreta
• POST /api/notas body {"{senha, msg}"} — salva nota com timestamp dd/mm HH:MM
• POST /api/notas/limpar — apaga todas as notas do canal
• Limite de 200 mensagens FIFO. Estado em memória — resetado ao reiniciar o servidor.
• URL do widget corrigida de IP direto para http://api.plegmadag.com/api/notas (via nginx, com CORS correto)

Nova página com manifesto do protocolo: o que PLEGMA DAG é, o que não é, a origem da ideia em 01/02/2026, a filosofia de Justiça Absoluta, a stack técnica e a missão de soberania digital.

• Abertura: "Não somos pessoas. Não somos empresa. Não temos escritório. Somos um protocolo."
• 6 pilares do protocolo com cards individuais
• Seção "Justiça Absoluta" com checklist: sem ICO, sem pré-mineração, sem tokens de fundador, Fair Launch total
• Stack técnica: Dilithium3 · DAG · BLAKE3 · ZK-SNARK · Aerarium · Gossip
• Closing manifesto: "Protocolos não morrem quando param de acreditar — morrem quando param de rodar."

Nova página de controle operacional para o Sócio Fundador, acessível exclusivamente via botão discreto "⬡ conselho" na aba de Provers do dashboard. Não indexada por buscadores (noindex, nofollow), sem links públicos.

• Gate de senha (admin_key) com verificação server-side via /api/admin/downloads
• Sessão salva em sessionStorage — persiste enquanto a aba estiver aberta
• Cards: transações DAG, aceitas/rejeitadas, tips, Genesis Reserve (barra de progresso PLG-G), Pools de Mineração
• Lista de Sócios PLG-G com categoria (Apoiador/Sentinela/Master) e selo Genesis
• Ações rápidas: ativar governança, injetar liquidez, limpar canal de notas, painel Fundação, burn de não vendidos (com confirmação dupla)
• Downloads APK com contagem por versão
• Canal de notas integrado (enviar/ler/limpar diretamente no painel)
• Inscrições da Fundação com status por projeto
• Últimos 20 vértices da DAG em tempo real
• Auto-refresh de 30s para status da rede e notas

Todas as páginas agora carregam Syne:wght@800 e aplicam a fonte da logo no elemento .nav-brand e equivalentes. Blog, Dashboard e Forge corrigidos.

Revisão dos parâmetros econômicos da Reserva Genesis para garantir que apenas participantes com compromisso real entrem como Sócios Fundadores. O mínimo de $1 era permissivo demais — elimina curiosos e fortalece a base de governança desde o início.

• Mínimo elevado de $1,00 para $100,00 USDC (equivalente a 1.000 PLG-G a $0,10)
• Validação no backend (genesis_contract.py) e no frontend (JS + hint)
• Input HTML: min="100" — impede envio abaixo do mínimo

• APOIADOR: 1.000–3.000 PLG-G · $100–$300 · até 3 mineradores
• SENTINELA: 3.001–6.000 PLG-G · $301–$600 · até 6 mineradores
• MASTER: 6.001–10.000 PLG-G · $601–$1.000 · até 10 mineradores
• Tiers anteriores (MASTER=6.670, SENTINELA=3.340, APOIADOR_MIN=10) substituídos

• Nova fórmula: 1.01 + (saldo - 1000) × (3.99 / 9000)
• Escala linear de 1,01 (1.000 PLG-G) a 5,0 (10.000 PLG-G)
• Cap de 5,0 mantido — saldo acima de 10.000 não eleva mais o peso

• 1 minerador por 1.000 PLG-G em carteira (exclusivo para Sócios Fundadores Genesis)
• max_mineradores = floor(saldo_plgg / 1000) — adicionado ao dict de retorno do check_priority()
• Exemplos: 1.000 PLG-G → 1 minerador · 5.000 → 5 · 10.000 → 10
• Taxa de mineração: 40% para todos (diferenciação já existe via boost PLG-G)

• sentinela.py — novos thresholds, formula peso_voto, max_mineradores
• genesis_contract.py — validação mínimo $100
• genesis/index.html — cards de tier, hint do formulário, validação JS
• dashboard/index.html — aviso PLG-G com tiers e ratio
• blog/index.html — este log
• ROADMAP_priorizacao.md — header e entrada da CAMADA 2

• Todas as camadas de autenticação (B1 biometria, B2 padrão de pontos, overlay de lock, lifecycle guard) foram desativadas do fluxo principal do app
• App abre direto na tela de boot → home, sem nenhuma barreira de autenticação
• auth_service.dart e lock_screen.dart preservados no código — prontos para reimplementação com novo sistema em V2.0+
• Decisão motivada por loop de autenticação persistente em dispositivos MIUI/Xiaomi que resistiu a múltiplas correções (v1.3.0 → v1.6.0). Será reimplementado com abordagem diferente
• Registrado no ROADMAP como ⚪ V2.0+
• APK v1.7.0 publicado — build limpo, 73.4 MB

• As duas abas separadas "ENVIAR $PLG" e "ENVIAR PLG-G" na barra lateral foram fundidas em uma única aba ENVIAR
• Dentro do painel: duas sub-tabs — $PLG e PLG-G — com troca visual e estado independente
• Os botões na visão da Carteira (ENVIAR $PLG / ENVIAR PLG-G) continuam funcionando e abrem diretamente na tab correta
• Avisos PLG-G: bloco âmbar completo antes do formulário de envio PLG-G explicando: governança viaja com o token, peso de voto transferido ao destinatário, lock-up ativo durante Genesis, preço genesis $0,10 e mercado P2P pós-lançamento

• Corrigido bug clássico de Flexbox: o elemento .panel não tinha min-height: 0, fazendo o conteúdo ocupar altura mínima igual ao tamanho do conteúdo em vez de obedecer ao container pai
• Resultado: no desktop, o painel não respeitava os limites de 100vh do main e o scroll interno não funcionava corretamente — o layout parecia "mobile" (conteúdo comprimido/fora do lugar)
• Fix: min-height: 0 adicionado ao .panel — scroll interno restaurado em todas as resoluções desktop

• Widget flutuante ✉ adicionado no canto inferior direito da landing page
• Acesso protegido por senha (verificação SHA256 no servidor)
• Mensagens armazenadas no servidor com timestamp — persistem entre sessões
• Recarregamento automático a cada 30s + envio com Ctrl+Enter
• Botão LIMPAR TUDO para resetar o histórico
• Backend: dois novos endpoints em core_vm.py — GET /api/notas?senha= e POST /api/notas
• Finalidade: canal de comunicação assíncrono para enviar notas durante o dia sem precisar abrir o terminal

• Raiz do problema: Em dispositivos Xiaomi/MIUI o diálogo biométrico é uma Activity separada. Ao fechar, o sistema emite um evento AppLifecycleState.paused atrasado (~1–2 s) mesmo com o app em primeiro plano — disparando um novo lock logo após o unlock bem-sucedido
• canLock grace period: Adicionado campo _unlockTime em AuthService. A propriedade canLock retorna false durante 2000 ms após cada chamada a unlock(). Condição em main.dart atualizada para !AuthService.isLocked && AuthService.canLock
• APK v1.3.0 publicado

• Guard de lifecycle sincronizado com canLock para garantir que o evento paused tardio do MIUI nunca aciona o lock enquanto o app acabou de desbloquear
• lock_screen.dart reescrito: B1 dispara em initState via addPostFrameCallback — sem dependência de estado interno do framework biométrico
• APK v1.4.0 publicado

• Diagnóstico final: O MIUI dispara AppLifecycleState.paused de forma atrasada (3–5 s) após o fechamento da Activity biométrica — depois do unlock() já ter sido chamado, mas antes de resumed chegar. O grace period simples de 2 s não cobria esse intervalo em todos os dispositivos
• Gate _resumedAfterUnlock: Adicionado campo estático _resumedAfterUnlock = false em AuthService. lock() e unlock() resetam para false. markResumed() seta para true. canLock agora retorna false enquanto o flag for falso
• Em main.dart: AppLifecycleState.resumed chama AuthService.markResumed(). O paused tardio do MIUI chega antes de resumed real → gate ainda fechado → sem re-lock
• Quando o usuário vai ao background genuinamente: app estava em resumed → gate aberto → lock normal ✓
• APK v1.6.0 publicado — loop de autenticação eliminado definitivamente

• Decisão técnica: Mesmo com canLock, o loop de autenticação persistia em MIUI. A causa era a transição B1→B2: o diálogo biométrico (B1) emitia o evento tardio durante a janela de entrada do padrão (B2), reiniciando o fluxo
• B2 (padrão de pontos 3×3) removido do app. Lock agora é exclusivamente B1 = biometria/PIN do dispositivo
• Rotas /pattern_setup removidas. boot_screen.dart simplificado: após confirmar host → AuthService.lock() → /home diretamente
• Métodos B2 preservados em auth_service.dart para reimplementação futura em V2.0+
• lock_screen.dart completamente reescrito: apenas B1. Sem _logoTaps, sem b1DoneNotifier, sem estado de padrão
• APK v1.5.0 publicado — build limpo, 73.4 MB

• Painel Carteira reestruturado para espelhar fielmente a carteira do app mobile
• Card $PLG SALDO PRINCIPAL: total, disponível, vesting e cotação USDT em tempo real
• Card PLG-G GOVERNANÇA: saldo total com cotação USDC (× $0,10 genesis / P2P pós-lançamento). Detalhes de disponível/lock visíveis apenas quando saldo_plgg > 0; mensagem informativa quando zerado
• Card PLG-G / USDC: preço genesis ($0,10) com nota sobre mercado P2P
• Botão ENVIAR PLG-G: painel de envio completo com validação de saldo, confirmação prévia mostrando destino, valor e saldo restante, e resultado inline. POST para /wallet/transferir_plgg
• Duplicatas do campo $PLG removidas (era exibido duas vezes antes da reestruturação)

Auditoria completa de todos os módulos críticos do backend Python: core_dag.py, aerarium.py, sentinela.py, auth_server.py, gossip.py, plegma_db.py, genesis_contract.py e lattice_shield.py. Análise estática de 2.200+ linhas de código. Simulação de vetores de ataque: injeção via gossip, race condition de supply, DDoS por nonce spam, bypass de modo dev, ataque de frontrunning na Genesis.

• [CRÍTICO] gossip.py — Injeção de Vértices Fraudulentos: _buscar_e_aceitar_vertice() aceita vértices sincronizados de peers sem verificar assinatura Dilithium3 nem prova ZK. Um peer malicioso pode injetar transações falsas diretamente no DAG local. Vetor: comprometer qualquer nó → propagar vértices com hash válido mas assinatura omitida → contaminação silenciosa do estado da rede
• [CRÍTICO] auth_server.py — Dev Mode Bypass (DILITHIUM_AVAILABLE = False): Quando a biblioteca Dilithium3 não está instalada, o servidor entra em modo de desenvolvimento que aceita qualquer assinatura como válida. Em produção com a biblioteca ausente ou corrompida, qualquer cliente pode autenticar como qualquer carteira. Impacto: autenticação completamente nula

• [ALTA] aerarium.py — Race Condition no Pool de Validadores (TOCTOU): O bloco mine_tokens() lê validator_pool, verifica saldo, debita — mas sem lock de threading. Com múltiplas requisições de mineração simultâneas (cenário realista em rede com 100+ nós), o pool pode ser debitado abaixo de zero. Vetor: disparar 50+ requisições POST /mine em paralelo — pool de 4.000.000 PLG vira negativo
• [ALTA] genesis_contract.py — TOCTOU no Supply PLG-G: registrar_intencao() e confirmar_compra() leem plgg_vendido da DB, verificam < 10.500.000, depois escrevem — sem SELECT FOR UPDATE (SQLite não suporta) e sem lock Python. Múltiplas compras concorrentes podem ultrapassar o limite de 10,5 M PLG-G. Mitigação parcial: tx_externo_ja_processado() previne replay, mas não race inicial

• [MODERADA] auth_server.py — Sem Rate Limiting no Endpoint /api/auth/challenge: Qualquer IP pode solicitar nonces ilimitados. Cada nonce é armazenado em memória com TTL. Ataque: script gerando 10.000 req/s pode saturar memória do servidor e degradar autenticação legítima
• [MODERADA] core_dag.py — Inconsistência de Timestamp (T1 vs T2): dados_para_assinar usa int(time.time()) no momento da assinatura (T1). O construtor Transaction.__init__ define self.timestamp = int(time.time()) (T2). A assinatura cobre o hash com T1, mas o tx_hash canônico usa T2. Em cargas altas (>1s de processamento), T1 ≠ T2 → assinatura inválida para o tx_hash persistido
• [MODERADA] plegma_db.py — SQLite sem WAL Mode: Modo padrão de journal causa bloqueio de escrita sequencial. Em rede ativa com múltiplos nós escrevendo transações, timeouts e erros database is locked são esperados. PRAGMA journal_mode=WAL permitiria leituras e escritas simultâneas
• [MODERADA] core_dag.py — Tips List Pode Crescer Indefinidamente: Se um vértice referencia parents que não estão nos tips atuais, os parents são adicionados de volta aos tips sem verificação de duplicatas ou limite de tamanho. Em ataques de spam de vértices inválidos, a lista de tips pode crescer sem controle

• [BAIXA] sentinela.py — active_mobile_connections Não Persistido: Conexões mobile ativas são armazenadas apenas em memória (active_mobile_connections = {}). Reinicialização do servidor limpa o estado — nós que estavam conectados são tratados como novos até reconectar
• [BAIXA] core_dag.py — nos_ativos é Proxy Incorreto: nos_ativos = len(self.transactions) + 1 conta transações, não nós da rede. Endpoint /api/status reporta número inflado quando a rede ainda tem poucos nós mas muitas transações

• Gossip Injection Attack: Peer malicioso na rede gossip propaga 100 vértices com amounts fabricados. Resultado simulado: todos aceitos sem verificação. Impacto: saldos inflados, DAG corrompido silenciosamente. Bloqueado pelo fix proposto: verificação Dilithium3 obrigatória no sync
• Race Condition Supply Overflow: 200 requisições simultâneas de compra PLG-G com 100.000 unidades cada. Resultado simulado: ~180 aceitas antes do lock disparar → até 18.000.000 PLG-G emitidos (7,5% acima do cap de 10,5M). Fix: threading.Lock() em torno de read-check-write
• Nonce Spam DoS: 50.000 req/s em /api/auth/challenge. Resultado simulado: servidor Flask single-thread atinge 100% CPU em ~3s, latência de autenticação legítima >30s. Fix: rate limiting por IP com sliding window
• Dev Mode Bypass: Remoção da biblioteca Dilithium3 do servidor → qualquer {"assinatura": "fake"} aceito. Resultado: acesso total como qualquer carteira cadastrada. Fix: falha explícita em produção quando Dilithium indisponível

Todos os itens acima foram registrados no ROADMAP com prioridade. Fixes críticos (gossip + dev mode bypass) são bloqueantes para a abertura da rede ao público. Fixes de race condition (aerarium + genesis) serão implementados antes do Dia 1 da Genesis Reserve. Rate limiting no challenge endpoint será parte do hardening V1.5.

• Fix loop de autenticação: AppLifecycleState.inactive removido do gatilho de lock. O estado inactive dispara enquanto o diálogo biométrico do sistema está aberto — causando loop de digital → padrão → digital. Agora o app só trava em paused (background real)
• Tela de aviso obrigatório antes da configuração do padrão: 3 blocos explicativos (Digital / Padrão Secreto / Anti-Coação) com checkbox obrigatório. Botão "CONFIGURAR MEU PADRÃO" permanece desativado até leitura confirmada. Resolve a confusão de usuários que achavam o app travado após a digital
• Fluxo de setup atualizado: info (leitura + checkbox) → draw1 → draw2 → /home

• Nova página /ajuda com 25 artigos organizados em 7 categorias: Primeiros Passos, Reserva Genesis, Como Comprar USDT, Mineração, Fundação, Segurança, Rede & Governança
• Busca interna em tempo real filtrando por título e conteúdo dos artigos
• Filtros por categoria na sidebar (desktop) e tags compactas (mobile)
• Artigos em acordeão expansível com dicas, avisos e blocos de passo a passo formatados
• Link "AJUDA" adicionado na nav principal

• POST /api/fundacao/inscricao: recebe formulário, valida campos obrigatórios, aplica rate limiting (3 por hora por IP) e honeypot anti-bot (website_url). Salva em tabela fundacao_inscricoes isolada no SQLite
• GET /api/fundacao/inscricoes?admin_key=: endpoint protegido por variável de ambiente PLEGMA_ADMIN_KEY
• Formulário HTML conectado ao backend via fetch() com validação client-side, honeypot invisível e mensagens de sucesso/erro inline
• Painel admin /admin/fundacao.html: interface visual com stats (total/pendentes/aprovados/rejeitados), filtros, busca e troca de status por clique

• Hamburger menu mobile: nav da landing page colapsava em telas pequenas empilhando todos os links. Implementado menu hamburguer (☰/✕) com animação — links em coluna vertical ao expandir
• Email overflow mobile: endereço plegmadag@proton.me na seção "Canal Oficial" extrapolava a largura da tela. Corrigido com word-break: break-all e clamp mais agressivo

• Artigo de instalação do APK inclui dica sobre verificações de segurança: o Google Play Protect e o verificador do fabricante (Xiaomi, Samsung etc.) podem solicitar análise do arquivo — aceitar a verificação e ser aprovado é prova de ausência de vírus ou malware
• Artigo de autenticação dupla reescrito com ênfase clara: a digital sozinha não desbloqueia o app completamente — necessário 3 toques no logo para abrir o padrão

• v1.0.0 — Primeiro build assinado publicado em plegmadag.com/download/
• v1.0.1 — HTTP cleartext liberado (usesCleartextTraffic), permissões CAMERA e USE_BIOMETRIC adicionadas
• v1.0.2 — Correção crítica de package: com.plegmadag.plegma_app → com.plegmadag.app. App instalava mas não abria (ClassNotFoundException: MainActivity)
• v1.1.0 — Sistema de autenticação dupla anti-coação implementado
• v1.1.1 — Correção do overlay de lock: lockedNotifier inicia como false; boot chama lock() disparando o ValueListenableBuilder
• v1.1.2 — FlutterActivity → FlutterFragmentActivity: necessário para o local_auth exibir o diálogo biométrico via FragmentManager
• v1.1.3 estável — Estado da fase B1 movido para AuthService.b1DoneNotifier (ValueNotifier estático). Resolve o bug onde o widget era recriado pelo builder e perdia o estado da autenticação

• B1 — Biometria do dispositivo: digital ou face ID, idêntico ao desbloqueio do celular. Ativado automaticamente ao abrir o app
• Após B1: tela neutra — apenas logo e nome. Nenhuma indicação do próximo passo. Usuário sob coação para aqui
• B2 — Padrão de pontos: grade 3×3 (9 pontos, mínimo 4 conectados). Ativado por 3 toques no logo — sem botão, sem texto, sem pista visual
• App trava automaticamente ao ir para background, ao minimizar ou ao apagar a tela (AppLifecycleState.paused/inactive)
• Autenticação B1 exigida antes de assinar qualquer transação de $PLG ou PLG-G
• Padrão configurado no primeiro boot, com instrução clara de como o mecanismo funciona

• FIFO L(t) = R(t−30): data de liberação do vesting agora ancorada no timestamp do vértice minerado, não em datetime.now(). Garante que quem minerar primeiro libera primeiro
• Anchor vertices: vértices com amount=0 permitidos nos primeiros 30 dias da Genesis — necessários para construção da topologia DAG antes de existirem transações reais
• Fee component: a partir do Dia 31, a recompensa inclui 0,1% do valor da transação validada — R = G/N + tx_fee

• Selo pessoal não-transferível para compradores da Genesis Reserve
• Governança (peso_voto, boost, categoria) viaja com o token PLG-G na transferência
• Selo é identidade pessoal — não se transfere com o token e não se recupera se o saldo PLG-G chegar a zero
• Implementado no backend (genesis_contract.py), no app (badge dourado na aba Wallet) e na página /genesis

• Simulação de preço removida do app — qualquer flutuação artificial seria desonesta com o Sócio
• Novo endpoint GET /api/genesis/ultimo_preco: retorna o preço da última venda P2P real
• Fallback: $0,10 USDC (preço de emissão da Genesis) quando nenhuma venda P2P existe ainda
• O app exibe a fonte do preço (Genesis ou P2P) com transparência

• A Rede PLEGMA DAG entra em fase de pré-lançamento oficial a partir desta data.
• A Genesis Reserve será aberta em breve: 10.500.000 PLG-G a $0,10 USDC fixo. A data de abertura será anunciada via blog e email.
• Canal oficial de suporte e comunicação: plegmadag@proton.me
• Todas as funcionalidades da plataforma serão ativadas na data oficial de lançamento.
• A data será comunicada com antecedência via blog e email — botão AVISE-ME disponível em todas as páginas.

• SYNC: ALV_ZKDAG_BNG_GENESIS_2026_FAIRLAUNCH

• Blog reestruturado com linha do tempo completa desde o dia da concepção: 01/02/2026
• Três posts de origem criados: A Ideia, O Nome e A Identidade Visual — narrativa contínua da gênese do projeto
• Posts técnicos e logs de desenvolvimento redistribuídos ao longo do período real de construção
• Data e hora adicionadas a todos os registros para rastreabilidade histórica
• Categorias reorganizadas: Origens e Concepção / Fundamentos Técnicos / Logs de Desenvolvimento

• Android Studio instalado e toolchain Android completo — flutter doctor sem pendências críticas
• Estrutura de pastas Flutter criada: lib/screens/, lib/widgets/, lib/services/, lib/models/
• Tela de Boot implementada: animação logo.gif com barra de progresso e splash em fundo preto/ciano
• Navegação principal configurada: BottomNavigationBar com 5 abas (Home, Wallet, Validator, Shield, Provers)
• Tema global definido: ThemeData com fundo #000000, primária #00F2FF, fontFamily Space Mono
• Serviço de API criado: api_service.dart com métodos para status, saldo e mineração via HTTP

• Página /genesis publicada com contador de supply em tempo real via GET /api/genesis/status
• Formulário de intenção de compra com geração de REF único e QR code de pagamento USDC
• Barra de progresso visual do supply vendido vs disponível atualizada a cada 30 segundos
• Seção de tiers com cards diferenciados: Apoiador ($100–$300 · 1.000–3.000 PLG-G | até 3 min.), Sentinela ($301–$600 · 3.001–6.000 PLG-G | até 6 min.), Master ($601–$1.000 · 6.001–10.000 PLG-G | até 10 min.). Mínimo de aporte: $100 USDC · 1.000 PLG-G.

• Nav unificada em todas as páginas — link /genesis adicionado onde faltava
• auth.js: timeout de sessão tratado com mensagem amigável em vez de tela branca
• dashboard: painel Lattice Shield corrigido — escudo SVG não renderizava em Firefox
• minerador_gui.py: crash corrigido ao iniciar sem GPU detectada — fallback para CPU-only gracioso

• core_consenso.py reescrito: classificação automática de hardware por score (CPU × 50 + RAM × 5 + GPU × 500), tipos VALIDATOR e PROVER
• aerarium.py atualizado: dois pools separados — Validator Pool (60%) e Prover Pool (40%) desde a inicialização
• core_dag.py atualizado: add_transaction() recebe node_type e debita do pool correto via Aerarium
• Vínculo celular→PC: recompensas de PCs sempre vão para o endereço PLG do celular dono
• Cláusula 14ª: fragmentação equitativa de trabalho entre Provers com teto de 10% por nó

• wallet.py: motor central com saldo disponível vs vesting, histórico tipado, transferência assinada Dilithium3
• wallet_app.py: interface mobile minimalista CLI com 3 telas (saldo, enviar, histórico)
• wallet_dashboard.py: interface completa CLI com 6 painéis e breakdown dos pools
• wallet_server.py: API HTTP porta 8083 com 7 rotas — status, vesting, extrato, provers, stats, transferir, vincular
• Liberação automática de vesting após 30 dias com notificação no histórico

• Trava de acesso: sem sessão ativa o dashboard bloqueia com tela de lock e redireciona para QR auth
• Header com botão de sessão no canto superior direito — dropdown com endereço PLG, saldo e logout
• Wallet com accordion na nav — WALLET fixo, sub-itens ENVIAR/EXTRATO/PROVERS colapsáveis
• Painel WALLET: cotação PLG/USDT simulada com gráfico de linha animado, saldo em USDT em tempo real
• Painel PROVERS: tabela com 7 colunas, instrução de vínculo passo a passo, botão BAIXAR MINERADOR (V2.0+), botão DESVINCULAR por linha
• Painel LATTICE SHIELD: escudo SVG lattice grande com telemetria DAG animada sobreposta dentro do escudo
• Painel DESENVOLVEDOR com duas sub-abas: API & Console (status servidores, logs, console de rotas, docs) e CONTRATOS (IDE visual PlegmaScript com syntax highlight, roadmap V2.0+)
• Botão ADQUIRIR $PLG na carteira — pool externa V2.0+ com aviso claro

• hardware_detector.py: detecção real de CPU/RAM/GPU via psutil e nvidia-smi/wmic
• miner_engine.py: loop de mineração em thread separada, conecta à DAG real com fallback para simulação
• miner_server.py: API HTTP porta 8084 expõe status do minerador para o dashboard
• minerador_gui.py: GUI Tkinter com identidade visual do dashboard — fundo escuro, ciano, Space Mono
• Tela de Boot: barra de progresso animada com detecção de hardware em 7 fases, resultado VALIDATOR/PROVER com specs
• Painel Principal: sidebar com controles, 4 cards de métricas (hashrate, total minerado, vértices aceitos, uptime), log colorido em tempo real
• Logo logo.gif animada em 3 locais: topbar, boot screen e sidebar — redimensionada automaticamente
• Empacotado em .exe via PyInstaller — executável standalone sem dependências

• Tecnologia definida: Flutter (iOS + Android, código único em Dart)
• Estrutura de telas MVP definida: Boot, Home, Wallet, Validator, Shield, Provers, Governança (V2.0+)
• Identidade visual: mantém fundo escuro e ciano adaptado para mobile com cards arredondados e gestos nativos
• Flutter SDK instalado: versão 3.41.5 canal stable, Dart 3.11.3
• Android Studio em instalação para completar o toolchain Android

• Protocolo binário proprietário ZKM1 implementado — formato com header, payload RGBA por blocos e prova SHA-256 de 32 bytes
• ZKM Forge: conversor PNG e GIF animado para .zkm com motor de compressão por blocos e fator ajustável
• ZKM Player: Web Component <zkm-img> embeddable em qualquer site — Shadow DOM isolado, verificação de prova automática
• ZKM Viewer: página de preview com suporte a drag-and-drop de arquivos .zkm e guia de integração
• Animação de montagem no carregamento — pixels aparecem gradualmente com efeito visual ciano
• GIF animado preserva todos os frames e timing original via biblioteca omggif
• Prova SHA-256 exibe ZK-VERIFIED ✓ ou PROVA INVÁLIDA ✗ no carregamento

• Auth Server implementado em Python — Challenge/Response com Crystals-Dilithium3
• Nonce criptograficamente seguro via BLAKE3, TTL de 120 segundos, uso único
• Verificação server-side da assinatura Dilithium3 — chave privada nunca sai do dispositivo
• Sessão de 24h com token seguro — single sign-on entre todas as páginas via sessionStorage
• auth.js centralizado — módulo reutilizável incluído em landing, blog e labs
• Simulador de app mobile para testar o fluxo QR sem app nativo
• Polling automático a cada 2s com timer visual e barra de progresso de expiração

• Rede social de inovação coletiva com identidade via carteira PLG
• Filtro híbrido PHR: auto-bloqueio em tempo real + moderação admin
• Fluxo de status: IDEIA → EM VOTAÇÃO → DESENVOLVIMENTO COLETIVO → FORGE → ARSENAL
• Gaveta de Projetos com seções FORGE (em construção) e ARSENAL (concluídos)
• ZKM Forge, ZKM Viewer e ZKM Player registrados no Arsenal como primeiros projetos
• Ciclo mensal automático: top 3 ideias por comentários promovidas para votação no último dia do mês
• Storage persistente entre sessões via artifact storage API

• Nav atualizada: botões BLOG, LABS, ZKM e DASHBOARD em todas as páginas
• Botão DASHBOARD usa QR auth — substituiu input de endereço PLG inseguro
• Seção Economia corrigida: referência ao Motor Ollama removida (V2+), fórmula R=G/N mantida no Aerarium
• Contratos Inteligentes e Pacto dos 5 marcados como V2.0+ no conteúdo público
• Terceiro card adicionado: BLAKE3 + ZK-Press
• Bug CSS corrigido na landing: chave extra no @media 768px

• Criptografia: Ed448 (curva elíptica) substituído por Crystals-Dilithium3 — padrão NIST FIPS 204, resistência pós-quântica real
• Core DAG: fluxo completo integrado — assinatura Dilithium3 + ZK-Press + Aerarium em pipeline único
• API V1.0 validada em ambiente real: GET /api/status · POST /api/mine · GET /api/lastBlock
• Módulos V2.0+ isolados: core_vm (contratos), pacto_dos_5 (ZK-Sharding), app_navegacao — código preservado, fora do escopo MVP
• Tokenomics: lock-up de mineração padronizado para 30 dias em toda a base de código
• Reserva de Gênese 0,05% documentada como extensão fundadora — PLG-G como token de governança com queima dos não-vendidos no Dia 30
• Frontend: escudo SVG atualizado com forma policial, nó DAG rotacionando, estrelas e faixa "Justiça Absoluta"
• Responsividade mobile implementada — sidebar vira drawer, layout 2×2 em telas pequenas
• Bug CSS crítico corrigido no style.css: chave faltando em .plegma-footer corrompendo .tx-list
• telemetry.js conectado à API real via polling — particleCount dinâmico com nos_ativos
• Conexões DAG no visualizador limitadas a 5 por nó — alinhado ao Estatuto §2.1

A marca PLEGMA DAG não foi desenhada; ela foi arquitetada. Cada curva, material e emissão de luz no glifo central responde aos três pilares do protocolo: Segurança, Escalabilidade e Descentralização. Nenhum elemento é decorativo — cada decisão visual tem raiz técnica.

O termo grego Plegma significa "malha" ou "tecido entrelaçado". Diferente de uma blockchain linear e limitada, a logo utiliza uma estrutura de infinito multidimensional. Por que o entrelaçamento? Ele representa a topologia de um DAG: na PLEGMA, as transações não esperam por blocos — elas se entrelaçam em um fluxo contínuo e assíncrono. O "P" escondido: a forma como os feixes se curvam no centro projeta sutilmente a inicial do projeto, unindo identidade nominal à estrutura técnica.

A logo é emoldurada por um anel de metal escovado com fundo de fibra de carbono. A escolha do Carbono simboliza alta resistência e baixo peso — uma metáfora para o protocolo Zk-Press de 22KB, extremamente leve mas matematicamente indestrutível. O Anel Metálico representa o Isolamento e Privacidade Total: a barreira física que protege o registro offline contra interferências externas.

O azul elétrico (Cyan/Electric Blue) que emana das conexões não é meramente estético. Representa a Segurança Quântica: o brilho simula a energia de uma rede viva, protegida por assinaturas baseadas em reticulados (Lattice-based) do protocolo Dilithium3. Os Nós de Dados — pontos de luz nas intersecções — representam os nós da rede verificando transações em tempo real, garantindo o determinismo absoluto.

Localizado na base do anel, este lema é a tradução visual da diretriz de emissão $R=G/N (Aerarium). Na PLEGMA, não existe vantagem para o fundador: a justiça é absoluta — todos, incluindo o Engenheiro Chefe, devem adquirir $PLG sob as mesmas regras de mercado. O lema reforça o compromisso do Fair Launch 2026 e a regra de retenção de 30 dias para mineradores.

A identidade se estende para dois ícones satélites: Plegma Minerador — uma trama geométrica que representa o esforço computacional e a prova de trabalho necessária para a segurança da rede. Segurança Agente (Shield) — um escudo que abriga a molécula de Dilithium3, simbolizando o agente Sentinela protegendo o capital do usuário. SYNC: ALV_ZKDAG_BNG_GENESIS_2026_FAIRLAUNCH

Na sua origem grega, Plegma (πλέγμα) significa algo entrelaçado: uma rede, uma trama, um tecido de fios que se cruzam e se sustentam mutuamente. Não é uma linha. Não é uma cadeia. É uma malha viva onde cada ponto reforça o outro. O nome foi escolhido deliberadamente: ele descreve tanto a estrutura técnica da rede quanto a filosofia social por trás dela — uma comunidade onde cada participante valida e é validado pelos demais.

DAG é a sigla para Directed Acyclic Graph — Grafo Acíclico Dirigido em português. É uma estrutura matemática onde os elementos (vértices) são conectados por arestas com direção, mas sem a possibilidade de formar ciclos: você nunca pode partir de um ponto e retornar a ele seguindo as conexões. Na prática para um protocolo de transações: cada transação aponta para transações anteriores, formando uma teia de confirmações cruzadas em vez de uma fila linear bloqueante. O resultado é escalabilidade natural — quanto mais transações, mais validadores, mais velocidade.

A escolha de DAG no lugar de Chain não foi apenas técnica — foi filosófica. "Chain" (cadeia) carrega a imagem de uma sequência rígida, onde um elo fraco quebra tudo. "Graph" (grafo) carrega a imagem de uma rede resiliente onde múltiplos caminhos coexistem. PlegmaDAG é, portanto, o nome mais honesto que o projeto poderia ter: uma malha entrelaçada construída sobre uma estrutura de grafo acíclico dirigido. O nome é o protocolo.

O ticker $PLG é a contração de Plegma — três letras que encapsulam toda a etimologia. Curto o suficiente para ser lembrado, único o suficiente para não ser confundido. Em exchanges e registros on-chain, $PLG será sempre o marcador de que uma transação pertence à rede entrelaçada — à malha viva que o Engenheiro Chefe começou a desenhar em fevereiro de 2026.

O ponto de partida não foi uma ideia brilhante. Foi uma frustração acumulada. O Engenheiro Chefe passou meses investigando como reduzir o custo de energia das blockchains tradicionais — Bitcoin, Ethereum, e seus derivados. Cada abordagem encontrada custava mais do que pretendia resolver: hardware especializado mais eficiente ainda era caro; algoritmos de consenso alternativos ainda exigiam infraestrutura pesada; soluções de Layer 2 traziam complexidade sem resolver o problema na raiz.

Em um determinado momento, a pergunta mudou. Em vez de "como consumir energia de forma mais barata?", a questão passou a ser: "e se fosse possível consumir muito menos energia?". Não otimizar o consumo — abolir a necessidade de consumo massivo por design. Essa inversão de lógica parece simples enunciada assim, mas exige desmontar décadas de pressuposto sobre como uma rede descentralizada deve funcionar.

Blockchains tradicionais assumem que segurança = gasto de energia: o custo de atacar a rede deve ser proibitivamente alto em termos de poder computacional. É o Proof of Work. O problema é que esse modelo pune todos os participantes honestos pelo potencial comportamento de atores maliciosos. O Engenheiro Chefe percebeu que a segurança poderia vir de outro lugar — da matematicamente indestrutível e da estrutura do grafo, não do desperdício deliberado de ciclos de CPU.

Com essa premissa estabelecida, começou o projeto de um ecossistema onde qualquer dispositivo — inclusive um smartphone de entrada — pudesse ser um nó validador sem consumir mais energia do que já consome em uso normal. A segurança viria de assinaturas criptográficas pós-quânticas (Crystals-Dilithium3) e da estrutura DAG que distribui a validação entre todos os participantes em paralelo. Sem mineração competitiva. Sem energia desperdiçada. Sem barreiras de entrada por capital. Em 01 de fevereiro de 2026, o ecossistema PLEGMA DAG começou a ser projetado.

Primeira bateria diária automatizada executada contra dois ambientes: Sandbox (80.78.26.52) e Produção (api.plegmadag.com). 16 testes em cada — disponibilidade, autenticação, Genesis, segurança (SQLi, XSS, path traversal, oversized), stress concorrente, performance e saúde pós-ataque. Ambos passaram com 16/16.

• Sandbox (80.78.26.52): avg 492ms · p95 1243ms · throughput 15.1 req/s
• Produção (api.plegmadag.com): avg 72ms · p95 122ms · throughput 14.9 req/s
• Resultado: produção é 420ms mais rápida — nginx com SSL e 4 nós âncora distribui carga e termina TLS mais próximo do servidor EU.
• Nó EU directo (213.199.42.88:8080): avg 109ms — o mais rápido dos âncoras. BR / MAL / SIN inacessíveis directamente por firewall (UFW bloqueia porta 8080 externamente — esperado por design).

• SQL Injection (4 payloads) — todos rejeitados com HTTP 400, sem leak, servidor vivo.
• XSS (3 payloads) — nenhum refletido na resposta.
• Path Traversal (5 paths) — HTTP 404 em todos, sem vazamento de ficheiros.
• Oversized Requests (50KB+) — HTTP 400/503, sem crash.
• Rate Limit Auth — HTTP 429 após N requests por IP.
• Stress 200 req / 50 threads (sandbox) — 199/200 OK (99.5%).
• Stress 100 req / 20 threads (produção) — 100/100 OK (100%).

Bateria agendada via Claude Code Remote Agent — 5× por dia (10h, 13h, 16h, 19h, 22h Madrid). Cada execução: testa → revisa falhas → corrige código → commita no repositório. Erros críticos geram alerta imediato.

Após auditoria de 90 testes (score 72%), todos os 8 CVEs críticos foram corrigidos em 4 blocos de patches emergenciais. Novos arquivos criados: tx_verifier.py, dilithium_ffi_service.dart, dilithium_bridge.c, CMakeLists.txt. Arquivos modificados: plegma_db.py, sentinela.py, core_vm.py, auth_server.py, wallet_server.py, genesis_contract.py, crypto_service.dart, build.gradle.kts.

• [CVE-001] CORRIGIDO — /api/mine: verificação Dilithium3 obrigatória via tx_verifier.py. Vértices sem assinatura válida rejeitados com 401.
• [CVE-002] CORRIGIDO — /api/peer/vertex: hash BLAKE3 + assinatura Dilithium3 verificados antes de inserir no DAG. Injeção de vértices fabricados bloqueada.
• [CVE-003] CORRIGIDO — Token previsível PLG_TOKEN_{addr}_{ts} substituído por secrets.token_hex(32). Sessões compartilhadas via tabela sessions no SQLite.
• [CVE-004] CORRIGIDO — Bans do Escudo persistidos em disco com checksum BLAKE3. Carregados antes de abrir sockets. Nós banidos permanecem banidos após restart.
• [CVE-005] CORRIGIDO — /wallet/transferir: sessão Bearer obrigatória + Dilithium3 em cada transferência. Risco financeiro eliminado.
• [CVE-006] CORRIGIDO — transferir_plgg(): ownership verificado por verificar_tx(). Transferência de PLG-G de terceiros bloqueada.
• [CVE-007/008] CORRIGIDO — Flutter: SHA-256 simulado substituído por Dilithium3 via FFI nativo (dilithium_bridge.c + dilithium_ffi_service.dart). Assinatura criptográfica real em toda a cadeia mobile.