Lista de verificação de integração de tokens

Siga esta lista de verificação ao interagir com tokens arbitrários. Certifique-se de entender os riscos associados a cada item e justifique quaisquer exceções a essas regras.

Por conveniência, todos os utilitários (opens in a new tab) do Slither podem ser executados diretamente em um endereço de token, como:

Tutorial de uso do Slither

slither-check-erc 0xdac17f958d2ee523a2206206994597c13d831ec7 TetherToken

Para seguir esta lista de verificação, você vai querer ter esta saída do Slither para o token:

- slither-check-erc [target] [contractName] [optional: --erc ERC_NUMBER]
- slither [target] --print human-summary
- slither [target] --print contract-summary
- slither-prop . --contract ContractName # exige configuração, e o uso do Echidna e do Manticore

Considerações gerais

• O contrato possui uma revisão de segurança. Evite interagir com contratos que não tenham uma revisão de segurança. Verifique a duração da avaliação (também conhecida como “nível de esforço”), a reputação da empresa de segurança e o número e a gravidade das descobertas.
• Você entrou em contato com os desenvolvedores. Você pode precisar alertar a equipe deles sobre um incidente. Procure contatos apropriados em blockchain-security-contacts (opens in a new tab).
• Eles têm uma lista de e-mails de segurança para anúncios críticos. A equipe deles deve avisar os usuários (como você!) quando problemas críticos forem encontrados ou quando ocorrerem atualizações.

Conformidade com ERC

O Slither inclui um utilitário, slither-check-erc (opens in a new tab), que revisa a conformidade de um token com muitos padrões ERC relacionados. Use o slither-check-erc para revisar se:

• Transfer e transferFrom retornam um booleano. Vários tokens não retornam um booleano nessas funções. Como resultado, suas chamadas no contrato podem falhar.
• As funções name, decimals e symbol estão presentes, se usadas. Essas funções são opcionais no padrão ERC-20 e podem não estar presentes.
• Decimals retorna um uint8. Vários tokens retornam incorretamente um uint256. Se for esse o caso, certifique-se de que o valor retornado seja inferior a 255.
• O token mitiga a conhecida condição de corrida do ERC-20 (opens in a new tab). O padrão ERC-20 tem uma condição de corrida conhecida que deve ser mitigada para evitar que invasores roubem tokens.
• O token não é um token ERC-777 e não tem chamada de função externa em transfer e transferFrom. Chamadas externas nas funções de transferência podem levar a reentrâncias.

O Slither inclui um utilitário, slither-prop (opens in a new tab), que gera testes unitários e propriedades de segurança que podem descobrir muitas falhas comuns de ERC. Use o slither-prop para revisar se:

• O contrato passa em todos os testes unitários e propriedades de segurança do slither-prop. Execute os testes unitários gerados e, em seguida, verifique as propriedades com o Echidna (opens in a new tab) e o Manticore (opens in a new tab).

Por fim, existem certas características que são difíceis de identificar automaticamente. Revise essas condições manualmente:

• Transfer e transferFrom não devem cobrar uma taxa. Tokens deflacionários podem levar a comportamentos inesperados.
• Os juros potenciais ganhos com o token são levados em consideração. Alguns tokens distribuem juros aos detentores de tokens. Esses juros podem ficar presos no contrato se não forem levados em consideração.

Composição do contrato

• O contrato evita complexidade desnecessária. O token deve ser um contrato simples; um token com código complexo exige um padrão de revisão mais alto. Use o human-summary printer (opens in a new tab) do Slither para identificar códigos complexos.
• O contrato usa SafeMath. Contratos que não usam SafeMath exigem um padrão de revisão mais alto. Inspecione o contrato manualmente quanto ao uso do SafeMath.
• O contrato tem apenas algumas funções não relacionadas a tokens. Funções não relacionadas a tokens aumentam a probabilidade de um problema no contrato. Use o contract-summary printer (opens in a new tab) do Slither para revisar amplamente o código usado no contrato.
• O token tem apenas um endereço. Tokens com vários pontos de entrada para atualizações de saldo podem quebrar a contabilidade interna baseada no endereço (por exemplo, balances[token_address][msg.sender] pode não refletir o saldo real).

Privilégios do proprietário

• O token não é atualizável. Contratos atualizáveis podem mudar suas regras ao longo do tempo. Use o human-summary printer (opens in a new tab) do Slither para determinar se o contrato é atualizável.
• O proprietário tem capacidades limitadas de cunhagem. Proprietários mal-intencionados ou comprometidos podem abusar das capacidades de cunhagem. Use o human-summary printer (opens in a new tab) do Slither para revisar as capacidades de cunhagem e considere revisar o código manualmente.
• O token não é pausável. Proprietários mal-intencionados ou comprometidos podem prender contratos que dependem de tokens pausáveis. Identifique códigos pausáveis manualmente.
• O proprietário não pode colocar o contrato em uma lista de bloqueio (blacklist). Proprietários mal-intencionados ou comprometidos podem prender contratos que dependem de tokens com uma lista de bloqueio. Identifique recursos de lista de bloqueio manualmente.
• A equipe por trás do token é conhecida e pode ser responsabilizada por abusos. Contratos com equipes de desenvolvimento anônimas ou que residem em paraísos fiscais devem exigir um padrão de revisão mais alto.

Escassez de tokens

As revisões de problemas de escassez de tokens exigem revisão manual. Verifique estas condições:

• Nenhum usuário possui a maior parte do suprimento. Se alguns usuários possuírem a maioria dos tokens, eles poderão influenciar as operações com base na repartição do token.
• O suprimento total é suficiente. Tokens com um suprimento total baixo podem ser facilmente manipulados.
• Os tokens estão localizados em mais do que apenas algumas exchanges. Se todos os tokens estiverem em uma exchange, o comprometimento da exchange pode comprometer o contrato que depende do token.
• Os usuários entendem os riscos associados a grandes fundos ou empréstimos relâmpago (flash loans). Contratos que dependem do saldo do token devem levar em consideração cuidadosamente invasores com grandes fundos ou ataques por meio de empréstimos relâmpago.
• O token não permite cunhagem relâmpago (flash minting). A cunhagem relâmpago pode levar a oscilações substanciais no saldo e no suprimento total, o que exige verificações rigorosas e abrangentes de overflow na operação do token.