Fonte de financiamento

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

«Financiado por X» pode significar remetente imediato, fonte anterior visível, rótulo de serviço ou origem humana última. São afirmações diferentes. Histórico incompleto pode sustentar primeiro evento de entrada visível mantendo fundos iniciais e proveniência anterior desconhecidos.

Reconstruirá caminho de financiamento delimitado, distinguirá financiamento nativo e em tokens e declarará histórico anterior ausente. Financiamento comum continua observação de relação, não prova de proprietário comum.

Definir financiamento para a pergunta

Especificar ativo, alvo e finalidade. Unidades nativas para pagar taxas diferem de tokens recebidos para outra atividade. Se carteira recebe token sem entrada nativa fornecida, não se pode assumir que o evento explica saldo para taxas.

«Primeira transferência nativa de entrada visível» é regra reproduzível. «Financiador original» é mais forte: exige histórico anterior e definição clara de origem. Uma imagem de estado com saldo inicial já estabelece que a janela não explica cada unidade.

Usar endereço alvo exato e contas de tokens relevantes. Enumeração Solana por proprietário filtra por mint ou programa [S09-OWNERS]; fornece relação de conta, não humano por trás do financiamento. Não fundir ativos porque aparecem na mesma interface.

Separar fonte imediata e histórico anterior

Transferência direta bem-sucedida pode identificar conta de origem imediata segundo mecanismo descodificado. Não identifica quem a instruiu, se representa serviço ou de onde vieram os fundos em última análise.

Caminho de dois saltos A→HUB→W regista duas operações. Num modelo de saldos por conta, fundos recebidos podem misturar-se com inventário anterior. Caminho cronológico não estabelece que as unidades exatas recebidas por W sejam exclusivamente as enviadas por A. Explicar hipótese de alocação se tentar atribuição de fluxo.

Nesta lição não alocar unidades particulares através do hub. Apresentar caminho fornecido e limites. Grafo pode ser útil sem fingir rastreio de moedas identificáveis de forma única através de saldos fungíveis.

Distinguir mecanismos dos eventos

Transferência de tokens, emissão, recompensa, reembolso e operação de ponte podem alterar inventário. Não são arestas de fonte intercambiáveis. Operação descodificada de emissão por ponte identifica mecanismo local sem identificar depositante original entre cadeias.

Não chamar reembolso a uma transferência de retorno só por seguir uma saída anterior. Rótulo exige evidência de mecanismo ou contexto. Da mesma forma, pagamento de endereço rotulado como plataforma de negociação é pagamento desse endereço com rótulo não verificado até a proveniência sustentar serviço alegado.

Instruções e metadados de resultado fornecem vistas de mecanismo para inspeção [S09-STRUCTURES]. Documentação explica campos; não autentica rótulos económicos de fornecedor nem registos inventados do exercício.

Registar cobertura antes de escolher primeiro evento

Histórico de assinaturas Solana é paginado com mais recentes primeiro [S09-SIGNATURES]. Item mais antigo numa página é apenas o mais antigo dessa página. Âmbito de pesquisa, paginação e retenção do fornecedor determinam atividade anterior que pode faltar.

Obter sucesso e montantes separadamente da lista de descoberta. Resultado null de transação no compromisso pedido é evidência indisponível [S09-TRANSACTION]. Não inserir montante ou remetente presumidos no grafo para ligar uma lacuna.

Fixar janela de observação. Quando saldo inicial é fornecido mas origem não, desenhar lacuna rotulada de histórico anterior em vez de tratar primeira transferência posterior como criação de conta. Primeiro financiamento visível não é necessariamente verdadeiro primeiro financiamento.

Reconciliar saldo delimitado

Para janela declarada completa, saldo final é inicial mais entradas bem-sucedidas menos saídas bem-sucedidas e custos aplicáveis. Declarar custos incluídos. O conjunto fixa explicitamente taxas nativas e outros efeitos em zero neste modelo simplificado.

Entrada bruta, saída bruta e mudança líquida ficam separadas. Carteira que recebe6 e envia5 aumenta1 líquido. Não «recebeu apenas1» nem ganhou6 ignorando saídas.

Reconciliação sustenta explicação contabilística na janela. Não estabelece motivos, legitimidade ou propriedade económica do saldo inicial. Se registos incompletos, preservar variação inexplicada em vez de a atribuir a conta anterior presumida.

Interpretar fonte comum sem fundir pessoas

Se HUB envia a vários endereços, relação observada é financiamento imediato comum. Explicações possíveis incluem um operador, serviço partilhado, distribuição pública ou levantamentos não relacionados. Alternativas não provam nenhuma; impedem que uma explicação se torne prova exclusiva.

Rótulo de fornecedor pode ajudar a formular próxima verificação. Capturar editor, fundamento probatório e âmbito. Várias interfaces copiando rótulo não acrescentam evidência independente de identidade. Não criar nó de pessoa com base em fonte comum.

Escrever afirmação ao nível sustentado

Preferir «F1 é o primeiro evento nativo de entrada bem-sucedido visível em SIM-DAY5–8; as 3 unidades iniciais têm proveniência desconhecida» a «HUB criou W». A frase limitada continua útil e testável.

Se alvo é mecanismo de financiamento e não identidade, pedir resultado, caminho descodificado e saldos correspondentes. Associação anterior exige evidência adicional de fonte/controlo. Caminho de financiamento não dá sinal BUY/SELL nem estabelece causalidade de mercado.

• Fonte imediata: conta que fornece diretamente um movimento descodificado.
• Fonte anterior: ponto anterior num caminho observado.
• Saldo inicial: inventário no início da janela.
• Lacuna de histórico anterior: registos indisponíveis antes da janela.
• Mecanismo de financiamento: transferência, emissão ou outra operação especificada.
• Hipótese de alocação: regra de rastreio de quantidades fungíveis através de inventário misturado.

ILLUSTRATIVE — FIX-P09-03. SIM-CHAIN-A / W. Números SIM-DAY são deslocamentos inventados de dias de calendário. Efeitos nativos completos em SIM-DAY5–8; abertura de 3 unidades NATIVE, taxas/outros efeitos zero neste modelo.

F0 é registo anterior fornecido fora da janela alvo, não histórico completo de HUB. F5 é ativo separado; ligação ao depósito na cadeia de origem ausente. Fornecedor rotula HUB «plataforma de negociação» sem autenticação.

OBSERVED no conjunto: F1 fornece5 unidades nativas diretamente de HUB; F3 devolve1 de B; F5 fornece operação local de emissão.

INFERRED: na janela nativa, entrada 6, saída 5, líquido+1 e final 4. F1 é primeiro evento nativo de entrada visível nessa janela.

UNKNOWN: origem das 3 iniciais, humanos anteriores, identidade de serviço HUB e depositante original de F5.

INSUFFICIENT EVIDENCE: F0/F1 não alocam exclusivamente os50 de A a W. Ordem de F3 não prova reembolso. Financiamento comum HUB não estabelece propriedade humana partilhada.

Chamar verdadeiro primeiro financiamento à linha devolvida mais antiga; ignorar inventário inicial; somar tokens de ponte e unidades nativas; alocar unidades fungíveis de hub sem hipóteses; adotar rótulos de fonte como prova de identidade.

Desenhar caminho nativo com lacuna anterior, calcular reconciliação de janela de W e identificar primeira fonte nativa visível. Classificar afirmações de reembolso, plataforma de negociação e depositante original da ponte.

• Definir ativo alvo e regra de financiamento.
• Separar observações imediatas e anteriores.
• Preservar lacunas de proveniência do saldo inicial.
• Verificar mecanismo bem-sucedido, não apenas rótulos.
• Reconciliar bruto e líquido na cobertura.
• Nunca fundir proprietários por financiamento comum.

Análise de financiamento reconstrói caminhos e quantidades disponíveis. Conclusão honesta mais forte pode ser primeira fonte visível com lacunas anteriores explícitas.

Fonte imediata não é origem última. Caminho não é alocação única através de hub. Financiamento comum e rótulos de fornecedor não provam identidade.

Grafo nativo dirigido F0–F4 com quantidades e deslocamentos de dias; marcar histórico anterior HUB desconhecido e abertura W de 3. Colocar emissão de ponteF5 em faixa separada de ativo com aresta ausente da cadeia de origem. Painel de reconciliação6 de entrada/5 de saída/líquido+1/final4; rótulos de fornecedor tracejados.

Caminho ilustrativo de financiamento; fontes partilhadas não estabelecem propriedade.

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.
• Estruturas JSON do RPC Solana — Metadados de resultado, taxa, instruções e saldos como vistas distintas. Verificado em 2026-09-30.
• Solana getTokenAccountsByOwner — Enumeração de saldos por proprietário com filtros de mint/programa. 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-L04 após o exercício resolvido e a revisão das perguntas.