- Revisão de Segurança Mínima de Contratos Inteligentes
- Índice
- Sobre o projeto / Documentação
- Estatísticas
- Configuração
- Escopo da Revisão de Segurança
- Funções
- Problemas Conhecidos
Resumo do projeto. Quanto mais documentação, melhor.
Use algo como métricas do solidity ou cloc para obter estes dados.
- nSLOC: XX
- Pontuação de Complexidade: XX
- Cronograma da Revisão de Segurança: Data -> Data
Quais ferramentas são necessárias para configurar a base de código e o conjunto de testes?
Exemplo:
forge init
forge install OpenZeppelin/openzeppelin-contracts --no-commit
forge install vectorized/solady --no-commit
forge build
Como executar os testes. Como ver a cobertura dos testes.
Example:
forge test
Os detalhes específicos da revisão de segurança. Defina exatamente o que o protocolo está planejando implantar e como planeja implantá-lo.
- Versão do Solc: XXX
- Redes para implantação do contrato:
- XXX (ex: ETH)
- XXX (ex: Arbitrum)
- Tokens:
- XXX (ex: ERC20s)
- XXX (ex: LINK: <endereço>)
- XXX (ex: USDC: <endereço>)
- XXX (ex: ERC721s)
- XXX (ex: CryptoKitties: <endereço>)
- Liste os ERC20s esperados e outros tokens específicos. Se um protocolo deve funcionar com múltiplos ou quaisquer tokens de um determinado padrão, você pode fazer algo como "Todos os ERC20s". Ou uma lista ordenada como "USDC: <Endereço USDC>" etc
- XXX (ex: ERC20s)
Quais são os diferentes atores do sistema? Quais são seus poderes? O que eles devem/não devem fazer?
Exemplo:
Atores:
Comprador: O comprador dos serviços, neste cenário, um projeto comprando uma auditoria.
Vendedor: O vendedor dos serviços, neste cenário, um auditor disposto a auditar um projeto.
Árbitro: Um ator imparcial e confiável que pode resolver disputas entre o Comprador e o Vendedor.
O Árbitro só é compensado com o valor da taxa de arbitragem se ocorrer uma disputa.
Liste quaisquer problemas que a equipe do protocolo está ciente e não irá reconhecer/corrigir.