Clusters de billeteras y financiación

Máster de origen EN · P07-L06 · 45 minutos estimados · needs_review

Objetivos de aprendizaje:

• Construir un grafo de financiación a partir de transferencias exitosas proporcionadas explícitamente.
• Separar cohortes de financiador común de hipótesis de control compartido.
• Calcular flujos brutos y saldos finales condicionales sin contar dos veces.

Los grafos de financiación pueden revelar relaciones que una tabla de tenedores omite, pero también crear identidades falsas convincentes. Un financiador común podría ser servicio de custodia, faucet, cuenta de nóminas u operador de lanzamiento. La habilidad práctica es conservar aristas de transferencia tratando interpretaciones de control compartido como hipótesis con alternativas.

Definir nodos y aristas con precisión

Un grafo de financiación empieza con una transferencia observada: dirección/cuenta de origen, destino, activo, cantidad, identificador de evento, resultado y contexto temporal. Una flecha debe significar algo específico, como «transferencia exitosa de cinco unidades de cotización», no simplemente «estas billeteras parecen conectadas». Un grafo con líneas hermosas pero significado de aristas sin especificar no es evidencia reproducible.

En el alcance de Solana, las estructuras de transacciones distinguen claves de cuentas, información de firmantes, instrucciones y metadatos de resultado/saldos [S-STRUCTURE]. Leerlas respalda reconstrucción operativa de transferencias. El propietario controlador de una cuenta de tokens puede consultarse por separado [S-OWNERS]. Ni un indicador de firmante ni un campo de propietario de cuenta proporciona una identidad de pasaporte.

Distinga una arista directa de financiación de una ruta con intermediarios. Si aparece F→A→B, no es idéntico a F→B. La cuenta intermedia puede combinar fondos de orígenes sin relación o actuar para varios usuarios. Salvo que el modelo de trazado y los flujos completos lo justifiquen, no describa la cantidad final como las mismas monedas identificables de forma única.

Separar tres tipos de relaciones

Una relación de financiación registra movimiento de activos. Una relación operativa puede registrar autoridad firmante común o rol compartido de programa respaldado por datos explícitos. Una relación de control humano es una afirmación mucho más fuerte. Mantenga estilos de arista o tablas diferentes para cada una. Nunca convierta las tres en una etiqueta genérica de «billeteras vinculadas».

La financiación compartida es útil para generar hipótesis. No basta para concluir control común. El mismo servicio puede financiar muchos clientes independientes. A la inversa, direcciones financiadas independientemente pueden compartir controlador. Ambas direcciones muestran por qué una pertenencia automatizada a cluster debe conservar su regla y confianza en lugar de afirmar certeza.

Declare la regla de agrupación antes de inspeccionar la conclusión. Por ejemplo: «agrupar direcciones que reciben unidades de cotización directamente del mismo origen en la ventana proporcionada». Esa regla crea una cohorte de financiación. No afirma un cluster de identidad humana. Renombre el resultado acordemente para que un informe posterior no herede accidentalmente una etiqueta exagerada.

Comprobar hipótesis frente a alternativas

Para cada relación inferida, liste una alternativa y la evidencia que la distinguiría. Si tres billeteras reciben cantidades similares y operan poco después, la actividad coordinada es una explicación candidata. Clientes independientes retirando de un servicio compartido es otra. Un indexador también podría asignar incorrectamente una etiqueta de origen. El analista debe preguntar qué observación distingue realmente estas explicaciones.

Más de la misma pista débil no es siempre una pista más fuerte. Diez transferencias de un centro de custodia a diez clientes no se vuelven prueba de identidad porque el grafo sea denso. Evidencia diferente puede ser más informativa: autoridad compartida explícita para una cuenta particular, divulgación corroborada independientemente o mecanismo operativo verificado. Incluso esto puede respaldar operaciones conjuntas sin identificar un individuo.

El momento repetido puede describirse sin interpretar intención. Un grafo puede informar que la financiación precedió una operación de lanzamiento por un intervalo corto observado. «Conocían el lanzamiento de antemano» es una afirmación separada. Un supuesto de latencia, historial ausente o marca temporal gruesa puede cambiar el intervalo aparente.

Delimitar cobertura del grafo y cantidades trazadas

Todo grafo tiene alcance: red, conjunto de activos, ventana de observación, máximo de saltos, cobertura de proveedor y exclusiones. Un diagrama de tres saltos sin historial anterior a su primer nodo muestra el primer origen visible en ese análisis, no necesariamente el origen último. Incluya rutas entrantes sin resolver en el límite.

Saldos y volumen de flujo difieren. Sumar todas las transferencias entrantes puede contar dos veces fondos que van y vuelven. Sumar flujos superpuestos de clusters puede contar la misma cantidad en varios saltos. Diga si un total es flujo entrante bruto, flujo neto o saldo al final de la ventana. Una leyenda útil de grafo nombra unidades de aristas y reglas de agregación.

Las etiquetas de servicios también necesitan estado. Si F es solo «plataforma de intercambio declarada», conserve esa incertidumbre. Use la evidencia de transferencias con independencia de la etiqueta, pero compruebe la interpretación con y sin clasificación de servicio. Etiquetas falsas de entidades pueden contaminar muchas conclusiones posteriores a la vez.

El resultado es un informe de relaciones honesto sobre lo visto y lo inferido. Un cluster es un instrumento de investigación. No es señal de inversión, prueba de colusión ni permiso de revelar identidades privadas.

• Arista directa: una transferencia proporcionada entre nodos especificados.
• Cohorte de financiación: direcciones agrupadas por regla explícita de financiación.
• Hipótesis de cluster: relación propuesta, no hallazgo de identidad.
• Nodo de límite: nodo con historial relevante fuera de cobertura disponible.
• Flujo bruto: suma de transferencias sin descontar retornos.
• Flujo neto: entrada direccional menos salida para activo/ventana especificados.

EJEMPLO ILLUSTRATIVE — FIX-P07-06. Todas las etiquetas, cantidades de cotización y tiempos son ficticios. Solo se cubren estas transferencias proporcionadas.

HUB tiene una etiqueta sin corroborar de servicio de custodia. No se proporciona registro de firmantes compartidos, identificación humana ni historial anterior de HUB. OUT es un nodo de límite sin resolver.

OBSERVED: HUB financia las tres direcciones; W1 y W2 intercambian una unidad en cada dirección; W3 transfiere dos unidades a OUT.

INFERRED: W1/W2/W3 forman una cohorte de financiador directo común bajo la regla indicada. No es control humano común.

UNKNOWN: Origen último de financiación de HUB y controladores humanos de W1, W2, W3 u OUT.

INSUFFICIENT EVIDENCE: Financiación igual más transferencias recíprocas no pueden establecer un operador único, manipulación coordinada ni red de iniciados. Una etiqueta de custodia tampoco prueba relación de cliente.

Etiquetar un origen común de financiación como creador; suponer que transferencias iguales implican un controlador; colorear todas las aristas de hipótesis como observadas; sumar transferencias brutas como saldos; y trazar «origen último» más allá de historial ausente.

Aplique la regla de financiación directa de HUB. Calcule salida bruta de HUB y saldos de W1/W2/W3 al final de ventana bajo el supuesto explícito de que cada uno empieza en cero y estas son las únicas transferencias relevantes, excluyendo comisiones. Compare entrada bruta de W1 con su saldo final. Escriba dos explicaciones alternativas de la cohorte.

• Especificar unidad y evento detrás de cada arista observada.
• Conservar red, ventana de cobertura y límite de saltos.
• Separar financiación común, roles operativos e identidad humana.
• Distinguir flujos brutos/netos y saldos finales.
• Registrar explicaciones rivales y etiquetas de origen sin verificar.

Un grafo de financiación es más sólido cuando semántica de aristas, alcance e incertidumbres son explícitos. La financiación compartida respalda una cohorte reproducible, pero el control humano compartido requiere evidencia adicional.

Agrupe con una regla revelada. Mantenga las hipótesis visibles como hipótesis. Una ruta anterior ausente es una incógnita, no prueba de origen último.

Dibujar FIX-P07-06 como grafo dirigido de financiación con cantidades/tiempos en aristas sólidas de transferencia. Mantener rayada la etiqueta de servicio HUB y OUT como límite sin resolver. Colocar un corchete separado discontinuo de hipótesis alrededor de la cohorte de financiador directo etiquetado «no propiedad humana». Incluir paneles laterales de entrada bruta frente a saldo final.

Reglas de entrega visual: azul marino oscuro/negro, acentos cian/azul eléctrico/violeta, unidades e incertidumbre etiquetadas explícitamente. Use gráficos deterministas o SVG, no capturas inventadas. A 390 px apile anotaciones y proporcione la tabla de datos como alternativa textual; verifique 768 px y escritorio después. En árabe localice etiquetas y diseño con RTL nativo, aislando direcciones/hashes LTR y conservando la dirección real de transferencias y cronología. Use solo el logotipo oficial BlockAssay proporcionado si se añade marca. No se afirma que ningún recurso visual ni renderizado móvil/RTL esté listo.

Use WALLET_INTELLIGENCE solo cuando la red exacta, el activo y los campos necesarios estén admitidos y su procedencia sea visible. Esta es una inspección educativa de solo lectura, no una operación ni lanzamiento de tokens. Use el conjunto de datos sin conexión proporcionado si no hay acceso o datos; la información ausente sigue siendo desconocida. Una futura acción Open in BlockAssay necesita enrutamiento de runtime y cobertura de fuentes validados. No se proporciona CTA ejecutable de activo para identificadores ilustrativos. La participación en Academy y la condición comercial nunca cambian las observaciones de Radar.

• Estructuras JSON de RPC de Solana — Firmantes de transacciones, instrucciones y metadatos de saldos/resultados. Revisado 2026-09-30.
• Solana getTokenAccountsByOwner — Enumeración de cuentas de tokens por propietario de cuenta; el campo de propiedad no es identidad humana. Revisado 2026-09-30.
• Solana getSignaturesForAddress — Firmas de direcciones referenciadas en orden de más nuevas primero y parámetros de paginación. Revisado 2026-09-30.

Las tablas y conjuntos ficticios de ejercicios son material educativo original salvo que se designen explícitamente HISTORICAL. Los identificadores ficticios son deliberadamente inválidos como direcciones de blockchain. La documentación respalda definiciones de mecanismos, no los valores inventados de los ejercicios. La inspección de fuentes es investigación editorial, no medición de una cadena en vivo. Las fuentes pueden cambiar; vuelva a revisarlas antes de publicar.

P07-L07; continúe tras completar el ejercicio y revisar cada explicación del cuestionario.