Antiguidade e comportamento da carteira

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

Página com «carteira de 25 dias» pode significar realmente25 dias desde primeiro registo devolvido por um indexador. A conta pode ter existido ou agido antes. Gráfico tranquilo também pode refletir intervalo ausente em vez de inatividade.

Esta lição substitui rótulos vagos de idade e comportamento por janelas definidas, contagens de eventos e descrições ajustadas à cobertura. Nunca transforma idade observada em criação real nem atividade em julgamento de pessoa.

Definir precisamente primeira observação

Primeira observação exige fonte, consulta, rede, alvo e regra de atividade. Primeira assinatura, primeira transferência bem-sucedida, primeira ação de saída e primeiro evento de conta de tokens podem ocorrer em pontos diferentes. Nomear regra escolhida antes de apresentar idade.

Consultas de assinaturas Solana devolvem histórico que referencia endereço, mais recente primeiro e paginado [S09-SIGNATURES]. Linha devolvida mais antiga é apenas primeiro registo visível nessa consulta. Mesmo paginação bem-sucedida não estabelece automaticamente histórico anterior completo de todas as contas associadas ou de toda a retenção do fornecedor.

Afirmação de criação real exige mecanismo relevante e evidência. Chave pode existir privadamente antes de aparecer nos registos; momento de implantação de contrato refere-se ao contrato, não à geração da chave do criador ou à primeira carteira de uma pessoa. Criação de conta de tokens refere-se à conta específica, não necessariamente à existência do proprietário.

Separar relógios e contextos

Contexto do registo, tempo do evento apresentado, tempo de captura da fonte e tempo da análise são diferentes. Respostas de transação Solana podem ter blockTime null [S09-TRANSACTION]. Se tempo do evento ausente, manter contexto de slot sem inventar instante de calendário.

O conjunto fornece deslocamentos artificiais de dias de calendário para aritmética. Não foram recolhidas observações reais de relógio e observedAt continua null. SIM-DAY6 não codifica data real. Subtrair deslocamentos fornecidos dá apenas dias sintéticos decorridos.

Intervalo do dia6 ao dia29 é de 23 dias decorridos. Contar extremos de calendário rotulados daria24 posições de data, quantidade diferente. Especificar se mede tempo decorrido, conta datas ou define intervalo semiaberto. Não alternar convenções para aumentar atividade aparente.

Publicar cobertura antes das taxas

Usar janelas semiabertas como [5,31): incluir dia5 e excluir dia31. Assim janelas adjacentes não se sobrepõem. Lacuna [15,21) remove seis dias de cobertura fornecida. Não a rotular «inativa» quando fonte não a observou.

Se intervalos cobertos são estipulados completos para regra escolhida, eventos divididos por dias cobertos é taxa descritiva ajustada à cobertura. Não estima acontecimentos nos dias ausentes. Dividir pela janela inteira responde pergunta diferente que deve ser nomeada explicitamente.

Taxa de 0.25 eventos bem-sucedidos por dia coberto significa cinco eventos fornecidos em vinte dias cobertos. Não significa transação a cada quarto dia. Agrupamento dentro dos dias importa e não se assume uniformidade da atividade.

Escolher medidas de comportamento

Contar eventos bem-sucedidos separados de tentativas. Contar dias ativos distintos separados de eventos. Várias transações num dia podem aumentar eventos mantendo contagem de dias ativos.

Definir ativo e direção. Registo de mera receção não é necessariamente iniciação ativa pelo alvo. Eventos que referenciam endereço não provam assinatura. Para medir transações iniciadas, precisa de evidência de signatário ou remetente, não apenas atividade envolvendo endereço.

Variação líquida de saldo não mede competência de negociação. Carteira pode receber alocações, transferir ou custodiar ativos de outros. Esta lição usa só contagens descritivas, sem classificações de lucro, sofisticação ou estratégia.

Tratar observações parciais honestamente

Primeiro evento visível na janela pedida dá afirmação delimitada: observado desde esse evento no âmbito disponível. Se cobertura começa quando conta já tem fundos, mesmo primeiro financiamento visível não é evidência completa de origem.

Ausência de linhas num intervalo totalmente verificado pode sustentar «nenhum evento correspondente devolvido sob esta regra». Não estabelece ausência de atividade noutra rede, mint ou conta relacionada. Dados ausentes do fornecedor não sustentam ausência nesse intervalo.

Não extrapolar para lacunas. Carteira sem eventos devolvidos durante falha conhecida não pode ser descrita como dormente nesse período. Grafo deve desenhar região desconhecida explicitamente sombreada em vez de barra zero que parece zero medido.

Evitar rótulos pessoais de comportamento

«Adotante precoce», «bot», «negociador experiente» ou «pessoa nova» exigem definições e evidência mais fortes. Padrões temporais motivam hipóteses mas não provam automatização ou identidade. Cadência igual pode resultar de ações programadas da aplicação ou granularidade de indexação.

A conta pode mudar arranjo de controlo ao longo do tempo. Continuidade de atividade pública não prova que o mesmo humano operou cada evento. Ações mediadas por contrato e execução delegada complicam hipótese de utilizador manual único [S09-ETHACCOUNTS; S09-DELEGATION].

Não ordenar confiança por idade. Histórico observado mais antigo estabelece período visível mais longo sob fonte declarada, não honestidade. Primeira observação recente não estabelece utilizador novato nem operador malicioso.

Escrever descrição de atividade delimitada

Relatório útil nomeia regra, janela, lacunas, primeiro e último eventos correspondentes visíveis, contagem e convenção temporal. Depois declarar limites de criação e controlo explicitamente.

Preferir «cinco eventos bem-sucedidos de transferência referenciados em quatro dias ativos cobertos; histórico anterior e seis dias ausentes não resolvidos» a «carteira ativa experiente». O primeiro é reproduzível e permite recalcular com melhor cobertura.

• Primeira observação: evento correspondente mais antigo visível sob fonte/regra especificadas.
• Intervalo observado: tempo decorrido entre primeiro e último eventos fornecidos.
• Dia coberto: dia incluído no âmbito verificado do conjunto.
• Dia ativo: data coberta com evento correspondente.
• Janela semiaberta: inclui início, exclui fim.
• Taxa descritiva: contagem dividida por denominador de observação declarado.

ILLUSTRATIVE — FIX-P09-05. SIM-CHAIN-A / W. Deslocamentos SIM-DAY são rótulos inventados de dias de calendário. Janela de consulta[5,31), cobertura completa para regra de transferências listada salvo lacuna[15,21). Histórico anterior ao dia5 indisponível. Corte de análise dia31.

Montantes normalizados de um ativo fictício. Sem campos de signatário, registo de criação anterior ou evidência de identidade fornecidos. Regra de atividade bem-sucedida inclui ambas as direções e exclui tentativas falhadas.

OBSERVED no conjunto: sucessos correspondentes nos dias 6,10,22,29; dia12 é tentativa falhada; seis dias sem cobertura.

INFERRED: cinco sucessos em quatro dias ativos cobertos; intervalo decorrido primeiro-último de 23 dias;25 dias desde primeiro sucesso visível no dia de análise31.

UNKNOWN: criação real, atividade antes de dia5/na lacuna, iniciação/signatários e continuidade humana.

INSUFFICIENT EVIDENCE: idade observada 25 não pode ser apresentada como idade real de criação. Intervalo ausente não estabelece inatividade; frequência não prova perícia nem automatização.

Tratar registo mais antigo da página como criação; usar tempo null como zero; trocar dias decorridos e inclusivos; transformar falhas da fonte em atividade zero; atribuir competência ou identidade pela cadência.

Calcular duração da janela inteira, dias ausentes/cobertos, eventos bem-sucedidos e dias ativos, taxa por dia coberto e intervalo decorrido. Reescrever «W foi criada25 dias antes e permaneceu inativa seis dias».

• Nomear fonte de primeira observação e regra de atividade.
• Separar eventos bem-sucedidos de tentativas/iniciações.
• Usar convenções explícitas de intervalo.
• Publicar lacunas antes das taxas.
• Manter tempo de calendário null desconhecido.
• Evitar rótulos de criação, competência ou pessoa pela idade observada.

Antiguidade da carteira é frequentemente intervalo de observação. Estatísticas de comportamento são úteis quando regra dos eventos e denominador de cobertura ficam visíveis.

Primeira observação não é criação. Sem dados não é sem atividade. Cadência descreve eventos fornecidos, não identidade ou competência pessoal.

Cronologia[5,31) com lacuna[15,21) hachurada UNKNOWN, marcadores de evento/tentativa e eventos duplos do dia10. Mostrar26 no total/6 ausentes/20 cobertos; primeiro 6,último29,análise31 como marcadores distintos. Nunca rotular primeira observação como criação.

Atividade observada ilustrativa; dias sintéticos não são instantes do registo.

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.

• Solana getSignaturesForAddress — Histórico de assinaturas que referenciam o endereço, ordem da mais recente à mais antiga e paginação. Verificado em 2026-09-30.
• Solana getTransaction — Consulta de transações, compromisso de confirmação e campos de dados/tempo que podem ser nulos. 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-L06 após o exercício resolvido e a revisão das perguntas.