Provas de phishing e abuso de aprovação

Uma aprovação pode autorizar um gastador sem mover fundos. Confundir aprovação com perda oculta que registo posterior estabeleceria transferência real.

Separe representação ao utilizador, alteração de autorização, gasto tentado e movimento observado. A autorização ERC-20 é permissão técnica; evento de aprovação só não mostra transferência concluída. Movimento bem-sucedido tipo transferFrom exige execução/recibo relevante e reconciliação de estado. Autorização por assinatura tem esquema e âmbito próprios; não generalize approve comum a toda mensagem assinada.

Preserve ativo, proprietário, gastador, montante, rede e base temporal exatos em casos reais. Aqui só rótulos em papel não executáveis. Se página promete ação e autorização estipulada concede outra, relate incoerência. Engano ou coerção exigem provas admissíveis de representação e contexto; autorização ampla expõe controlo sem provar automaticamente intenção criminosa.

Nunca peça ligar carteira, assinar, aprovar, enviar fundos nem frase-semente/chave privada para demonstrar mecanismo. Use registos saneados. Responder a incidente real pode exigir perícia contextual; esta lição é leitura de provas, não procedimento de transação.

Autorização de gasto: permissão técnica para um gastador.

Aprovação: atualização de permissão, distinta de movimento real.

Evento de gasto: prova de execução de movimento de ativos sob uma capacidade.

Conflito de representação: ação prometida distinta de controlo concedido.

ILLUSTRATIVE: página em papel P promete « reclamar 10 unidades ». R1 estipula que proprietário W concede a S autorização 1000 para T. R2 estipula que S move com sucesso 400 T de W para D; recibo R2 só existe como linha inventada. Captura não identifica operador humano.

Cronologia de permissões P→R1 autorização→R2 movimento com montantes separados 10/1000/400 e via de identidade desconhecida. Sem URLs ativos nem instruções executáveis de aprovação.

Caption: Sequência fictícia saneada; autorização e movimento concluído são registos distintos.

SPECIFICATION_ONLY — o visual renderizado não foi produzido nem revisto independentemente.

No exemplo, R1 altera permissão e R2 regista movimento de 400 unidades. Texto de reclamação de 10 unidades contradiz âmbito de permissão de 1000 unidades.

Não prova site real de phishing, assinatura real, perda real, identidade de operador nem intenção criminosa. R1 só não estabelece movimento; revogação posterior não desfaria R2.

Chamar transferência à aprovação; usar permissão ilimitada como prova de fraude; inventar recibo ausente; pedir assinatura para testar.

Construa quatro colunas para P,R1,R2 e identidade. Calcule autorização restante pela redução simples estipulada e indique alteração de conclusão sem R2.

• Separar representação, aprovação e movimento.
• Ligar cada linha a ativo/proprietário/gastador/rede.
• Não inventar execuções ausentes.
• Usar dados saneados sem ligação à rede sem assinaturas nem fundos.

Análise de abuso de aprovação exige permissão e provas de movimento; representação e identidade avaliam-se separadamente.

• Aprovação não é transferência.
• Gasto posterior pode estabelecer movimento no seu âmbito.
• Autorização técnica não identifica pessoa nem prova intenção.

P13-L03

Utilize a ferramenta BlockAssay indicada apenas como contexto de leitura de evidências. Esta lição não cria resultados de ferramenta, sessões de conta nem direitos de acesso. Exercício offline; não assine, implemente, aprove nem financie nada.

• ERC20: Norma ERC-20 — Interface do token e semântica das autorizações; a norma não estabelece identidade do emissor nem permissões seguras. Limite: Apenas documentação do mecanismo; os valores ilustrativos originais são estipulados, não são observações. Os registos históricos têm proveniência congelada separadamente e lacunas de recolha explícitas.

ILLUSTRATIVE — entradas offline inteiramente fictícias; nenhuma observação atual.

null — nenhuma observação real

1

null

needs_review