Reordenei as 12 linhas do índice oficial de auditoria da Dusk; primeiro agrupei por componentes e depois colei as datas ao lado. Quando a tabela ficou pronta, aquela frase bem fluida — “A Dusk já foi auditada” —, na verdade, não dava mais para escrever exatamente como antes: cada relatório tem o seu próprio objeto e o seu próprio horário, e nenhuma linha é chamada de “certificado total do current code stack”.
As duas últimas entradas são as avaliações de segurança do ERC20 e do BEP20 de abril de 2026. Já os relatórios de protocolo central, consenso, nós, Phoenix etc. caem principalmente em 2023–2024. Não é que seja mais importante o que é novo ou o que é antigo; é que o relatório só consegue falar pelos componentes que ele realmente verificou. Módulos adicionados depois e versões que sofreram mudanças significativas não podem herdar conclusões de relatórios antigos apenas porque o nome do projeto é o mesmo.
Esta tabela realmente mudou a forma como faço a verificação. No futuro, quando eu vir uma divulgação de segurança, eu não vou discutir primeiro “a auditoria tem ou não tem utilidade”; eu vou querer quatro coisas: nome do relatório, componente de fato auditado, data da auditoria e versão correspondente. Só quando as quatro coisas batem é que eu continuo lendo as descobertas e os comprovantes de correção; se só tiver o Logo do projeto ou o Logo da entidade de auditoria, a informação ainda fica no nível da propaganda.
Para $DUSK , essa limitação não é um jeito deliberado de ir contra. Repositório de auditoria público e relatórios rastreáveis já é algo bom; ao definir o escopo com precisão, dá para ver o que já tem evidência e o que, por mudança de versão, precisa de comprovação. Relatórios antigos também não deveriam ser julgados de forma arbitrária como inválidos; apenas não podem garantir automaticamente objetos que não foram cobertos.
Ainda há duas coisas que não dá para inferir a partir dessas 12 linhas. Nesta vez, não houve julgamento da qualidade de cada relatório, nem validação item a item se todos os problemas foram totalmente corrigidos; apenas porque um índice público não lista algum material, isso não prova que ele não exista em outro lugar. @Dusk fornece um índice que serve como porta de entrada — não como o ponto final de conclusões.
Uma frase como “já foi auditado” economiza muitas palavras, mas também economiza a fronteira mais importante. Depois que eu abri essas 12 linhas, a avaliação de segurança finalmente ganhou um sujeito rastreável, um horário e uma versão. Na próxima vez que alguém usar um argumento de todo o projeto para tirar conclusões, eu vou pedir que ele primeiro aponte exatamente qual linha é a base. #dusk
As duas últimas entradas são as avaliações de segurança do ERC20 e do BEP20 de abril de 2026. Já os relatórios de protocolo central, consenso, nós, Phoenix etc. caem principalmente em 2023–2024. Não é que seja mais importante o que é novo ou o que é antigo; é que o relatório só consegue falar pelos componentes que ele realmente verificou. Módulos adicionados depois e versões que sofreram mudanças significativas não podem herdar conclusões de relatórios antigos apenas porque o nome do projeto é o mesmo.
Esta tabela realmente mudou a forma como faço a verificação. No futuro, quando eu vir uma divulgação de segurança, eu não vou discutir primeiro “a auditoria tem ou não tem utilidade”; eu vou querer quatro coisas: nome do relatório, componente de fato auditado, data da auditoria e versão correspondente. Só quando as quatro coisas batem é que eu continuo lendo as descobertas e os comprovantes de correção; se só tiver o Logo do projeto ou o Logo da entidade de auditoria, a informação ainda fica no nível da propaganda.
Para $DUSK , essa limitação não é um jeito deliberado de ir contra. Repositório de auditoria público e relatórios rastreáveis já é algo bom; ao definir o escopo com precisão, dá para ver o que já tem evidência e o que, por mudança de versão, precisa de comprovação. Relatórios antigos também não deveriam ser julgados de forma arbitrária como inválidos; apenas não podem garantir automaticamente objetos que não foram cobertos.
Ainda há duas coisas que não dá para inferir a partir dessas 12 linhas. Nesta vez, não houve julgamento da qualidade de cada relatório, nem validação item a item se todos os problemas foram totalmente corrigidos; apenas porque um índice público não lista algum material, isso não prova que ele não exista em outro lugar. @Dusk fornece um índice que serve como porta de entrada — não como o ponto final de conclusões.
Uma frase como “já foi auditado” economiza muitas palavras, mas também economiza a fronteira mais importante. Depois que eu abri essas 12 linhas, a avaliação de segurança finalmente ganhou um sujeito rastreável, um horário e uma versão. Na próxima vez que alguém usar um argumento de todo o projeto para tirar conclusões, eu vou pedir que ele primeiro aponte exatamente qual linha é a base. #dusk