Anatomia de uma carteira

Master de origem EN · P09-L01 · 45 minutos estimados · needs_review

Uma página de carteira pode combinar um endereço, várias contas de tokens, chamadas de contrato e rótulos de fornecedor num ecrã. Essa conveniência não os torna um só objeto do registo ou uma pessoa. Antes de ler o histórico, definir o que a página realmente representa.

Mapeará papéis de contas e reconciliará saldos fornecidos sem atribuir identidade. É a competência inicial do programa: qualquer afirmação posterior sobre financiamento, antiguidade e relações depende da unidade de observação correta.

Separar a interface do objeto

Uma aplicação de carteira é uma interface, enquanto uma conta é um objeto do registo; a documentação Ethereum explicita esta distinção [S09-ETHACCOUNTS]. Uma interface pode mostrar várias contas e redes. Uma conta pode ser acessível por várias interfaces. Nenhuma relação identifica um ser humano único.

Usar rede e endereço completo como identificador inicial. Um rótulo abreviado não estabelece igualdade. Texto igual em cadeias diferentes não é um objeto contabilístico partilhado. O agrupamento «carteira» de um fornecedor pode incluir relações inferidas; examinar a definição antes de o tratar como total de proprietário.

No trabalho real validar codificação do endereço e registar a rede selecionada. O exercício usa deliberadamente rótulos inválidos, pelo que comparações são apenas educativas e nenhuma transação pode visar estes identificadores.

Identificar o papel da conta

Contas Solana guardam estado em endereços e têm um campo de programa proprietário [S09-ACCOUNTS]. Esse campo não é identidade humana. Uma conta de tokens regista separadamente mint e autoridade proprietária [S09-TOKENS]. Não interpretar a propriedade base do Token Program como significando que o programa beneficia de todos os saldos de tokens.

Uma autoridade pode possuir várias contas de tokens para um mint. Agregar apenas mint exato, contexto correspondente e campos de autoridade sustentados. Saldo nativo e saldo de tokens são unidades diferentes. Nunca somar como ativo único nem converter em dólares sem fonte explícita de valorização.

Registar se o endereço designa programa, conta de tokens, mint ou outra conta de estado. O mesmo grafo pode conter todos esses tipos de nó. Um grafo com cinco nós não mostra cinco carteiras, muito menos cinco pessoas.

Compreender atividade controlada por programa

Endereços Solana derivados de programa (PDA) derivam de ID de programa e sementes e não têm chave privada; o programa derivador pode assinar por eles através do mecanismo de execução [S09-PDA]. Derivação por si só não afirma que já existe conta alocada nesse endereço. Verificar relação de endereço e estado relevante da conta.

Não colapsar assinatura de programa e humana num campo. Uma autoridade mediada por programa pode servir muitos utilizadores. Regras da aplicação determinam que pedidos a fazem agir; um rótulo PDA não estabelece utilizador individual nem controlo irrestrito.

Nas redes EVM distinguir controlo normal por chave, lógica de contrato e mecanismos de delegação suportados. Uma conta externa (EOA) é controlada por chave privada; delegação suportada pode determinar o código executado. EIP-7702 permite delegação de código para EOA em redes compatíveis [S09-DELEGATION]. Presença de código sozinha não é regra universal «isto não pode ser uma EOA». Examinar regras da rede e estado da conta no contexto pedido.

Uma conta com código pode executar instruções sem provar que humano beneficia. Um contrato multisig pode representar várias contas signatárias, mas contá-las não prova pessoas independentes. Separar mecanismo de controlo e atribuição humana.

Construir mapa de papéis antes do mapa de propriedade

Usar tipo de nó, identificador exato, rede, contexto e localizador de evidência. Usar arestas de proprietário de conta de tokens, referência de mint, derivação de programa e delegação de código. Têm significados específicos. Uma aresta genérica «relacionado com» esconde a razão da ligação.

Não transformar todas as arestas em propriedade comum. Referência de mint liga todos os detentores de um ativo sem os tornar um controlador. Derivação liga endereço a mecanismo, não necessariamente ao inventário pessoal do operador do programa.

Rótulos de fornecedor pertencem a anotação separada com proveniência e estado de verificação. «Serviço de custódia» pode ser pista útil, mas editor, data de atualização e fundamento exigem inspeção. Registar como afirmação de fornecedor até corroborar suficientemente.

Reconciliar os saldos fornecidos

O conjunto fornece contas de tokens exaustivas para autoridade W e um mint alvo em S0. Essa completude é hipótese do exercício, não capacidade afirmada de Wallet Intelligence. Somar os dois saldos válidos só após confirmar proprietário e mint.

Uma terceira conta do mesmo mint sob autoridade derivada de programa não é saldo de W só por aparecer no mesmo ecrã. Um saldo de mint diferente não entra no total alvo. Unidades nativas ficam separadas.

Se registos reais forem parciais, apresentar total dos saldos devolvidos e limitação de cobertura. Não o promover silenciosamente a «todos os saldos». Consulta falhada é evidência indisponível, não inventário zero. Montante zero fornecido é medição no âmbito declarado.

Declarar os limites construtivamente

Um bom resultado pode dizer «W é a autoridade fornecida para T1/T2 com MINT-A; P1 é autoridade separada mediada por programa. Controlo humano desconhecido». Responde à pergunta sobre conta sem resolver identidade não sustentada.

O pedido seguinte deve corresponder à lacuna: enumeração completa proprietário/mint para saldos ausentes, registos de derivação/estado para classificar PDA e autorização da aplicação para controlo mediado. Pedir nome de pessoa não substitui essas verificações técnicas.

Nenhum papel de conta produz sinal BUY/SELL. Ter contrato, PDA ou conta de tokens indica organização das observações. Não estabelece legitimidade, intenção ou comportamento futuro do mercado.

• Endereço: identificador delimitado pela rede.
• Conta: objeto de estado num endereço.
• Interface de carteira: aplicação que mostra ou interage com contas.
• Autoridade proprietária: campo que governa uma conta de tokens especificada.
• PDA: endereço derivado de programa com assinatura na execução.
• Delegação: relação de execução da conta, não afiliação pessoal.

ILLUSTRATIVE — FIX-P09-01. SIM-SOL-A no S0 fictício; saldos já normalizados. Autoridade alvo W, mint alvo MINT-A. T1/T2 são estipulados exaustivos para W/MINT-A.

A 7 é exemplo numa rede separada. Não são fornecidos registos de identidade, valorização, limiar de assinatura ou autorização da aplicação.

OBSERVED no conjunto: W é autoridade proprietária para T1/T2; P1 é autoridade distinta derivada de programa para T4. O fornecedor publica A 8.

INFERRED: saldos MINT-A fornecidos de W totalizam 200 tokens. Os seus 2 nativos e MINT-B50 são quantidades separadas.

UNKNOWN: identidade humana por trás de W/P1/E1, regras de controlo da aplicação e propriedade beneficiária.

INSUFFICIENT EVIDENCE: A 8 não estabelece identidade de Alice. Mint partilhado não funde W e P1. Delegação de código não estabelece afiliação com editor de LOGIC-D.

Tratar interface de carteira como pessoa; confundir programa proprietário base e autoridade proprietária de tokens; somar unidades diferentes; fundir detentores do mesmo mint; aplicar classificação obsoleta código/sem código sem contexto de rede.

Desenhar mapa tipado de papéis de A 1–A 7. Calcular saldos alvo de W. Classificar A 8 e explicar por que T4 fica fora do total de W. Identificar duas verificações ausentes para atividade controlada por programa.

• Selecionar rede exata e unidade de observação.
• Tipar todos os nós e relações.
• Separar saldos nativos e de mint.
• Agregar apenas campos sustentados de proprietário.
• Distinguir controlo por programa/chave/delegação.
• Preservar rótulos como afirmações até corroborar.

Anatomia de carteira é mapa de objetos do registo e mecanismos de controlo. Estabelece o que inspecionar sem equiparar endereços a pessoas.

Uma interface não é conta nem pessoa. Relações tipadas evitam agregação falsa. Rótulos de fornecedor e comportamento do código não provam identidade.

Desenhar nós tipados W,T1,T2,T3,P1,T4 e mint com arestas rotuladas de autoridade/mint/derivação. Destacar apenas alvo200. Isolar unidades nativas e MINT-B e separar delegação EVM. Colocar A 8 em anotação de rótulo não verificado.

Anatomia ilustrativa de conta; nós do grafo não são pessoas.

Usar SVG/HTML determinista ou gráficos com unidades, localizadores de evidência e alternativas textuais. Azul-marinho/preto com ciano, azul elétrico e violeta discretos; sem capturas decorativas ou fabricadas de exploradores. A 390px empilhar anotações; verificar 768px, computador e RTL árabe quando os recursos forem implementados. Manter identificadores LTR e direções factuais de tempo/arestas/eixos inalteradas. Usar apenas a marca oficial BlockAssay fornecida. Ambos os registos visuais continuam especificações.

WALLET_INTELLIGENCE corresponde à inspeção só de leitura de registos de endereços públicos, relações e proveniência. Verificar rede suportada, identificadores exatos, campos e cobertura antes de integrar na execução; não se afirma aqui qualquer capacidade de fornecedor em direto. Usar o exercício offline incluído se faltarem dados ou acesso pago. Não é necessária ligação de carteira, credenciais, chave privada, assinatura ou operação real de mercado. Dados ausentes continuam desconhecidos. Progresso Academy, estatuto de criador, pagamentos e referências nunca alteram evidência Radar.

• Contas Solana — Estado endereçado e campo de programa proprietário. Verificado em 2026-09-30.
• Ativos Solana — Distinções entre mint, conta de tokens e autoridade proprietária. Verificado em 2026-09-30.
• Endereços Solana derivados de programa — Endereços derivados de programa e assinatura pelo programa; sem chave privada de PDA. Verificado em 2026-09-30.
• Contas Ethereum — Distinção conta/interface e tipos de conta. Verificado em 2026-09-30.
• EIP-7702: definir código para EOA — Delegação de código de EOA; presença de código por si só não é regra universal de classificação de EOA. Verificado em 2026-09-30.

Todos os registos de exemplo são conjuntos originais ILLUSTRATIVE, não medições históricas/em direto da cadeia. A documentação explica mecanismos, não montantes ou rótulos inventados. A cronologia sintética é explicitamente delimitada; observedAt=null é intencional. OBSERVED num exercício significa um registo fornecido do conjunto. Rever documentação e descodificação implementada antes de publicar. Rótulos de fornecedor não estabelecem identidade; controlo de endereços e atribuição humana exigem evidências distintas.

P09-L02 após o exercício resolvido e a revisão das perguntas.