Fuente de financiación

Máster fuente EN · P09-L03 · 45 minutos estimados · needs_review

«Financiado por X» puede significar remitente inmediato, fuente anterior visible, etiqueta de servicio u origen humano último. Son afirmaciones distintas. Un historial incompleto puede respaldar el primer evento entrante visible dejando desconocidos los fondos iniciales y la procedencia anterior.

Reconstruirás una ruta de financiación delimitada, distinguirás financiación nativa y de tokens y expresarás el historial previo faltante. La financiación común sigue siendo observación de relación, no prueba de propietario común.

Definir la financiación para la pregunta

Especificar activo, objetivo y propósito. Las unidades nativas para comisiones difieren de tokens recibidos para otra actividad. Si una cartera recibe un token sin entrada nativa suministrada, no se puede asumir que ese evento explica su saldo para comisiones.

«Primera transferencia nativa entrante visible» es una regla reproducible. «Financiador original» es más fuerte: requiere historial previo y definición clara de origen. Una instantánea con saldo inicial ya establece que la ventana mostrada no explica cada unidad.

Usar dirección objetivo exacta y cuentas de tokens relevantes. La enumeración Solana por propietario filtra por mint o programa [S09-OWNERS]; suministra una relación de cuenta, no el humano detrás de la financiación. No fusionar activos porque una interfaz los muestra juntos.

Separar fuente inmediata e historial anterior

Una transferencia directa exitosa identifica la cuenta fuente inmediata bajo su mecanismo decodificado. No identifica quién dio instrucciones a esa cuenta, si representa un servicio ni de dónde vinieron finalmente sus fondos.

Una ruta de dos saltos A→HUB→W registra dos operaciones. En un modelo de saldo por cuenta, los fondos entrantes pueden mezclarse con inventario anterior. Mostrar una ruta cronológica no establece que las unidades exactas recibidas por W fueran exclusivamente las enviadas por A. Explicar la hipótesis de asignación si se intenta atribuir flujos.

En esta lección no asignar unidades particulares a través del hub. Informar la ruta suministrada y sus límites. Un grafo puede ser útil sin fingir que rastrea monedas identificables de forma única a través de saldos fungibles.

Distinguir mecanismos de evento

Transferencia de tokens, acuñación, recompensa, reembolso y operación de puente pueden cambiar inventario. No son aristas de fuente intercambiables. Una acuñación de puente decodificada identifica un mecanismo local sin identificar al depositante original entre cadenas.

No llamar reembolso a una transferencia de retorno solo porque sigue a una salida anterior. La etiqueta necesita evidencia de mecanismo o contexto. Igualmente, un pago de una dirección etiquetada como plataforma de intercambio es un pago de esa dirección más una etiqueta no verificada hasta que la procedencia respalde el servicio.

Las instrucciones y metadatos de resultado aportan vistas de mecanismo para esta inspección [S09-STRUCTURES]. La documentación explica campos; no autentica etiquetas económicas del proveedor ni registros de ejercicio inventados.

Registrar cobertura antes de elegir el primer evento

El historial de firmas Solana muestra más recientes primero y está paginado [S09-SIGNATURES]. El elemento más antiguo de una página es solo el más antiguo de esa página. Alcance de búsqueda, paginación y retención del proveedor determinan qué actividad anterior podría faltar.

Recuperar éxito e importes separados de la lista de descubrimiento. Un resultado null de transacción en el compromiso solicitado es evidencia no disponible [S09-TRANSACTION]. No poner importe ni remitente supuestos en el grafo para conectar una laguna.

Fijar la ventana de observación. Cuando el saldo inicial está suministrado pero su origen no, dibujar una laguna etiquetada de historial previo en lugar de tratar la primera transferencia posterior como creación de cuenta. La primera financiación visible no necesariamente es la verdadera primera financiación.

Conciliar un saldo delimitado

Para una ventana declarada completa, saldo final equivale a saldo inicial más entradas exitosas menos salidas exitosas y costes aplicables. Expresar qué costes se incluyen. El conjunto fija explícitamente comisiones nativas y otros efectos en cero para este modelo simplificado.

Entrada bruta, salida bruta y cambio neto quedan separados. Una cartera que recibe6 y envía5 aumenta1 neto. No «recibió solo1» ni ganó6 ignorando sus salidas.

La conciliación respalda la explicación contable dentro de la ventana. No establece motivos, legitimidad ni propiedad económica del saldo inicial. Si faltan registros, preservar el cambio inexplicado en lugar de asignarlo a una cuenta anterior supuesta.

Interpretar fuente común sin fusionar personas

Si HUB envía a varias direcciones, la relación observada es financiación inmediata común. Posibles explicaciones incluyen un operador, servicio compartido, distribución pública o retiradas sin relación. Existir alternativas no prueba ninguna; impide convertir una explicación en prueba exclusiva.

Una etiqueta de proveedor puede ayudar a formular la siguiente comprobación. Registrar publicador, fundamento probatorio y alcance. Varias interfaces copiando la misma etiqueta no añaden evidencia independiente de identidad. No crear un nodo de persona por una fuente común.

Escribir la afirmación al nivel respaldado

Preferir «F1 es el primer evento entrante nativo exitoso visible dentro de SIM-DAY5–8; las 3 unidades iniciales tienen procedencia desconocida» a «HUB creó W». La frase limitada sigue siendo útil y comprobable.

Si se investiga un mecanismo de financiación y no identidad, pedir resultado de transacción, ruta decodificada y saldos coincidentes. Para una asociación anterior se requiere evidencia adicional de fuente/control. Una ruta de financiación no emite señal BUY/SELL ni establece causalidad de mercado.

• Fuente inmediata: cuenta que suministra directamente un movimiento decodificado.
• Fuente anterior: punto previo de una ruta observada.
• Saldo inicial: inventario al inicio de la ventana.
• Laguna de historial previo: registros no disponibles anteriores a la ventana.
• Mecanismo de financiación: transferencia, acuñación u otra operación especificada.
• Hipótesis de asignación: regla para rastrear cantidades fungibles a través de inventario mezclado.

ILLUSTRATIVE — FIX-P09-03. SIM-CHAIN-A / W. Los números SIM-DAY son desplazamientos inventados de días de calendario. Efectos nativos completos en SIM-DAY5–8; saldo inicial 3 unidades NATIVE, comisiones/otros efectos cero en este modelo.

F0 es un registro anterior suministrado fuera de la ventana objetivo, no historial completo de HUB. F5 es un activo separado; falta enlace con depósito en cadena fuente. Un proveedor etiqueta HUB «plataforma de intercambio» sin autenticación.

OBSERVED en el conjunto: F1 suministra5 unidades nativas directamente de HUB; F3 devuelve1 desde B; F5 suministra una acuñación local.

INFERRED: dentro de la ventana nativa, entrada 6, salida 5, neto+1 y final 4. F1 es el primer evento entrante nativo visible en esa ventana.

UNKNOWN: origen de las 3 iniciales, humanos anteriores, identidad de servicio HUB y depositante original de F5.

INSUFFICIENT EVIDENCE: F0/F1 no asignan exclusivamente los50 de A a W. El orden de F3 no prueba semántica de reembolso. Financiación común HUB no establece propiedad humana compartida.

Llamar verdadera primera financiación a la fila devuelta más antigua; ignorar inventario inicial; sumar tokens de puente y unidades nativas; asignar unidades fungibles de hub sin hipótesis; adoptar etiquetas de fuente del proveedor como prueba de identidad.

Dibujar la ruta nativa suministrada con laguna previa, calcular conciliación de la ventana de W e identificar su primera fuente nativa visible. Clasificar afirmaciones de reembolso, plataforma de intercambio y depositante original del puente.

• Definir activo objetivo y regla de financiación.
• Separar observaciones inmediatas y anteriores.
• Preservar lagunas de procedencia del saldo inicial.
• Verificar mecanismo exitoso, no solo etiquetas.
• Conciliar bruto y neto dentro de cobertura.
• Nunca fusionar propietarios por financiación común.

El análisis de financiación reconstruye rutas y cantidades disponibles. Su conclusión honesta más fuerte puede ser una primera fuente visible con lagunas previas explícitas.

Fuente inmediata no es origen último. Una ruta no es asignación única a través de un hub. Financiación común y etiquetas de proveedor no prueban identidad.

Grafo nativo dirigido F0–F4 con cantidades y desplazamientos de día; marcar historial previo HUB desconocido y apertura W de 3. Poner acuñación de puenteF5 en carril de activo separado con arista faltante de cadena fuente. Panel de conciliación6 entrantes/5 salientes/neto+1/final4; etiquetas de proveedor discontinuas.

Ruta ilustrativa de financiación; fuentes compartidas no establecen propiedad.

Usar SVG/HTML determinista o gráficos con unidades, localizadores de evidencia y alternativas textuales. Azul marino/negro con cian, azul eléctrico y violeta discretos; sin capturas decorativas o fabricadas de exploradores. A 390px apilar anotaciones; verificar 768px, escritorio y RTL árabe cuando se implementen los recursos. Mantener identificadores LTR y las direcciones fácticas de tiempo/aristas/ejes sin cambios. Usar únicamente la marca oficial BlockAssay suministrada. Ambos registros visuales siguen siendo especificaciones.

WALLET_INTELLIGENCE corresponde a la inspección de solo lectura de registros de direcciones públicas, relaciones y procedencia. Verificar red compatible, identificadores exactos, campos y cobertura antes de cualquier integración en ejecución; aquí no se afirma ninguna capacidad de proveedor en vivo. Usar el ejercicio sin conexión incluido si faltan datos o acceso de pago. No se requiere conexión de cartera, credenciales, clave privada, firma ni operación real de mercado. Los datos ausentes siguen desconocidos. El progreso Academy, estatus de creador, pagos y referidos nunca alteran la evidencia Radar.

• Solana getSignaturesForAddress — Historial de firmas que referencian la dirección, orden de más reciente a más antiguo y paginación. Comprobado el 2026-09-30.
• Solana getTransaction — Consulta de transacciones, compromiso de confirmación y campos de datos/tiempo que pueden ser nulos. Comprobado el 2026-09-30.
• Estructuras JSON del RPC Solana — Metadatos de resultado, comisión, instrucciones y saldos como vistas distintas. Comprobado el 2026-09-30.
• Solana getTokenAccountsByOwner — Enumeración de tenencias por propietario con filtros de mint/programa. Comprobado el 2026-09-30.

Todos los registros de ejemplo son conjuntos originales ILLUSTRATIVE, no mediciones históricas/en vivo de la cadena. La documentación explica mecanismos, no importes ni etiquetas inventados. La cronología sintética está explícitamente delimitada; observedAt=null es intencional. OBSERVED en un ejercicio significa un registro suministrado del conjunto. Revisar nuevamente la documentación y la decodificación desplegada antes de publicar. Las etiquetas de proveedor no establecen identidad; el control de direcciones y la atribución humana requieren evidencias distintas.

P09-L04 después del ejercicio resuelto y la revisión de preguntas.